June 2017 - ghc-tickets

[GHC] #13093: Runtime linker chokes on LLVM function on Windows
by GHC 19 Aug '17

19 Aug '17

#13093: Runtime linker chokes on LLVM function on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This error prevents the [http://hackage.haskell.org/package/llvm-general llvm-general] library from loading in GHCi on Windows. I don't know how to reproduce this error without using LLVM. First, you need to install LLVM. On Windows, you can install it with MSYS2: {{{ pacman -S mingw-w64-x86_64-llvm }}} Currently, this gives you LLVM-3.9, although I've reproduced it with LLVM-3.8 as well. Now define this Haskell file: {{{#!hs module Main (main) where import Foreign.C.Types newtype LLVMBool = LLVMBool CUInt deriving Show foreign import ccall unsafe "LLVMIsMultithreaded" isMultithreaded :: IO LLVMBool main :: IO () main = isMultithreaded >>= print }}} If you compile it, it works OK: {{{ $ ghc LLVM.hs -fforce-recomp $(llvm-config --libs) $(llvm-config --system- libs) -lstdc++-6 -lgcc_s_seh-1 [1 of 1] Compiling Main ( LLVM.hs, LLVM.o ) Linking LLVM.exe ... $ ./LLVM LLVMBool 1 }}} Or, if you're allergic to `llvm-config`: {{{ $ ghc LLVM.hs -fforce-recomp -lLLVMLTO -lLLVMObjCARCOpts -lLLVMSymbolize -lLLVMDebugInfoPDB -lLLVMDebugInfoDWARF -lLLVMGlobalISel -lLLVMCoverage -lLLVMTableGen -lLLVMLineEditor -lLLVMOrcJIT -lLLVMMIRParser -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMObjectYAML -lLLVMLibDriver -lLLVMOption -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMDebugInfoCodeView -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMPasses -lLLVMipo -lLLVMVectorize -lLLVMLinker -lLLVMIRReader -lLLVMAsmParser -lLLVMInterpreter -lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMObject -lLLVMMCParser -lLLVMCodeGen -lLLVMTarget -lLLVMScalarOpts -lLLVMInstCombine -lLLVMInstrumentation -lLLVMTransformUtils -lLLVMMC -lLLVMBitWriter -lLLVMBitReader -lLLVMAnalysis -lLLVMProfileData -lLLVMCore -lLLVMSupport -lpsapi -lshell32 -lole32 -luuid -lstdc++-6 -lgcc_s_seh-1 [1 of 1] Compiling Main ( LLVM.hs, LLVM.o ) Linking LLVM.exe ... $ ./LLVM LLVMBool 1 }}} If you load it into GHCi, however, things go awry: {{{ $ ghci $(llvm-config --libs) $(llvm-config --system-libs) -lgcc_s_seh-1 GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from C:\Users\RyanGlScott\AppData\Roaming\ghc\ghci.conf Ok, modules loaded: Main (LLVM.o). > main ghc.exe: LLVM.o: unknown symbol `LLVMIsMultithreaded' }}} On GHC 8.0.1 and HEAD, it's a slightly different error: {{{ > main ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: LLVMIsMultithreaded This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13093> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #13815: Support Windows big-obj format
by GHC 19 Aug '17

19 Aug '17

#13815: Support Windows big-obj format -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 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): Phab:D3523 | Wiki Page: -------------------------------------+------------------------------------- By default, an object file can hold up to 65,536 (2^16) addressable sections. This is the case no matter which target platform is specified. /bigobj increases that address capacity to 4,294,967,296 (2^32). Most modules will never generate an .obj file that contains more than 65,536 sections. However, machine generated code, or code that makes heavy use of template libraries may require .obj files that can hold more sections. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13815> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13399: Location of `forall` matters with higher-rank kind polymorphism
by GHC 18 Aug '17

18 Aug '17

#13399: Location of `forall` matters with higher-rank kind polymorphism -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code fails to compile, but probably should: {{{ {-# LANGUAGE RankNTypes, TypeInType #-} import Data.Kind data Foo :: forall k . (* -> *) -> k -> * -- Decl 1 class C (a :: forall k . k -> *) instance C (Foo a) -- error on this line }}} with the error {{{ • Expected kind ‘forall k. k -> *’, but ‘Foo a’ has kind ‘k0 -> *’ • In the first argument of ‘C’, namely ‘Foo a’ In the instance declaration for ‘C (Foo a)’ }}} Similarly, the following declarations of `Foo` also cause a similar error at the instance declaration: Decl 2: `data Foo :: (* -> *) -> k -> *` Decl 3: `data Foo (a :: * -> *) (b :: k)` However, if I move the `forall` to a point ''after'' the first type parameter (which is where the instance is partially applied) thusly: Decl 4: `data Foo :: (* -> *) -> forall k . k -> *` then GHC happily accepts the instance of `C`. From my (admittedly negligible) knowledge of type theory, the signatures for Decls 1 and 4 (and 2) are identical, since the `forall` can be floated to the front of Decl 4. GHC should accept any of the four versions of `Foo`, since they are all equivalent. As a side note, I was surprised to discover that the syntax for Decl 4 is even allowed. What is the point of allowing a "global"/rank-1 forall anywhere but at the left edge of the signature (other than as a convenient workaround for this bug)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13399> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows
by GHC 18 Aug '17

