March 2016 - ghc-tickets

[GHC] #10520: RecordWildCards causes “is not a (visible) field of constructor” in ghci
by GHC 02 May '16

02 May '16

#10520: RecordWildCards causes “is not a (visible) field of constructor” in ghci -------------------------------------+------------------------------------- Reporter: ion1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux RecordWildCards | Type of failure: GHC rejects Architecture: x86_64 | valid program (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ % ghc -ignore-dot-ghci -e 'data Foo = Bar { baz :: Integer } deriving Show' -e 'Bar 42' -e '(Bar 42){ baz = 43 }' -e 'Bar { baz = 42 }' Bar {baz = 42} Bar {baz = 43} Bar {baz = 42} }}} {{{ % ghc -ignore-dot-ghci -XRecordWildCards -e 'data Foo = Bar { baz :: Integer } deriving Show' -e 'Bar 42' -e '(Bar 42){ baz = 43 }' -e 'Bar { baz = 42 }' Bar {baz = 42} Bar {baz = 43} <interactive>:1:7: ‘baz’ is not a (visible) field of constructor ‘Bar’ }}} {{{ % ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10520> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11747: `Strict` causes core lint error
by GHC 02 May '16

02 May '16

#11747: `Strict` causes core lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: Strict | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ghci -dcore-lint -XStrict -XGADTs -XRankNTypes -XTypeApplications -XScopedTypeVariables -ignore-dot-ghci GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Typeable Prelude Data.Typeable> let zero :: forall x. Typeable x => Maybe x; zero = do Refl <- eqT @Int @x; pure 0 Prelude Data.Typeable> zero *** Core Lint errors : in result of desugar expression *** <no location info>: warning: In the expression: ds_d1t9 @ x_a1sx $dTypeable_a1sC @ x_a1sx $dTypeable_a1sz $dTypeable_a1sz :: Typeable x_a1sx [LclId, Str=DmdType] is out of scope *** Offending Program *** let { $dTypeable_a1sS :: Typeable () [LclId, Str=DmdType] $dTypeable_a1sS = D:Typeable @ * @ () (let { ds_d1tb :: TypeRep [LclId, Str=DmdType] ds_d1tb = mkPolyTyConApp $tc() ([] @ TypeRep) ([] @ TypeRep) } in \ (wild_00 :: Proxy# ()) -> ds_d1tb) } in let { $dShow_a1sU :: Show () [LclId, Str=DmdType] $dShow_a1sU = $fShow() } in let { $dShow_a1sP :: Show (Maybe ()) [LclId, Str=DmdType] $dShow_a1sP = $fShowMaybe @ () $dShow_a1sU } in letrec { ds_d1t9 :: forall x_a1sx. Typeable x_a1sx => forall x_a11P. Typeable x_a11P => Maybe x_a11P [LclId, Str=DmdType] ds_d1t9 = \ (@ x_a1sx) ($dTypeable_a1sC :: Typeable x_a1sx) -> let { $dTypeable_a1sz :: Typeable x_a1sx [LclId, Str=DmdType] $dTypeable_a1sz = $dTypeable_a1sC } in letrec { it_a1sw :: forall x_a11P. Typeable x_a11P => Maybe x_a11P [LclId, Str=DmdType] it_a1sw = zero; } in it_a1sw; it_a1dz :: forall x_a1sx. Typeable x_a1sx => Maybe x_a1sx [LclId, Str=DmdType] it_a1dz = \ (@ x_a1sx) ($dTypeable_a1sC :: Typeable x_a1sx) -> ds_d1t9 @ x_a1sx $dTypeable_a1sC @ x_a1sx $dTypeable_a1sz; } in case it_a1dz of it_a1dz { __DEFAULT -> thenIO @ () @ [()] (print @ (Maybe ()) $dShow_a1sP (it_a1dz @ () $dTypeable_a1sS)) (returnIO @ [()] (: @ () (unsafeCoerce# @ 'Lifted @ 'Lifted @ (forall x_a1sx. Typeable x_a1sx => Maybe x_a1sx) @ () it_a1dz) ([] @ ()))) } *** End of Offense *** <no location info>: error: Compilation had errors *** Exception: ExitFailure 1 Prelude Data.Typeable> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11747> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11545: Strictness signature blowup
by GHC 01 May '16

01 May '16

#11545: Strictness signature blowup -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code takes a lot of memory (556MB) to compile: {{{#!hs data A = A A A A A A deriving (Eq) }}} More {{{A}}}s result in more memory consumption during compilation. Using {{{ghc -O A.hs -v -dverbose-core2core -c -ddump-simpl +RTS -s}}} it seems like the strictness signatures of (==) and (/=) blow up quite a bit. A less silly example could be the following: {{{#!hs data QuadTree a = QuadTree !Int [a] (QuadTree a) (QuadTree a) (QuadTree a) (QuadTree a) foldQuadTree :: (a -> b -> b) -> Int -> b -> QuadTree a -> b foldQuadTree f maxSize = go where go z (QuadTree size elems t1 t2 t3 t4) | size <= maxSize = foldr f z elems | otherwise = go (go (go (go z t4) t3) t2) t1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11545> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9758: By default, testsuite should clean up after successful tests
by GHC 30 Apr '16

