October 2015 - ghc-tickets

[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 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

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

03 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

[GHC] #10592: Allow cycles in class declarations
by GHC 03 Jan '16

03 Jan '16

#10592: Allow cycles in class declarations -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: feature | Milestone: request | Version: 7.10.1 Priority: normal | Operating System: Unknown/Multiple Component: Compiler | Type of failure: None/Unknown (Type checker) | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In particular, I would like to have a class hierarchy that looks like: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} type family Scalar x class Field (Scalar x) => Vector x class Vector x => Field x }}} It is the case that every field is a vector, and the scalar associated with every vector is a field. But we can't currently enforce that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10592> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #10846: PartialTypeSignatures change implicit CallStack behavior
by GHC 02 Jan '16

02 Jan '16

#10846: PartialTypeSignatures change implicit CallStack behavior -------------------------------------+------------------------------------- Reporter: | Owner: nitromaster101 | 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 Revisions: | -------------------------------------+------------------------------------- I have two functions, f and f2 which are identical expect for the use of PartialTypeSignatures in f2. GHC produces a warning and says that f2's wildcard is filled in by String, which is correct. {{{#!hs {-# LANGUAGE ImplicitParams, PartialTypeSignatures #-} import GHC.Types f :: (?loc :: CallStack) => String f = show $ map (srcLocStartLine . snd) $ getCallStack ?loc f2 :: (?loc :: CallStack) => _ f2 = show $ map (srcLocStartLine . snd) $ getCallStack ?loc f_caller = f f2_caller = f2 }}} {{{ [1 of 1] Compiling Main ( Bug2.hs, interpreted ) Bug2.hs:8:30: warning: Found type wildcard ‘_’ standing for ‘String’ In the type signature for: f2 :: (?loc :: CallStack) => _ Ok, modules loaded: Main. *Main> f_caller "[6,11]" *Main> f2_caller "[9]" }}} f2_caller should have two entries (f2_caller's line and f2's line), just like f_caller. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10846> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9590: AMP breaks `haskell2010` package
by GHC 02 Jan '16

02 Jan '16

#9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: | Version: 7.9 libraries/haskell2010 | Operating System: Keywords: AMP | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (and probably also `haskell98`) I hate to be the one pointing this out, but the AMP has one ugly side- effect. Consider the following session: ``` $ inplace/bin/ghc-stage2 --interactive -XHaskell2010 -hide-all-packages -package haskell2010 GHCi, version 7.9.20140914: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim-0.3.1.0 ... linking ... done. Loading package integer-gmp-0.5.1.0 ... linking ... done. Loading package base-4.8.0.0 ... linking ... done. Loading package array-0.5.0.1 ... linking ... done. Loading package haskell2010-1.1.2.1 ... linking ... done. λ:2> data Identity a = Identity a data Identity a = Identity a λ:3> instance Monad Identity <interactive>:3:10: No instance for (base-4.8.0.0:GHC.Base.Applicative Identity) arising from the superclasses of an instance declaration In the instance declaration for ‘Monad Identity’ λ:4> :info Monad class base-4.8.0.0:GHC.Base.Applicative m => Monad (m :: * -> *) where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a fail :: String -> m a -- Defined in ‘base-4.8.0.0:GHC.Base’ instance Monad (Either e) -- Defined in ‘base-4.8.0.0:Data.Either’ instance Monad Maybe -- Defined in ‘base-4.8.0.0:Data.Maybe’ instance Monad [] -- Defined in ‘base-4.8.0.0:GHC.Base’ instance Monad IO -- Defined in ‘base-4.8.0.0:GHC.Base’ instance Monad ((->) r) -- Defined in ‘base-4.8.0.0:GHC.Base’ λ:5> ``` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9590> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #8182: Parser.y.pp needs special treatment with -fcmm-sink
by GHC 31 Dec '15

31 Dec '15

#8182: Parser.y.pp needs special treatment with -fcmm-sink ------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This bug is really more of a reminder, but it's critical for the 7.8.1 release. Right now, `Parser.y.pp` uses a very weird hack to pass `-fcmm-sink` to the compiler. Here's the relevant comment: {{{ -- CPP tricks because we want the directives in the output of the -- first CPP pass. -- -- Clang note, 6/17/2013 by aseipp: It is *extremely* important (for -- some reason) that there be a line of whitespace between the two -- definitions here, and the subsequent use of __IF_GHC_77__ - this -- seems to be a bug in clang or something, where having the line of -- whitespace will make the preprocessor correctly format the rendered -- lines in the 'two step' CPP pass. No, this is not a joke. #define __IF_GHC_77__ #if __GLASGOW_HASKELL__ >= 707 #define __ENDIF__ #endif __IF_GHC_77__ -- Required on x86 to avoid the register allocator running out of -- stack slots when compiling this module with -fPIC -dynamic. {-# OPTIONS_GHC -fcmm-sink #-} __ENDIF__ }}} This is because the parser is first preprocessed before being run with GHC (which again preprocesses,) so we want the resulting `#ifdef` in the final `.hs` file. Things to note: * We really shouldn't be doing this, it's amazingly fragile. I think the correct thing to do is to ensure the build system correctly passes `-fcmm- sink` during the stage[2,3] build. * `./configure.ac` needs to check to see if the bootstrapping compiler is `ghc >= 7.7` (or `7.8`) and if it is, ''also'' pass `-fcmm-sink` during the stage1 build. * This hack needs to be removed once we can rely on >= 7.8 for bootstrap. Probably something like the hypothetical 7.12-7.14 timeframe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3