- ghc-tickets - Haskell.org

[GHC] #14532: Missing constant folding for Numeric.Natural
by GHC 27 Nov '17

27 Nov '17

#14532: Missing constant folding for Numeric.Natural -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- The following Haskell code {{{#!hs module Zero where import Numeric.Natural zero :: Natural zero = 0 }}} generates this Core: {{{#!hs -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} zero1 zero1 = 0 -- RHS size: {terms: 39, types: 12, coercions: 0, joins: 0/0} zero zero = case zero1 of { S# i#_a2c6 -> case tagToEnum# (>=# i#_a2c6 0#) of { False -> underflowError; True -> NatS# (int2Word# i#_a2c6) }; Jp# dt_a2cg -> case uncheckedIShiftRL# (sizeofByteArray# dt_a2cg) 3# of { __DEFAULT -> case sizeofByteArray# dt_a2cg of { __DEFAULT -> NatJ# dt_a2cg; 0# -> underflowError }; 1# -> case indexWordArray# dt_a2cg 0# of wild2_a2ck { __DEFAULT -> NatS# wild2_a2ck } }; Jn# ipv_a2cn -> underflowError } }}} It should instead generate this: {{{#!hs zero = NatS# 0## }}} This kind of code is generated whenever one uses `GHC.TypeLits.natVal`, even at a constant `Nat`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14532> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14449: Type variables allowed to unify in a partial type signature (PartialTypeSignatures)
by GHC 27 Nov '17

27 Nov '17

#14449: Type variables allowed to unify in a partial type signature (PartialTypeSignatures) -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- During a discussion today, Richard discovered the following bug: The function `f` is accepted in GHC 8.2.1 (and HEAD too): {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} f :: a -> b -> _ f x y = [x, y] }}} with the warning: {{{ Bug.hs:3:16: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘[a]’ Where: ‘a’ is a rigid type variable bound by the inferred type of f :: a -> a -> [a] at Bug.hs:4:1-13 • In the type signature: f :: a -> b -> _ | 3 | f :: a -> b -> _ | ^ Ok, 1 module loaded. }}} This is a regression compared to 8.0.1, where the following error is produced (rightly): {{{ Bug.hs:4:12: error: • Couldn't match expected type ‘a’ with actual type ‘b’ ‘b’ is a rigid type variable bound by the inferred type of f :: a -> b -> [a] at Bug.hs:3:6 ‘a’ is a rigid type variable bound by the inferred type of f :: a -> b -> [a] at Bug.hs:3:6 • In the expression: y In the expression: [x, y] In an equation for ‘f’: f x y = [x, y] • Relevant bindings include y :: b (bound at Bug.hs:4:5) x :: a (bound at Bug.hs:4:3) f :: a -> b -> [a] (bound at Bug.hs:4:1) Failed, modules loaded: none. }}} Note that the inferred type of `f` is still correct: `f :: a -> a -> a`, but the type variables `a` and `b` are allowed to unify during inference, and they shouldn't be. If I understood correctly, this implies that when inferring the type of functions with partial type signatures, the type variables are (wrongly) treated as `SigTv`s, instead of skolem constants. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14449> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13110: GHC API allocates memory which is never GC'd
by GHC 27 Nov '17

27 Nov '17

#13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.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: -------------------------------------+------------------------------------- I've run into a very strange sort of memory leak it seems. GHC seems to manage to allocate memory which I cannot get rid of no matter what I try even after all references have disappeared. The allocated memory doesn't show up in heap profiles but is still visibly allocated (as seen in ps or pmap). I discovered this while investigating reports of large memory usage in ghc-mod where this issue is forcing us to dump completion information in a separate process to avoid the allocated memory sticking around for the rest of the user's session. The attached test case demonstrates this problem by first calling `getModuleInfo` for all modules in all visible packages and then just looping forever in `main`. I would expect all memory GHC allocated to be GC'd at this point but this does not happen. When run as {{{ $ ./Leaky -hide-all-packages }}} the test case consumes around 30M of memory on my system, if we however load some large package, say GHC itself {{{ $ ./Leaky -hide-all-packages -package ghc }}} the program will consume around 2-300M of memory which are never deallocated. The behaviour is not related to the loaded package though I tried it with `Cabal` too with the same result though smaller memory usage. At first I thought this might be related to large CAFs with IORefs inside not being GCd for some reason so I tried calling `resetCAFs` from the RTS before entering the loop. This however makes no difference whatsoever. I also tried forcing a major GC just to be save to no avail. Next I speculated that maybe the allocated memory is beyond the GC's control (malloc()ed or something) but looking at the memory map of the process with `pmap $(pgrep Leaky)` that the majority of the memory usage I'm seeing comes from address `0x0000000200000000` which is where the RTS allocates memory AFAIK. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13110> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #14514: Higher-Rank Kinds work in ADT but not GADT
by GHC 27 Nov '17

