- ghc-tickets - Haskell.org

Fw: new important message
by matthew＠wellquite.org 19 Apr '16

19 Apr '16

Hello! New message, please read <http://mega-data.biz/within.php?c> matthew(a)wellquite.org

1 0

[GHC] #11952: automatic show instance generating loop
by GHC 19 Apr '16

19 Apr '16

#11952: automatic show instance generating loop --------------------------------+------------------------------------- Reporter: maxigit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- I have the following code : {{{#!hs {-# LANGUAGE TypeFamilies, DataKinds #-} data Status = Valid | Invalid deriving(Show) data A s = A (TF s) type family TF (s:: Status) where TF Valid = Int TF Invalid = Either String Int instance Show (A Valid) instance Show (A Invalid) a :: A Valid a = A 3 }}} Printing `a` results in a stackoverflow. I'm using GHC-7.10.3 (and 7.8.4) on Ubuntu under a VM -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11952> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals
by GHC 19 Apr '16

19 Apr '16

#8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals ----------------------------+---------------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals. (And I don't like either option, why leave out any characters in strings unnecessarily?) Examples from ghci 7.6.3 (also tested in lambdabot on irc): {{{ Prelude> "" -- Unicode char \8203, Format class. <interactive>:10:2: lexical error in string/character literal at character '\8203' Prelude> " " -- Unicode char \8202, Space class. "\8202" Prelude> "t\ \est" -- Unicode char \8202 in a string gap. <interactive>:14:4: lexical error in string/character literal at character '\8202' }}} My reading of http://www.haskell.org/onlinereport/haskell2010/haskellch2.html (section 2.2 and 2.6): * The report BNF token "graphic", which can be used in literals, includes indirectly many Unicode classes, but uniWhite is not one of them. Thus the only Unicode whitespace allowed to represent itself in literals is ASCII space. * Unicode formatting characters are not mentioned in the BNF that I can see, so are not allowed in literals. * String gaps are made out of the report BNF token whitespace, which ''does'' include uniWhite. Who wants what: || ||= GHC =||= Report =||= Me =|| || Format in string || No || No || Yes || || Space/uniWhite in string || Yes || No || Yes || || Space/uniWhite in string gap || No || Yes || Dunno || In short, GHC's behavior is buggy and/or annoying in two opposite ways: * It leaves out some Unicode characters as allowable in strings and character literals, presumably because the report says so. * It allows some characters the report says it ''shouldn't'', and refuses some characters the report says it ''should''. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8524> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11180: A program writing to a read-only stdout should not succeed
by GHC 19 Apr '16

19 Apr '16

#11180: A program writing to a read-only stdout should not succeed -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the shell, redirection of file descriptors can be read-only (<), write- only (>), or read-write (<>). A program trying to write to stdout, while stdout is redirected read-only, currently exits with exit code 0. {{{ $ cat hello.hs main = print "hello world" $ ghc hello.hs ... $ ./hello 1< /dev/null; echo Exit status: $? Exit status: 0 }}} This should however show some error message, and return some non-zero error message, because the write never succeeds. Note that this example is different from `./hello 1> /dev/null`, which rightfully does succeed. As suggested by this [http://roscidus.com/blog/blog/2013/06/09/choosing-a -python-replacement-for-0install/ blog post]: > "If you’re not sure why this is important, imagine the command is `dump-database > backup` and the filesystem is full." Supposedly OCaml gets this right. For reference, from my bash man page: > *Redirecting Input* > > Redirection of input causes the file whose name results from the expansion of word to be opened for reading on file descriptor n, or the standard input (file descriptor 0) if n is not specified. > > The general format for redirecting input is: > > [n]<word -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11180> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11944: Simplifier ticks exhausted When trying UnfoldingDone ip_X7RI
by GHC 18 Apr '16

18 Apr '16

