January 2016 - ghc-tickets

Re: [GHC] #4479: Implement Dot as Postfix Function Apply
by GHC 04 Jan '16

04 Jan '16

#4479: Implement Dot as Postfix Function Apply -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adam.gundry@… (removed) * cc: adamgundry (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4479#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7169: Warning for incomplete record field label used as function
by GHC 04 Jan '16

04 Jan '16

#7169: Warning for incomplete record field label used as function -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Warnings, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adam.gundry@… (removed) * cc: adamgundry (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7169#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5972: option to suppress (Monomorphic) record selector functions
by GHC 04 Jan '16

04 Jan '16

#5972: option to suppress (Monomorphic) record selector functions -------------------------------------+------------------------------------- Reporter: AntC | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: records Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adam.gundry@… (removed) * cc: adamgundry (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5972#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2595: Implement record update for existential and GADT data types
by GHC 04 Jan '16

04 Jan '16

#2595: Implement record update for existential and GADT data types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: tc244 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adam.gundry@… (removed) * cc: adamgundry (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2595#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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

Re: [GHC] #2258: ghc --cleanup
by GHC 04 Jan '16

04 Jan '16

#2258: ghc --cleanup -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4114 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): > Also, have I missed something? Maybe. Check out: * -dynamic * -dynamic-too * -dyno * -dynosuf * Should intermediate files also get deleted when using `--cleanup` to create shared libraries (https://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide/using- shared-libs.html)? * What happens on compilation failures. Say `A.hs` contains a syntax error, and imports `B.hs`. When running `ghc --cleanup A.hs`, `B.hs` gets compiled first, creating `B.hi` and `B.o`. Then `A.hs` fails to compile, because of the syntax error. Should `B.hi` and `B.o` get deleted? * Is `ghc --make --cleanup` allowed? Maybe the command line interface should be something like `ghc --make -cleanup` (so `-cleanup` would not be a mode flag, but a regular flag, just like for example `-keep-tmp-files` and `-outputdir`.). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2258#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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] #11175: Holding Ctrl+C on Windows GHCI Prompt crashes with concurrency panic
by GHC 04 Jan '16

04 Jan '16

#11175: Holding Ctrl+C on Windows GHCI Prompt crashes with concurrency panic ----------------------------------------+--------------------------------- Reporter: cwfenner | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- When I hold Control-C in the GHCI prompt (on either Windows Powershell or Command Prompt), then release, the prompt stops responding. The first few keystrokes will be ignored altogether, then the next ignored intermittently. After typing around 5 words, GHCi crashes with the following output: {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation }}} If I don't type after holding Ctrl+C, GHCi seems to sit happily without crashing. No amount of waiting after holding Ctrl+C seems to make it recover. It does not matter whether I press return or not. However, faster typing seems to make it crash in fewer keystrokes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11175> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

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

03 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

Re: [GHC] #1853: hpc mix files for Main modules overwrite each other
by GHC 03 Jan '16

03 Jan '16

#1853: hpc mix files for Main modules overwrite each other ----------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Code Coverage | Version: 6.8.1 Resolution: | 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: | ----------------------------------+-------------------------------------- Comment (by mgsloan): There's a pretty good reason not to vary `--hpcdir`. You can only pass in one `--hpcdir` to the `hpc` program, and it's treated as a relative path to each of the `--srdir`s. So, if you want to generate a report which spans multiple packages, `--hpcdir` needs to be kept constant. We might consider improving the hpc program's CLI. This particular issue is discussed further in https://ghc.haskell.org/trac/ghc/ticket/10951 The tricky thing about combining tix files together is that module names within the tix file are not sufficiently disambiguated. For packages, they are prefixed by their package key / id. So, you expect to find the mix file for `TixModule "cycli_6S2W1a0WjTe91AyXmPMq2j/Cyclic" ...` at some `HPCDIR/cycli_6S2W1a0WjTe91AyXmPMq2j/Cyclic.mix`. However, for modules from the non-library components, there is no folder. Instead it's just `TixModule "Main" ...` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1853#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0