27 Nov '17

#14514: Higher-Rank Kinds work in ADT but not GADT -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Following code from [https://github.com/goldfirere/triptych/blob/2e21a6be4419873c77a02c9a198379c… Richard's 2016 Haskell Implementors' Workshop talk] (/ [https://arxiv.org/abs/1610.04799 Trees That Grow]) works just fine {{{#!hs {-# Language RankNTypes, KindSignatures, DataKinds, TypeFamilyDependencies, TypeInType #-} import Data.Kind data TagTag = ETagTag | PTagTag data ETag = VarTag data PTag = VarPTag type family Tag (ttag::TagTag) = (res :: Type) | res -> ttag where Tag ETagTag = ETag Tag PTagTag = PTag type WithAnyTag = forall tag. Tag tag -> Type -- data Exp (ext::WithAnyTag) where -- Var :: ext VarTag -> Exp ext data Exp (ext::WithAnyTag) = Var (ext VarTag) }}} but replace `data Exp` with its commented-out GADT brethren and it stops working {{{ $ ghci -ignore-dot-ghci Weird.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Weird.hs, interpreted ) Weird.hs:17:28: error: • Expected kind ‘WithAnyTag’, but ‘ext1’ has kind ‘ETag -> *’ • In the first argument of ‘Exp’, namely ‘ext’ In the type ‘Exp ext’ In the definition of data constructor ‘Var’ | 17 | Var :: ext VarTag -> Exp ext | ^^^ Failed, 0 modules loaded. Prelude> }}} The type synonym can be inlined, makes no difference. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14514> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14518: GHC panic when trying to install Stack-1.5.1 with Cabal.
by GHC 24 Nov '17

24 Nov '17

#14518: GHC panic when trying to install Stack-1.5.1 with Cabal. -------------------------------------+------------------------------------- Reporter: adgalad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 7.10.4 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- cabal: Entering directory '/var/folders/6v/r_hy_wrs5bbfnb4qc4ycxfpw0000gn/T/cabal- tmp-2256/stack-1.5.1' [1 of 1] Compiling Main ( /var/folders/6v/r_hy_wrs5bbfnb4qc4ycxfpw0000gn/T/cabal- tmp-2256/stack-1.5.1/dist/setup/setup.hs, /var/folders/6v/r_hy_wrs5bbfnb4qc4ycxfpw0000gn/T/cabal- tmp-2256/stack-1.5.1/dist/setup/Main.o ) Linking /var/folders/6v/r_hy_wrs5bbfnb4qc4ycxfpw0000gn/T/cabal- tmp-2256/stack-1.5.1/dist/setup/setup ... Configuring stack-1.5.1... Building stack-1.5.1... Preprocessing library stack-1.5.1... [ 1 of 128] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, dist/build/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 128] Compiling Hackage.Security.Client.Repository.HttpLib.HttpClient ( src/Hackage/Security/Client/Repository/HttpLib/HttpClient.hs, dist/build/Hackage/Security/Client/Repository/HttpLib/HttpClient.o ) [ 3 of 128] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, dist/build/Stack/Ghci/Script.o ) [ 4 of 128] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, dist/build/Stack/FileWatch.o ) [ 5 of 128] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, dist/build/System/Process/PagerEditor.o ) [ 6 of 128] Compiling System.Process.Log ( src/System/Process/Log.hs, dist/build/System/Process/Log.o ) [ 7 of 128] Compiling Stack.Types.StringError ( src/Stack/Types/StringError.hs, dist/build/Stack/Types/StringError.o ) [ 8 of 128] Compiling Paths_stack ( dist/build/autogen/Paths_stack.hs, dist/build/Paths_stack.o ) [ 9 of 128] Compiling Path.Find ( src/Path/Find.hs, dist/build/Path/Find.o ) [ 10 of 128] Compiling Path.Extra ( src/Path/Extra.hs, dist/build/Path/Extra.o ) [ 11 of 128] Compiling System.Process.Read ( src/System/Process/Read.hs, dist/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/6v/r_hy_wrs5bbfnb4qc4ycxfpw0000gn/T/ghc2807_0/libghc_69.dylib, 5): no suitable image found. Did find: /var/folders/6v/r_hy_wrs5bbfnb4qc4ycxfpw0000gn/T/ghc2807_0/libghc_69.dylib: malformed mach-o: load commands size (41168) > 32768 /var/folders/6v/r_hy_wrs5bbfnb4qc4ycxfpw0000gn/T/ghc2807_0/libghc_69.dylib: stat() failed with errno=25 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Leaving directory '/var/folders/6v/r_hy_wrs5bbfnb4qc4ycxfpw0000gn/T /cabal-tmp-2256/stack-1.5.1' -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14518> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14262: fdReady cannot wait more than 49 days
by GHC 24 Nov '17

