November 2015 - ghc-tickets

[GHC] #10579: full module names of names not in scope have gone missing in ghci
by GHC 05 Jan '16

05 Jan '16

#10579: full module names of names not in scope have gone missing in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compare {{{ rwbarton@morphism:/tmp$ ghci-7.10.1 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> :t GHC.Read.readPrec GHC.Read.readPrec :: Read a => Text.ParserCombinators.ReadPrec.ReadPrec a }}} with {{{ rwbarton@morphism:/tmp$ ~/ghc/inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20150624: http://www.haskell.org/ghc/ :? for help Prelude> :t GHC.Read.readPrec GHC.Read.readPrec :: Read a => ReadPrec a }}} The `Text.ParserCombinators.ReadPrec.` bit can be quite helpful, was it suppressed intentionally? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10579> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11103: DuplicateRecordFields + TemplateHaskell
by GHC 05 Jan '16

05 Jan '16

#11103: DuplicateRecordFields + TemplateHaskell -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template | Version: 7.11 Haskell | 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: -------------------------------------+------------------------------------- The [wiki:Records/OverloadedRecordFields/DuplicateRecordFields DuplicateRecordFields] extension works by mangling the Names of field selector functions, and treating fields specially in the renamer. Thus if you define {{{ data T = MkT { foo :: Int } }}} then GHC will actually generate a selector called `$sel:foo:MkT`, but will resolve `foo` to refer to this selector. In general we want this name-mangling to be internal only, but at the moment it is visible when using Template Haskell, because the TH AST doesn't have a way to represent the distinction between the selector name and the field label. For example, if you reify `''T` above and then pretty-print it you will currently get {{{ data T = MkT { $sel:foo:MkT :: Int } }}} which is obviously bad. I'm not sure how best to address this. We could represent the name as `mkNameG_v pkg mod "foo"`, which will look okay when inspected, but if it is subsequently reified it might be ambiguous. Should we add a new `NameFlavour`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11103> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10643: GHC cannot import submodules when run from subfolder
by GHC 05 Jan '16

05 Jan '16

#10643: GHC cannot import submodules when run from subfolder -------------------------------------+------------------------------------- Reporter: FPtje | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: subfolder | Operating System: Unknown/Multiple import submodule cd | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm taking a huge risk in looking like an idiot, but it's worth trying to attack the elephant in the room. The first response I expect is ''"This is expected behaviour!"''. This is what intuition says, but I disagree. It's a simple problem and the fix should be easy, unless there's some advanced import mechanism that would conflict with the solution that I don't know about. That is exactly where I'm taking the risk in reporting this issue. The problem is simple: 1. Create a folder called "Yes". 2. Create Yes/A.hs with the following code: {{{#!hs module Yes.A where import Yes.B }}} 3. Create Yes/B.hs with the following code: {{{#!hs module Yes.B where }}} 4. Open a terminal in the folder that contains "Yes" and run: {{{ $ ghc Yes/A.hs }}} '''This works fine'''. Now try the following: {{{ $ cd Yes Yes/ $ ghc A.hs }}} You'll be greeted with the beautiful error: {{{ A.hs:3:8: Could not find module ‘Yes.B’ Use -v to see a list of the files searched for. }}} A screenshot is worth the above thousand words: http://i.imgur.com/8AxRa0K.png '''This is silly'''. Running with the -v option shows that ghc is not looking for Yes/B.hs, but Yes/Yes/B.hs. I can understand ''why'' it looks there, but not why ghc isn't just this ''tiny'' bit more intelligent in knowing where to look. After all, the module name tells ghc ''exactly'' in which subfolder it is located: {{{#!hs module Yes.A where -- This module is very likely to be in Yes/, because otherwise a name inconsistency error is thrown. }}} '''Proposed solution:''' The module name tells ghc exactly where it is located. If Yes.A imports Yes.B, then you know that they're in the same subfolder. Simple as that. Instead of ignoring that information and looking for Yes/Yes/B.hs, it should simply look for Yes/B.hs. Relative to ghc (which is run from Yes/) this would be ./B.hs. This solution is scalable. Imagine a module Ding.Dong.Biddly.Bong that imports Ding.Dong.Doodle.Bell. Running "ghc Bong.hs" from Ding/Dong/Biddly/ should '''not''' make it look for "Ding/Dong/Biddly/Ding/Dong/Doodle/Bell.hs", but for Ding/Dong/Doodle/Bell.hs. Relative to ghc (run from Ding/Dong/Biddly/), this would be ../Doodle/Bell.hs. So yeah, right now ghc is arbitrarily restricted to run from the root of the source directory. This '''looks''' like intended behaviour until you realise that the silly bug mentioned here is probably the only thing that prevents ghc from running from ''any'' subfolder. Of course there are the -i and :set options for ghc that allows one to work around this, but one should not be expected to jump through all the -iFile hoops to be allowed to run ghc from any arbitrary subdirectory of the source folder. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10643> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10984: the ghc-7.8.4 source distribution contents (README, etc.)
by GHC 05 Jan '16

