February 2018 - ghc-tickets

[GHC] #14710: GHC 8.4.1-alpha allows the use of kind polymorphism without PolyKinds
by GHC 19 Apr '18

19 Apr '18

#14710: GHC 8.4.1-alpha allows the use of kind polymorphism without PolyKinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 (Type checker) | Keywords: PolyKinds | 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: -------------------------------------+------------------------------------- This program: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# OPTIONS_GHC -ddump-deriv #-} module Bug where import Data.Coerce import Data.Proxy class C a b where c :: Proxy (x :: a) -> b newtype I a = MkI a instance C x a => C x (Bug.I a) where c = coerce @(forall (z :: x). Proxy z -> a) @(forall (z :: x). Proxy z -> I a) c }}} is rightfully rejected by GHC 8.2.2: {{{ $ /opt/ghc/8.2.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:20:16: error: Unexpected kind variables Perhaps you intended to use PolyKinds In a type argument | 20 | c = coerce @(forall (z :: x). Proxy z -> a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:21:16: error: Unexpected kind variables Perhaps you intended to use PolyKinds In a type argument | 21 | @(forall (z :: x). Proxy z -> I a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But GHC 8.4.1-alpha2 actually //accepts// this program! {{{ $ /opt/ghc/8.4.1/bin/ghci Bug.hs GHCi, version 8.4.0.20180118: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, one module loaded. }}} This is almost certainly bogus. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14710> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14689: Load order of .ghci config files is counterintuitive
by GHC 18 Apr '18

18 Apr '18

#14689: Load order of .ghci config files is counterintuitive -------------------------------------+------------------------------------- Reporter: hal9zillion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14250, #6017 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Basically ghci seems to give precedence to global .ghci conguration settings by applying them after any local/project specific .ghci files: https://github.com/ghc/ghc/blob/314bc31489f1f4cd69e913c3b1e33236b2bdf553/gh… OTOH there are a couple of open issues where people dont like the idea of local ghci evaluation for security reasons: #6017 #14250 I suggest the following resolution: - Change the order or evaluation from global first to local - include a new ghci setting that prevents/enables the evaluation of local/project specific .ghci files for people who wish to avoid the security concerns some people have - This flag can then be set in the global .ghci file I believe this would both address the counterintuitive loading strategy implied currently (i was convinced local .ghci files didnt work because when i changed the prompt it was always overwritten by my global config) and the security question. The only question then would be if evaluation of project/local .ghci files would be on or off by default. I would favour the former but that is just personal preference. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14689> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop
by GHC 17 Apr '18

17 Apr '18

#12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This worked in GHC 7.6.3, but ever since GHC 7.8, this code will cause the typechecker to loop infinitely: {{{#!hs {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} module Bug where class C a b | a -> b where c :: a -> Int newtype Foo a = Foo a deriving (C b) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12860> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files
by GHC 17 Apr '18

17 Apr '18

#9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files ------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I have a package that bundles in C library sources. I never had a problem with this when using GHC 7.6. In GHC 7.8, the order of the c-sources in the cabal file now matters. Sources must be listed earlier if they have symbols that subsequently loaded object files will need. If the c-sources are in the wrong order, when running "cabal repl" I get Loading object (static) dist/build/decnumber/src/decQuad.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc14294_0/ghc14294_1.so: undefined symbol: DECSTICKYTAB Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug When using the same code and cabal file with GHC 7.6, "cabal repl" works fine: GHCi loads each static object (regardless of ordering in the cabal file), links up the necessary symbols, and launches successfully. Haskell Cafe discussion here: http://www.haskell.org/pipermail/haskell-cafe/2014-May/114041.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9074> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11045: Loading temp shared object failed - undefined symbol
by GHC 17 Apr '18

17 Apr '18

#11045: Loading temp shared object failed - undefined symbol -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While re-compiling [https://github.com/commercialhaskell/stack stack]: {{{ $ stack install --ghc-options -O2 stack-0.1.7.0: configure Configuring stack-0.1.7.0... stack-0.1.7.0: build Preprocessing library stack-0.1.7.0... [30 of 74] Compiling Stack.Types.Docker ( src/Stack/Types/Docker.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Docker.o ) [31 of 74] Compiling Options.Applicative.Complicated ( src/Options/Applicative/Complicated.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Options/Applicative/Complicated.o ) [32 of 74] Compiling Stack.Types.Config ( src/Stack/Types/Config.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Config.o ) [33 of 74] Compiling Stack.Constants ( src/Stack/Constants.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Constants.o ) [Stack.Types.Config changed] [34 of 74] Compiling Stack.Types.Internal ( src/Stack/Types/Internal.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Internal.o ) [Stack.Types.Config changed] [35 of 74] Compiling Stack.Types.StackT ( src/Stack/Types/StackT.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/StackT.o ) [36 of 74] Compiling Stack.Docker.GlobalDB ( src/Stack/Docker/GlobalDB.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Docker/GlobalDB.o ) [Stack.Types.Config changed] [37 of 74] Compiling Stack.Types.Package ( src/Stack/Types/Package.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Package.o ) [Stack.Types.Config changed] [38 of 74] Compiling Stack.Types.Build ( src/Stack/Types/Build.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types/Build.o ) [39 of 74] Compiling Stack.Types ( src/Stack/Types.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/Types.o ) [Stack.Types.Build changed] [40 of 74] Compiling Stack.GhcPkg ( src/Stack/GhcPkg.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/GhcPkg.o ) [Stack.Constants changed] [41 of 74] Compiling Stack.PackageIndex ( src/Stack/PackageIndex.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Stack/PackageIndex.o ) [Data.Binary.VersionTagged changed] ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc22553_0/libghc_96.so: undefined symbol: stackzuFHzzONQT9HI3ATX2xQH198L_StackziTypesziCompiler_zdfBinaryCompilerVersionzuzdszdfGSumM2_closure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building package stack-0.1.7.0 using: /home/simon/.stack/setup-exe-cache/setup-Simple- Cabal-1.22.4.0-x86_64-linux-ghc-7.10.2 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.22.4.0/ build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 $ git show commit 2fb2d11fffddde3c44920f7ea93e34b9d3195dad Author: Emanuel Borsboom <manny(a)fpcomplete.com> Date: Sun Nov 1 05:21:16 2015 -0800 <snip> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11499: Loading temp shared object failed in GHCi
by GHC 17 Apr '18