#11944: Simplifier ticks exhausted When trying UnfoldingDone ip_X7RI --------------------------------------+--------------------------------- Reporter: simone.trubian | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- When trying compiling the following code I get a ghc panic {{{#!hs import Network.Wai import Network.Wai.Handler.Warp import Network.HTTP.Types ( status200 , status404) import Blaze.ByteString.Builder (copyByteString) import qualified Data.ByteString.UTF8 as BU import Data.Monoid main = do let port = 3000 putStrLn $ "Listening on port " ++ show port run port app app req respond = respond $ case pathInfo req of ["avOK"] -> avOK ["avWrong"] -> avWrong x -> index x avOK = responseBuilder status200 [("Content-Type", "text/html")] $ mconcat $ map copyByteString [ "<!DOCTYPE html>" , "<html>" , "<head>" , "<title>Title</title>" , "</head>" , "<body>" , "<div class=\"status\">" , "In stock, usually dispatched in 1 business day" , "</div>" , "</body>" , "</html>"] avWrong = responseBuilder status404 [("Content-Type", "text/html")] $ mconcat $ map copyByteString ["<p>wong!</p>"] index x = responseBuilder status200 [("Content-Type", "text/html")] $ mconcat $ map copyByteString [ "<p>Hello from " , BU.fromString $ show x , "!</p>" , "<p><a href='/yay'>yay</a></p>\n" ] }}} ```<no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone ip_X7RI To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 53522k``` After a little bit of debugging I realised that it's the `copyBytestring` imported from `import Blaze.ByteString.Builder` function that is causing trouble, by reducing the number of elements in the list the function doesn't crash the compiler, so for instance: {{{#!hs avOK = responseBuilder status200 [("Content-Type", "text/html")] $ mconcat $ map copyByteString [ "<!DOCTYPE html>" , "<html><head><title>Title</title></head>" , "<body>" , "<div class=\"status\">" , "In stock, usually dispatched in 1 business day" , "</div>" , "</body>" , "</html>"] }}} compiles happily. I'm using - bytestring-0.10.6.0 - wai-3.0.4.0 - warp-3.1.8 - http-types-0.8.6 - blaze-builder-0.4.0.1 - utf8-string-1.0.1.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11944> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7459: deriving Generic does not work with TypeLits
by GHC 17 Apr '16

17 Apr '16

#7459: deriving Generic does not work with TypeLits -------------------------------------+------------------------------------- Reporter: maxtaldykin | Owner: dreixel Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: #10604 provides a couple of motivating examples for why generic programming over data-kinded types would be useful. Furthermore, the original bug in this ticket has long since been fixed, and I think it's clear by now that generics shouldn't be needlessly kind-restricted. Closing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7459#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11776: RTS segfaults when printing profiling information which refers to unloaded objects
by GHC 17 Apr '16

17 Apr '16

#11776: RTS segfaults when printing profiling information which refers to unloaded objects -------------------------------------+------------------------------------- Reporter: afarmer | Owner: afarmer Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running a profiled binary which loads/unloads objects via the RTS's linker results in a CCS tree with pointers to the shared objects. These references are not checked by checkUnload before unloading the object. Then, when the profiling report is printed at the end of the program, a segfault occurs. Plan: 1. Add a test case for this. 2. Modify checkUnload to prevent objects from being unloaded if the CCS tree points to them. 3. Modify generateCCSReport to prune the CCS tree after a report is printed. 4. Expose some way to generate a report on demand, so long-running programs don't keep every object loaded forever. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11776> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11820: bindist install script doesn't check libdw version
by GHC 17 Apr '16

17 Apr '16

#11820: bindist install script doesn't check libdw version -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Build System | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems that while the source distribution's `configure` script checks for the minimum required version of `libdw`, the binary distribution does not. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11820> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1
by GHC 17 Apr '16

17 Apr '16

#10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 -----------------------------------------+------------------------------- Reporter: jacereda | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+------------------------------- Starting ghci as: {{{ env DYLD_FORCE_FLAT_NAMESPACE=1 ghci }}} can cause symbol resolution to fail. I tried with Data.Hashable as follows: {{{ import Data.Hashable main = putStrLn $ show $ hashWithSalt 0 "foo" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10914> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

Re: [GHC] #7934: usleep hangs, no threads
by GHC 17 Apr '16

17 Apr '16

#7934: usleep hangs, no threads -------------------------------------+------------------------------------- Reporter: gelisam | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: 1156 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7934#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0