July 2017 - ghc-tickets

[GHC] #13860: TODO: SMALL_MUT_ARR_PTRS in Compact.cmm
by GHC 24 Aug '17

24 Aug '17

#13860: TODO: SMALL_MUT_ARR_PTRS in Compact.cmm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.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): | Wiki Page: -------------------------------------+------------------------------------- While looking at `Compact.cmm` I noticed that the small mutable array compaction cases are currently TODOs. Presumably this should be addressed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13860> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13702: GHC can't produce position independent executables
by GHC 23 Aug '17

23 Aug '17

#13702: GHC can't produce position independent executables -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- Due to #12759 we unconditionally pass `-no-pie` to GCC. However, there are legitimate reasons to want a PIE. We should have a `-fPIE` flag to match `-fPIC`, requesting that the compiler produce a position-independent executable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13702> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13902: Misleading function arity mismatch error with TypeApplications
by GHC 22 Aug '17

22 Aug '17

#13902: Misleading function arity mismatch error with TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeApplications #-} f :: a -> a f x = x g :: Int g = f @Int 42 5 }}} {{{ GHCi, version 8.3.20170614: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:7:5: error: • Couldn't match expected type ‘Integer -> Int’ with actual type ‘Int’ • The function ‘f’ is applied to three arguments, but its type ‘Int -> Int’ has only one In the expression: f @Int 42 5 In an equation for ‘g’: g = f @Int 42 5 | 7 | g = f @Int 42 5 | ^^^^^^^^^^^ }}} That error message is quite confusing to read, since it reports that: * `f` is applied to three arguments, which //includes// a visible type application * `f` only has one argument, which //excludes// the visible type application We ought to be able to do better. My suggestion would be to report this instead: {{{ • The function ‘f @Int’ is applied to two arguments, but its type ‘Int -> Int’ has only one In the expression: f @Int 42 5 In an equation for ‘g’: g = f @Int 42 5 }}} Although I'm sure there are other ways the same information could be conveyed (e.g., `The function ‘f’ is applied to two value arguments`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13902> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12874: Read/Show Incompatibility in base
by GHC 22 Aug '17

22 Aug '17

#12874: Read/Show Incompatibility in base -------------------------------------+------------------------------------- Reporter: andrewthad | 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: -------------------------------------+------------------------------------- I just stumbled across a situation where the deriving machinery, in combination with types provided by base, produces Show/Read instances that are incompatible. Here is a minimal example: {{{#!hs import Data.Proxy main :: IO () main = do x <- readLn print (x :: Thing (Proxy Int)) data Thing a = Thing a deriving (Read,Show) }}} If you run this program and type "Thing Proxy" into standard in, you get a parse error. If you type in "Thing (Proxy)", it works fine. Calling `show` on `Thing Proxy` gives the string "Thing Proxy" though. So, `read . show =/= id` in this case. This might just be an issue with `Proxy`'s Read instance, but I'm not really sure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12874> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11400: * is not an indexed type family
by GHC 21 Aug '17

21 Aug '17

#11400: * is not an indexed type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- I can't seem to create an indexed data family using the kind `*` with `-XTypeInType` enabled. I have to work around it by using `Type`: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160108: http://www.haskell.org/ghc/ :? for help λ> :set -XTypeInType -XTypeFamilies λ> import Data.Kind λ> data family IdxProxy k (a :: k) λ> data instance IdxProxy * a <interactive>:5:1: error: • Illegal family instance for ‘*’ (* is not an indexed type family) • In the data instance declaration for ‘*’ λ> data instance IdxProxy Type a λ> :kind! IdxProxy * IdxProxy * :: * -> * = IdxProxy * λ> :kind! IdxProxy Type IdxProxy Type :: Type -> * = IdxProxy Type }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11400> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13636: Enable -Wcpp-undef
by GHC 19 Aug '17

19 Aug '17

#13636: Enable -Wcpp-undef -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- e5b3492f23c2296d0d8221e1787ee585331f726e tried (again) to enable `-Wcpp- undef` in `mk/warnings.mk`, {{{#!make SRC_HC_OPTS_STAGE1 += $(WERROR) #-Wcpp-undef SRC_HC_OPTS_STAGE2 += $(WERROR) #-Wcpp-undef }}} Unfortunately, this caused build failures in boot libraries on some platforms (e.g. `time` on Darwin). Resolve these and reenable `-Wcpp- undef`. An alternative would be to instead only add `-Wcpp-undef` to `GhcRtsHcOpts`, `GhcStage1HcOpts` and `GhcStage2HcOpts`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13636> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12155: Description of flags cut off
by GHC 19 Aug '17

19 Aug '17

#12155: Description of flags cut off -------------------------------------+------------------------------------- Reporter: mikail | Owner: Type: task | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.0.1 Keywords: flags | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The description of the flags from pages 104 to 110 are cut off in the PDF version of the User Guide. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12155> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[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