05 Jan '16

#10984: the ghc-7.8.4 source distribution contents (README, etc.) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc-7.8.4-src.tar.xz from https://www.haskell.org/ghc/download_ghc_7_8_4 does not include a README or INSTALL file. Its ANNOUNCE file talks of ghc-7.8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10984> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi
by GHC 04 Jan '16

04 Jan '16

#10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: GHCi | 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 Revisions: | -------------------------------------+------------------------------------- We missed the opportunity to merge this for GHC 7.10 but I hope this can make it for GHC 8.0 See https://github.com/chrisdone/ghci-ng/blob/master/README.md for a description of the new GHCi commands I've started rebasing the changes from Chris' ghci-ng repo against GHC HEAD and pushed the work-in-progress state as branch `wip/T10874`. One blocker right now is the use of SYB to traverse the AST which I don't want to drag into GHC as a dependency. So one thing that needs to be done is rewrite those 20 lines of code without relying on SYB. Other than that some minor polishing needs to be done. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10874> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10045: type holes related ghc panic
by GHC 04 Jan '16

04 Jan '16

#10045: type holes related ghc panic -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ sample.hs:9:13: Couldn't match expected type ‘t’ with actual type ‘()’ ‘t’ is untouchable inside the constraints () bound by the inferred type of foo :: Meta -> t1 at sample.hs:(6,1)-(9,17)ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.0 for x86_64-unknown-linux): No skolem info: t_avJ[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug sample.hs: module Blah where newtype Meta = Meta () foo (Meta ws1) = let copy :: _ copy w from = copy w 1 in copy ws1 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10737: GHC panic durring MVar operation
by GHC 04 Jan '16

04 Jan '16

#10737: GHC panic durring MVar operation -------------------------------------+------------------------------------- Reporter: dohaqatar7 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following error message was displayed while loading a program into ghci by executing `:r` in a ghci session: {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The only edit made to the source file before compiling was the removal of an unnecessary `do` on line 20 of the source file. The `do` was used even though the monodic computations were written in a single line style. I have not been able to reproduce the panic at all. The source file, unedited since the panic, now compiles without error. The ghci session leading up to the crash is below {{{ *Main> :t runState (filterM untouchable [1..3]) M.empty runState (filterM untouchable [1..3]) M.empty :: ([Int], M.Map Int Int) *Main> runState (filterM untouchable [1..3]) M.empty ([2],fromList [(1,1),(2,1),(3,1),(4,3)]) *Main> runState (filterM untouchable [1..10]) M.empty ([2,5],fromList [(1,1),(2,1),(3,1),(4,3),(5,1),(6,6),(7,1),(8,7),(9,4),(10,8),(11,1),(12,16),(13,1),(14,10),(15,9),(16,15),(17,1),(18,21),(19,1),(20,22),(21,11),(22,14),(23,1),(24,36),(25,6),(26,16),(27,13),(28,28),(29,1),(30,42),(31,1),(32,31),(33,15),(34,20),(35,13),(36,55),(37,1),(38,22),(39,17),(40,50),(41,1),(42,54),(43,1),(44,40),(45,33),(46,26),(47,1),(48,76),(49,8),(50,43),(51,21),(52,46),(53,1),(54,66),(55,17),(56,64),(57,23),(58,32),(59,1),(60,108),(61,1),(62,34),(63,41),(64,63),(65,19),(66,78),(67,1),(68,58),(69,27),(70,74),(71,1)(72,123),(73,1),(74,40),(75,49),(76,64),(77,19),(78,90),(79,1),(80,106),(81,40)]) *Main> runState (filterM untouchable [1..100]) M.empty ([2,5,52,88Interrupted. *Main> *Main> *Main> *Main> *Main> *Main> *Main> *Main> *Main> :r [1 of 1] Compiling Main ( C:\Users\admin\Programming\Haskell\codegolf\Untouchable.hs, interpreted ) Ok, modules loaded: Main. *Main> ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10737> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain'
by GHC 04 Jan '16

