July 2016 - ghc-tickets

[GHC] #10860: The test `setnumcapabilities001` sometimes fails on Phabricator
by GHC 13 Oct '16

13 Oct '16

#10860: The test `setnumcapabilities001` sometimes fails on Phabricator -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ setnumcapabilities001: internal error: ASSERTION FAILED: file rts/Schedule.c, line 406 }}} https://phabricator.haskell.org/harbormaster/build/5890/ Here it just timed out: https://phabricator.haskell.org/harbormaster/build/5904/?l=0 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10860> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12439: DeriveDataTypeable - deriving Data for several type constructor applications
by GHC 13 Oct '16

13 Oct '16

#12439: DeriveDataTypeable - deriving Data for several type constructor applications -------------------------------------+------------------------------------- Reporter: lspitzner | 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DeriveDataTypeable, StandaloneDeriving #-} import qualified Data.Data data Mu f = Mu (f (Mu f)) deriving instance Data.Data.Data (Mu []) deriving instance Data.Data.Data (Mu IO) }}} produces {{{ Multiple declarations of ‘$t3Ecq4GuAmh1HtkHHwEpyjp’ [..] Multiple declarations of ‘$c3Ecq4GuAmh1HtkHHwEpyjp’ [..] Duplicate type signatures for ‘$t3Ecq4GuAmh1HtkHHwEpyjp’ [..] Duplicate type signatures for ‘$c3Ecq4GuAmh1HtkHHwEpyjp’ [..] }}} As a workaround one can define instances in separate modules. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12439> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12124: Ambiguous type variable: it's a red herring!
by GHC 13 Oct '16

13 Oct '16

#12124: Ambiguous type variable: it's a red herring! -------------------------------------+------------------------------------- Reporter: drb226 | 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: -------------------------------------+------------------------------------- {{{ module Ret where data Whoops = Whoops Int Int foo :: Maybe Int foo = return (case Whoops 1 2 of Whoops a -> a _ -> 0) }}} Note that there is a pattern match error in the case statement, which the compiler correctly reports. However, it first reports the following red herring: {{{ ret.hs:6:7: error: • Ambiguous type variable ‘m0’ arising from a use of ‘return’ prevents the constraint ‘(Monad m0)’ from being solved. Probable fix: use a type annotation to specify what ‘m0’ should be. These potential instances exist: instance Monad IO -- Defined in ‘GHC.Base’ instance Monad Maybe -- Defined in ‘GHC.Base’ instance Monad ((->) r) -- Defined in ‘GHC.Base’ ...plus two others (use -fprint-potential-instances to see them all) • In the expression: return (case Whoops 1 2 of { Whoops a -> a _ -> 0 }) In an equation for ‘foo’: foo = return (case Whoops 1 2 of { Whoops a -> a _ -> 0 }) }}} One would think that the context `foo :: Maybe Int` is sufficient for the compiler to realize that `return (blah)` implies that m0 = Maybe, regardless of the errors involved in the expression `(blah)`. ghc 7.10.3 does not report this red herring. One can get a similar red- herring type error in ghc 7.10.3 by replacing `return (...)` with `return $ ...` in the example above. The red herring also does *not* appear, in ghc 7.10.3 or in ghc 8.0.1, if you name the broken case expression with a let binding. {{{ module Ret where data Whoops = Whoops Int Int foo :: Maybe Int foo = return boo where boo = case Whoops 1 2 of Whoops a -> a _ -> 0 }}} There seems to be something fishy going on here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12124> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12048: Allow CustomTypeErrors in type synonyms (+ evaluate nested type family?)
by GHC 12 Oct '16

12 Oct '16

#12048: Allow CustomTypeErrors in type synonyms (+ evaluate nested type family?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple CustomTypeErrors | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I didn't find a ticket with this, but with wiki:CustomTypeErrors you can't define a type synonym without it erroring: {{{#!hs -- error: … -- • onetwothree -- • In the type synonym declaration for ‘ERROR’ -- Compilation failed. type ERROR = TypeError (Text "onetwothree") }}} but I often want to abstract over error messages since they are clunky to write at the type level and I often use a similar message in many different type families, especially when they can be determined by a type family. Here's a hypothetical example: {{{#!hs type family Whoami (ty :: Type) :: Symbol where Whoami Int = "a number" Whoami Float = "a number" Whoami [_] = "a list of things" Whoami _ = "something else" }}} I would like to write {{{#!hs type Error ty = TypeError (Text "Expected a <...> but got ":<>: Text (Whoami ty)) }}} ---- Even when ‘inlined’, it displays `Expected a GRUE but got 'Text (Whoami Int)` and not `• Expected a GRUE but got a number.`: {{{#!hs a :: TypeError (Text "Expected a GRUE but got ":<>: Text (Whoami Int)) a = 'a' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10458: GHCi fails to load shared object (the 'impossible' happened)
by GHC 10 Oct '16

10 Oct '16