17 Apr '18

#11499: Loading temp shared object failed in GHCi --------------------------------------+------------------------------- Reporter: alfa07 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- While trying to launch ghci got the following error: ❯ stack ghci The following GHC options are incompatible with GHCi and have not been passed to it: -threaded -Odph Using main module: 1. Package `line-segment-intersection' component exe:demo with main-is file: /Users/maxim/Dev/ComputationGeometry/LineSegmentIntersection/app/Main.hs Configuring GHCi with the following packages: line-segment-intersection, GLUT, GLUtil, boundingboxes, freetype-simple, freetype2 GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib, 5): Symbol not found: _bdf_driver_class Referenced from: /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib Expected in: flat namespace in /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11499> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12982: Missed constant folding oportunities
by GHC 17 Apr '18

17 Apr '18

#12982: Missed constant folding oportunities -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: | Version: 8.0.1 libraries/hoopl | 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: -------------------------------------+------------------------------------- A work colleague of mine found that some expressions were not being constant folded as expected. For example: {{#!hs module Test where import Data.Int number :: Int64 number = 2 ^ 10 - 3 }}} compiled using: {{{ ghc -O2 -keep-s-file -c test.hs }}} should result in an assembler file containing the constant `1021` but doesn't. However, if I change the above expression to: {{{ number = 1024 -3 }}} then the output assembler files does contain the value `1021`. I did a bit of a search and found some constant folding code in the `hoopl` library, but that doesn't seem to be what GHC actually uses. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12982> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11117: mdo blocks in error messages are shown modified
by GHC 17 Apr '18

17 Apr '18

#11117: mdo blocks in error messages are shown modified -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE RecursiveDo #-} main = mdo Just x <- return (Right x) return () }}} gives {{{ MdoTypeError.hs:3:3: Couldn't match expected type ‘Either a0 b0’ with actual type ‘Maybe b0’ Relevant bindings include x :: b0 (bound at MdoTypeError.hs:3:8) In the pattern: Just x In a stmt of an 'mdo' block: Just x <- return (Right x) In a stmt of an 'mdo' block: rec { Just x <- return (Right x) } }}} Note that the error message mentions `rec` even though that is not what the user entered. In other instances, we are careful to show the code more similar to the original (e.g. `do`-notation instead of `>>=`). This should also be done here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11117> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14750: Plugins should be loaded once for each module rather than multiple times
by GHC 16 Apr '18

16 Apr '18

#14750: Plugins should be loaded once for each module rather than multiple times -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: plugins | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Plugins are currently loaded immediately before they are used in the simplifier and constraint solver. It would be better to load them once, at the start of the pipeline rather than at each of these different places. lazer already has a patch which achieves this. I'm making it a separate ticket as it need not be blocked on the progress of #14709 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14750> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13360: Add a flag to enable inferring HasCallStack constraints
by GHC 16 Apr '18

16 Apr '18

#13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- GHC is careful to not infer a HasCallStack constraint for a function, because the user didn't ask for one, it would complicate the type, and because it would incur some runtime overhead. I think this is the right default, but it can make debugging exceptions tedious as you have to manually add HasCallStack constraints to the entire chain of functions in the stack. I sometimes use CPP to give myself a flag to toggle the constraints, but I'd rather not have to resort to CPP. Instead, it would be nice if GHC supported a `-finfer-hascallstack` flag (off by default) that would simply generalize over the HasCallStack constraints rather than defaulting them. Then, if my program blows up I can simply recompile with `-finfer-hascallstack` and get a more informative trace. No manual editing, no preparation with CPP, easy! Furthermore, if we had such a flag, it might be nice to '''enable''' it by default in ghci. The two prime concerns are 1. Complicating type signatures. But `:t` solves the HasCallStack constraint before printing the type, so this is only a concern if you use `:i`. 2. Runtime overhead. I don't think this is a valid concern in ghci. I think this would be a nice and simple improvement to the debugging experience. The downside is that even with `-finfer-hascallstack` you would not get full call-stacks for functions in an imported module that was compiled normally. So this would not help with e.g. partial functions in `base`. (It would be really nice to find a solution to this that doesn't involve building modules in multiple ways..) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13360> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 42