30 Apr '16

#9758: By default, testsuite should clean up after successful tests -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: low | Milestone: Component: Test Suite | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- A fully built GHC compiler for development takes about 1G of space. However, running the testsuite balloons this amount to 10G. Why? Because we don't clear away any test files by default. Now, it's pretty useful to have these files if you're debugging a problem. But I think it's pretty unnecessary for successful tests. So I suggest cleaning out the files automatically if the test succeeds. Tradeoff: the testsuite will take longer to run since it is cleaning up after itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9758> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9543: Testsuite driver: replace "extra_clean" by "git clean -X"
by GHC 26 Apr '16

26 Apr '16

#9543: Testsuite driver: replace "extra_clean" by "git clean -X" -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When adding a new test that creates extra files, one also has to do some bookkeeping: 1. Supply an `extra_clean` argument to the test function in `all.T`. 2. Add an entry in `testsuite/.gitignore` Step number 1 is often forgotten. Currently there are over 200 uncleaned files and directories left behind in the `testsuite`, after running `validate` and then `make clean` (checked with `git clean -X -d -n | wc -l`). I propose to replace the functionality that `extra_clean` provides, namely to remove these extra files when one calls `make clean`, by doing the equivalent of `git clean -X -d`: {{{ -X Remove only files ignored by Git. -d Remove untracked directories in addition to untracked files. ... }}} That is: use the information from the `.ignore` files to figure out which files to delete on `make clean`. The advantages of making this change are: 1. Less manual bookkeeping, less work, less code 2. A more thorough `make clean` Implementation detail: we can not just call `git clean` directly, since this should also work when we are not in a git directory (for example a build directory created with [wiki:Building/Using lndir]). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9543> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9253: "internal error: evacuate(static): strange closure type 0" when running in QEMU
by GHC 25 Apr '16

25 Apr '16

#9253: "internal error: evacuate(static): strange closure type 0" when running in QEMU ------------------------------------+------------------------------------- Reporter: ocharles | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We're trying to use NixOS to automatically run our acceptance tests in a VM on commit, in order to guarantee system stability. However, we're periodically seeing our web server component, compiled with GHC 7.8.2 is failing to start up. When it fails, the error message is always: {{{ internal error: evacuate(static): strange closure type 0 (GHC version 7.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Happy to do more debugging on this, but I'll need to be pointed in the right direction. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9253> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10725: Figure out how to support type synonym implementions of abstract data
by GHC 22 Apr '16

22 Apr '16

#10725: Figure out how to support type synonym implementions of abstract data -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- A classic example we have used when describing Backpack is that you might want to abstract over is different types of strings: String, ByteString, Text, etc. Unfortunately, with every implementation of Backpack we have had so far, you can't actually do this! For example, say you use a type synonym to get an existing data type to the "right name"; you get this error: {{{ A.hs-boot:2:6: Type constructor `T' has conflicting definitions in the module and its hs-boot file Main module: type T = String Boot file: abstract(False) T No C type associated RecFlag NonRecursive FamilyInstance: none }}} How can we make this work? Could it be as simple as just relaxing the restriction here? This seems to work OK with shaping, so long as we refer to the type synonym (and not the original type in question!) If some type checker experts could weight in that would be quite useful. ---- Probably the biggest danger is interaction with machinery that works with type families. For example, this is accepted: {{{ -- A.hs-boot module A where data T -- B.hs {-# LANGUAGE TypeFamilies #-} module B where import {-# SOURCE #-} qualified A data T = T type family F a :: * type instance F A.T = Bool type instance F T = Int }}} This doesn't lead to unsoundness today, because A.T must always be defined in A.hs (and thus have a unique nominal identity). But it's dangerous for this to be accepted today with signatures, since T could refer to B.T. (The moral of the story is that after shaping, you have to recheck all pairs of families; you can't assume that because they were typechecked earlier that they're OK.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10725> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11742: 'Strict' extension is incompatible with 'deriving' mechanism
by GHC 21 Apr '16

21 Apr '16

#11742: 'Strict' extension is incompatible with 'deriving' mechanism -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- This: {{{#!hs {-# LANGUAGE Strict #-} module Foo where data Foo = Foo deriving Eq }}} panics with {{{ ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.1.20160317 for x86_64-unknown-mingw32): makeCorePair: dfun $dEq_a1zL }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[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