#10458: GHCi fails to load shared object (the 'impossible' happened) -----------------------------------------+--------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- I have a project that uses two external libraries, namely `-lcrypt` and `-lpcre`. Building with `cabal` and running the resulting executable works as expected, but I'm having trouble starting a REPL in GHCi: {{{ % cabal repl Preprocessing executable 'etamoo' for EtaMOO-0.2.1.0... GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help /usr/bin/ld: dist/build/etamoo/etamoo-tmp/src/cbits/crypt.o: relocation R_X86_64_PC32 against undefined symbol `crypt' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status }}} The error suggests I need `-fPIC`, and this seems to help the `-lcrypt` case, but now I get: {{{ % cabal repl --ghc-options="-fPIC" Preprocessing executable 'etamoo' for EtaMOO-0.2.1.0... GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc21539_0/libghc21539_2.so: undefined symbol: pcre_callout Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} FYI the C type of `pcre_callout` is a little unusual: {{{ extern int (*pcre_callout)(pcre_callout_block *); }}} In other words it is a global variable (pointer to function), not a function itself. Any advice is welcome, including the proper way to start GHCi given these external dependencies, as well as on this apparent bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10458> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 46

[GHC] #9877: ForeignImport coercion evaluated before typechecking
by GHC 09 Oct '16

09 Oct '16

#9877: ForeignImport coercion evaluated before typechecking -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Under Windows 8.1 x64 with Haskell Platform 2014.02 and EclipseFP I got: buildwrapper.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): ForeignImport coercion evaluated before typechecking on the first line of file that has: {{{ #!div style="font-size: 80%" Code highlighting: {{{#!haskell {-# LANGUAGE ForeignFunctionInterface, RankNTypes, OverloadedStrings, ScopedTypeVariables #-} module Persist( persistWrite, persistRead ) where import System.Win32.Types import Graphics.Win32.GDI.Types import Foreign.C.String import Foreign.Marshal.Array import Control.Exception foreign import ccall unsafe "SHGetFolderPathW" cSHGetFolderPathW :: HWND -> INT -> HANDLE -> DWORD -> CWString -> IO LONG }}} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9877> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10881: internal error: evacuate: strange closure type 5101248
by GHC 09 Oct '16

09 Oct '16

#10881: internal error: evacuate: strange closure type 5101248 -------------------------------------+------------------------------------- Reporter: burbly | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: strange | Operating System: Windows closure type 5101248 | Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Running a compiled executable on some complex input is causing this: postparse.exe: internal error: evacuate: strange closure type 5101248 (GHC version 7.10.2 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Running under Cygwin on Windows 8.1, 64. I suspect this may be a memory-related issue, but it's hard to diagnose as postparse.exe is operating in a larger ecosystem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10881> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11153: building lens-4.12.3 impossible happened: dupe _hs_primitive_memcpy
by GHC 09 Oct '16

09 Oct '16

#11153: building lens-4.12.3 impossible happened: dupe _hs_primitive_memcpy -----------------------------------------+--------------------------------- Reporter: blippy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -----------------------------------------+--------------------------------- I issued the command: stack install lens hoping to upgrade to lens-4.13 and I received the following error log: GHC runtime linker: fatal error: I found a duplicate definition for symbol _hsprimitive_memcpy whilst processing object file C:\apps\HaskellPlatform\7.10.2-a\lib\extralibs\primitive-0.6\HSprimitive-0.6-3d4UsQu7pJCEtlsxN3gLjk.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for i386-unknown-mingw32): loadObj "C:\\apps\\HaskellPlatform\\7.10.2-a\\lib\\extralibs\\primitive-0.6\\HSprimitive-0.6-3d4UsQu7pJCEtlsxN3gLjk.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11153> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12171: cygwin - option to accept ISO C99... unsupported
by GHC 09 Oct '16

09 Oct '16

#12171: cygwin - option to accept ISO C99... unsupported -------------------------------------+------------------------------------- Reporter: wozgonon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Building GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tried to build Haskell under cygwin under Windows 10 (x86_64) but /configure failed. I had a look on google and through the bug tracker but could not find anything helpful. Note that in the output from ./configure check two versions of gcc.exe 1) ... /ghc/inplace/mingw/bin/gcc.exe 2) C:/Program Files/Haskell Platform/8.0.1/lib/../mingw/bin/gcc.exe The check for the first succeeds but that for the second fails yet they both seem to be the same version of gcc.exe: (realgcc.exe (Rev3, Built by MSYS2 project) 5.2.0) {{{ checking for C:/unix/cygwin64/home/jb/haskell/ghc/inplace/mingw/bin/gcc.exe option to accept ISO C99... none needed checking for C:/Program Files/Haskell Platform/8.0.1/lib/../mingw/bin/gcc.exe option to accept ISO C99... unsupported }}} {{{ $ C:/unix/cygwin64/home/jb/haskell/ghc/inplace/mingw/bin/gcc.exe --version realgcc.exe (Rev3, Built by MSYS2 project) 5.2.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. jb@fabulord ~/haskell/ghc $ "C:/Program Files/Haskell Platform/8.0.1/lib/../mingw/bin/gcc.exe" --version realgcc.exe (Rev3, Built by MSYS2 project) 5.2.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12171> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11591: thread blocked indefinitely in an MVar operation
by GHC 09 Oct '16

09 Oct '16

#11591: thread blocked indefinitely in an MVar operation --------------------------------------+------------------------------- Reporter: PaulNibin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- *Main> take 24 [13,26..] [13,26,39,52,65,78,91,104,117,130,143,156,169,182,195,208,221,234,247,260,273,286,299,312] *Main> cycle [1,2,3] [1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2, *Main> *Main> *Main> *Main> take 10 (cycle [1,2,3]) [1,2,3,1,2,3,1,2,3,1] *Main> take 10 (cycle "Hel) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.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/11591> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2