18 Aug '17

#12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- Relevant code: {{{ -- | @setEnv name value@ sets the specified environment variable to @value@. -- -- On Windows setting an environment variable to the /empty string/ removes -- that environment variable from the environment. For the sake of -- compatibility we adopt that behavior. In particular -- -- @ -- setEnv name \"\" -- @ -- -- has the same effect as -- -- @ -- `unsetEnv` name -- @ }}} This sounds nice and authoritative... and it's also not true. https://msdn.microsoft.com/en- us/library/windows/desktop/ms686206(v=vs.85).aspx states that only if the pointer is NULL (as opposed to an empty string) is the environment variable deleted. https://github.com/golang/go/issues/5610 corroborates So `setEnv` has been given bogus semantics that don't make sense because empty environment variables ARE supported on Windows. My suggestion is to just fix this so that setEnv takes empty environment variables. But this would be a BC breaking change. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12494> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13901: Lift the "Illegal polymorphic type" restriction on type families
by GHC 18 Aug '17

18 Aug '17

#13901: Lift the "Illegal polymorphic type" restriction on type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11962 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, I can do this: {{{#!hs type Foo = forall a. Maybe a }}} But if I try to refactor this to an equivalent type family: {{{#!hs type family Foo where Foo = forall a. Maybe a }}} Then GHC complains: {{{ • Illegal polymorphic type: forall a. Maybe a • In the equations for closed type family ‘Foo’ In the type family declaration for ‘Foo’ }}} We should lift this restriction. This would be necessary, for instance, to implement #11962. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13901> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11975: New GHCi command to print out the type of an expression without instantiating
by GHC 18 Aug '17

18 Aug '17

#11975: New GHCi command to print out the type of an expression without instantiating -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.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: -------------------------------------+------------------------------------- #11376 changed the meaning of `:type` to deeply instantiate a type before printing. This means that we can't see which variables were specified and which were inferred. I propose `:type-spec` (please suggest a better name) that does not instantiate first. Phab patch to be posted shortly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11975> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11587: Place shared objects in LIBDIR
by GHC 18 Aug '17

18 Aug '17

#11587: Place shared objects in LIBDIR -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Package | Version: 7.10.3 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If one compiles a program with `-dynamic`, the resulting executable includes in its `rpath` the library directory of every Haskell package that the program links against. This causes a significant number of excess system calls at program start-up. For instance, in the case of a dynamically linked `ghc` executable on Debian 8, compiling a trivial "hello world" application produces over 800 `open` calls, the majority of which originate from the dynamic linker. e.g., {{{ $ strace -f -e open ghc-7.10.3 -c -fforce-recomp Test.hs 2>&1 | grep open ... open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) ... }}} The dynamic linker must look in nearly 25 Haskell library directories to locate every system library! This is madness. Instead of placing each shared library in its own directory, `$LIBDIR/$PKG_KEY/lib$PKG_KEY.so` as we do currently, why not just place them in `$LIBDIR`, e.g. `$LIBDIR/libPKG_KEY.so`. This would mean that we need to include only one directory, `$LIBDIR`, in `rpath`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11587> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11785: Kinds should be treated like types in TcSplice
by GHC 17 Aug '17

17 Aug '17

#11785: Kinds should be treated like types in TcSplice -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Template | Version: 8.1 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: -------------------------------------+------------------------------------- !TcSplice handles kinds differently than types. Now that they are the same, it's probably best to rewrite this code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11785> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12087: Inconsistency in GADTs?
by GHC 17 Aug '17

17 Aug '17

#12087: Inconsistency in GADTs? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: GADTs | 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 f :: Ord a => Eq a => a -> Bool f = … }}} this is allowed but not in GADTs {{{#!hs data F a where MkF :: Ord a => Eq a => a -> F a -- <interactive>:48:16: error: -- • Data constructor ‘MkF’ returns type ‘Eq a => a -> F a’ -- instead of an instance of its parent type ‘F a’ -- • In the definition of data constructor ‘MkF’ -- In the data type declaration for ‘F’ }}} not a big deal -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12087> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10807: PatternGuards and MultiWayIf layout rules
by GHC 17 Aug '17

17 Aug '17

#10807: PatternGuards and MultiWayIf layout rules -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The layout rules for MultiWayIf currently require any lines starting with a comma to be further indented than the lines starting with a pipe when used in conjunction with PatternGuards. This is inconsistent with the examples given in [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax- extns.html#pattern-guards]. For instance, we can't use the same indentation in the second example as in the first without triggering a parser error. {{{#!hs {-# LANGUAGE PatternGuards, MultiWayIf fine a pred | Just x <- a , pred x = True | otherwise = False notFine a pred = if | Just x <- a , pred x -> True | otherwise -> False }}} Though the documentation isn't ''incorrect'', if this intentional it could be pointed out, since it's counterintuitive. Otherwise, if there's no reason for MulitWayIf to require further indentation that should be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10807> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11