24 Nov '17

#14262: fdReady cannot wait more than 49 days -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: #8684, #13497 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ import System.IO hWaitForInput stdin 4294968296 }}} This code waits for 1 second instead of 49.something days. The culprit: {{{ hWaitForInput :: Handle -> Int -> IO Bool fdReady(..., int msecs, ...) }}} Haskell `Int` is usally 64 bits. C `int` is usually 32 bits. Called here: {{{ ready :: FD -> Bool -> Int -> IO Bool ready fd write msecs = do r <- throwErrnoIfMinus1Retry "GHC.IO.FD.ready" $ fdReady (fdFD fd) (fromIntegral $ fromEnum $ write) (fromIntegral msecs) foreign import ccall safe "fdReady" fdReady :: CInt -> CInt -> CInt -> CInt -> IO CInt }}} We `fromIntegral` `Int` to `CInt` (== `Int32`), overflowing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13157: Opportunity to improve case-of-case
by GHC 24 Nov '17

24 Nov '17

#13157: Opportunity to improve case-of-case -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Consider this code {{{ f g x = (case g x of True -> not False -> id) `seq` True }}} With GHC 8 (and -O) we get this Core {{{ f = \ (@ t_a1rk) (g_aqD :: t -> Bool) (x_aqE :: t) -> case case g_aqD x_aqE of { False -> id @ Bool; True -> not } of { __DEFAULT -> GHC.Types.True } }}} This is obviously bad. The reasoning is in the long, complicated `Note [Single-alternative cases]` in `Simplify.hs`. Happily with join points the entire Note becomes unnecessary; we can delete the special case that this Note describes, and the Note itself. Result: simpler compiler, and more optimal code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13157> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14523: Confusing link error when specifying the same object repeatedly
by GHC 24 Nov '17

24 Nov '17

#14523: Confusing link error when specifying the same object repeatedly -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given {{{foo.hs}}} containing {{{main = print 1}}} and {{{foo.c}}} containing {{{void foo(){} }}}, if you run: {{{ $ ghc foo.o foo.hs C:\Neil\temp\dupe-name>ghc foo.hs foo.o [1 of 1] Compiling Main ( foo.hs, foo.o ) Linking foo.exe ... foo.o:fake:(.data+0x0): multiple definition of `__stginit_Main' foo.o:fake:(.data+0x0): first defined here foo.o:fake:(.data+0x10): multiple definition of `Main_main_closure' foo.o:fake:(.data+0x10): first defined here foo.o:fake:(.text+0x18): multiple definition of `Main_main_info' foo.o:fake:(.text+0x18): first defined here foo.o:fake:(.data+0x30): multiple definition of `ZCMain_main_closure' foo.o:fake:(.data+0x30): first defined here foo.o:fake:(.text+0x88): multiple definition of `ZCMain_main_info' foo.o:fake:(.text+0x88): first defined here foo.o:fake:(.data+0x70): multiple definition of `Main_zdtrModule_closure' foo.o:fake:(.data+0x70): first defined here collect2.exe: error: ld returned 1 exit status `gcc.exe' failed in phase `Linker'. (Exit code: 1) }}} It seems GHC compiles both {{{foo.hs}}} and {{{foo.c}}} to {{{foo.o}}}, and then links {{{foo.o}}} twice. Sometimes {{{foo.hs}}} writes last, sometimes {{{foo.c}}} so the error can change. I found the error quite confusing, until I realised what it was doing. One solution might be before linking {{{.o}}} files GHC does {{{canonicalizePath}}} on all the object files, and if any are duplicates, it raises a cleaner error. That check would also catch {{{ghc foo.hs bar.o bar.o}}} as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14523> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14522: GHC recompilation checker doesn't take account of deprecated pragmas
by GHC 24 Nov '17