04 Jan '16

#10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' -------------------------------------+------------------------------------- Reporter: imz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: attached | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When compiling a set of 3 modules (in a certain order), linking of the final executable fails because there conflicting symbols in some of the `.o`. When doing the compilation in the same order, but with optimizations, it succeeds. The simple test case: A.hs: {{{#!hs module A where main :: IO () main = putStrLn "A" }}} B.hs: {{{#!hs module B where import A() main :: IO () main = putStrLn "B" }}} C.hs: {{{#!hs import B() main :: IO () main = putStrLn "hi" }}} When I compile it with in the order specified by the attached `./bug- reproduce.sh` and `Makefile`, the following happens: {{{ ./bug-reproduce.sh rm -fv a A.o A.hi removed 'a' removed 'A.o' removed 'A.hi' rm -fv b B.o B.hi removed 'b' removed 'B.o' removed 'B.hi' rm -fv c C.o C.hi removed 'c' removed 'C.o' removed 'C.hi' ghc -Wall A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall B.hs -main-is B.main -o b [1 of 2] Compiling A ( A.hs, A.o ) [flags changed] [2 of 2] Compiling B ( B.hs, B.o ) Linking b ... ghc -Wall C.hs -o c [2 of 3] Compiling B ( B.hs, B.o ) [flags changed] [3 of 3] Compiling Main ( C.hs, C.o ) Linking c ... removed 'A.o' ghc -Wall A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall B.hs -main-is B.main -o b [2 of 2] Compiling B ( B.hs, B.o ) [flags changed] Linking b ... ./A.o: In function `siv_closure': (.data+0x0): multiple definition of `__stginit_ZCMain' B.o:(.data+0x0): first defined here ./A.o: In function `ZCMain_main_srt': (.data+0x70): multiple definition of `ZCMain_main_closure' B.o:(.data+0x70): first defined here ./A.o:(.text+0xb8): multiple definition of `ZCMain_main_info' B.o:(.text+0xb8): first defined here collect2: error: ld returned 1 exit status make: *** [B.o] Error 1 }}} But it succeeds if done as `./bug-reproduce.sh GHC_OPTS=-O1` (probably, the optimizations remove the conflicting symbols): {{{ ./bug-reproduce.sh GHC_OPTS=-O1 rm -fv a A.o A.hi removed 'a' removed 'A.o' removed 'A.hi' rm -fv b B.o B.hi removed 'b' removed 'B.o' removed 'B.hi' rm -fv c C.o C.hi removed 'c' removed 'C.o' removed 'C.hi' ghc -Wall -O1 A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall -O1 B.hs -main-is B.main -o b [1 of 2] Compiling A ( A.hs, A.o ) [flags changed] [2 of 2] Compiling B ( B.hs, B.o ) Linking b ... ghc -Wall -O1 C.hs -o c [2 of 3] Compiling B ( B.hs, B.o ) [flags changed] [3 of 3] Compiling Main ( C.hs, C.o ) Linking c ... removed 'A.o' ghc -Wall -O1 A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall -O1 B.hs -main-is B.main -o b [1 of 2] Compiling A ( A.hs, A.o ) [flags changed] [2 of 2] Compiling B ( B.hs, B.o ) [flags changed] Linking b ... ghc -Wall -O1 C.hs -o c [2 of 3] Compiling B ( B.hs, B.o ) [flags changed] Linking c ... }}} Couldn't the compiler detect and handle such cases? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10531> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10379: Prefix syntax for promoted list kind isn't parsed properly
by GHC 04 Jan '16

04 Jan '16

#10379: Prefix syntax for promoted list kind isn't parsed properly -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- (Originally from https://stackoverflow.com/questions/27673578/) Given the following input file: {{{ {-# LANGUAGE KindSignatures, GADTs, DataKinds, TypeOperators #-} data Foo1 :: [*] -> * where data Foo2 :: ([] *) -> * where }}} it fails on the definition of `Foo2`: {{{ list-promote2.hs:4:16: parse error on input `]' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10379> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10554: Replacing existing attachment with the same name doesn't work
by GHC 03 Jan '16

03 Jan '16

#10554: Replacing existing attachment with the same name doesn't work -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10554> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5