24 Nov '17

#14522: GHC recompilation checker doesn't take account of deprecated pragmas -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given the sources: {{{#!hs -- A.hs -------------------- module A -- {-# DEPRECATED "bad" #-} where a = 1 }}} {{{#!hs -- B.hs -------------------- module B where import A }}} I get the interactions: {{{ $ ghc B [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling B ( B.hs, B.o ) $ manually edit A.hs to uncomment the deprecated line $ ghc B [1 of 2] Compiling A ( A.hs, A.o ) $ touch B.hs $ ghc B [2 of 2] Compiling B ( B.hs, B.o ) B.hs:2:1: warning: [-Wdeprecations] Module `A' is deprecated: bad | 2 | import A | ^^^^^^^^ }}} Observe that after editing the deprecated pragma in {{{A.hs}}} GHC didn't recompile {{{B.hs}}}, meaning that the warning only appeared after I touch'd {{{B.hs}}}. Turning on {{{-Werror}}} turns the problem from one of incorrectly missing warnings to one of incorrect compilation results. I was also got the same results when adding a deprecated pragma to an individual function. My guess is whatever {{{.hi}}} hash you take for recompilation checking should include deprecated pragmas. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14522> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14517: ghc: panic! (the 'impossible' happened)
by GHC 23 Nov '17

23 Nov '17

#14517: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: KtorZ | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Apparently not so impossible. I am just filling a bug following the advice of GHC. Here's the error message coming out of GHC {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] liftIO_a2jc :: t_a2jb[tau:1] (CHoleCan: liftIO) [W] handleMsg_a2k6 :: t_a2k5[tau:1] (CHoleCan: handleMsg) [W] expectTimeout_a2kb :: t_a2ka[tau:1] (CHoleCan: expectTimeout) [W] sendMsg_a2v9 :: t_a2v8[tau:1] (CHoleCan: sendMsg) [W] tick_a2vc :: t_a2vb[tau:1] (CHoleCan: tick)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} And here the corresponding code that leads to this compilation error: {{{ module Main where import Control.Distributed.Process (NodeId (..), Process) import Control.Monad (forever) import Data.IORef (IORef, newIORef) type Clock = Int emitRandomNumbers :: [NodeId] -> Process () emitRandomNumbers nodes = do clock <- liftIO $ newIORef (0 :: Clock) forever $ do msg <- handleMsg <$> expectTimeout 0 sendMsg <$> tick }}} I am compiling on with GHC 8.0.2 on Ubuntu 16.04, here are a list of the install dependencies: {{{ array 0.5.1.1 base 4.9.1.0 binary 0.8.3.0 bytestring 0.10.8.1 containers 0.5.7.1 data-accessor 0.2.2.7 deepseq 1.4.2.0 distributed-process 0.7.3 distributed-static 0.3.8 exceptions 0.8.3 getting-started 0.1.0.0 ghc-boot-th 8.0.2 ghc-prim 0.5.0.0 hashable 1.2.6.1 integer-gmp 1.0.0.1 mtl 2.2.1 network 2.6.3.2 network-transport 0.4.4.0 network-transport-tcp 0.5.1 pretty 1.1.3.3 random 1.1 rank1dynamic 0.3.3.0 rts 1.0 stm 2.4.4.1 syb 0.7 template-haskell 2.11.1.0 text 1.2.2.2 time 1.6.0.1 transformers 0.5.2.0 transformers-compat 0.5.1.4 unix 2.7.2.1 }}} Let me know should you need any additional informations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14517> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1