July 2017 - ghc-tickets

[GHC] #13105: Allow type families in RuntimeReps
by GHC 04 Sep '17

04 Sep '17

#13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | 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: -------------------------------------+------------------------------------- Conal Elliott provided me with this puzzle: {{{ type family RepRep a ∷ RuntimeRep class HasRep a where type Rep a ∷ TYPE (RepRep a) repr ∷ a → Rep a abst ∷ Rep a → a type instance RepRep Int = IntRep instance HasRep Int where type Rep Int = Int# abst n = I# n repr (I# n) = n }}} I think we should accept. However, doing so (even with my solution to #12809 complete) is hard, because we frequently consult a kind in order to determine a runtime representation. When that kind is `TYPE (RepRep Int)`, the code generator throws up its arms in despair. The solution here is either to teach the code generator how to normalise types (requiring propagating the `FamInstEnvs`) or to do a whole-program transformation at some point (zonker? desugarer? maybe we can wait until !CorePrep or even unarisation?) to change ids whose types have kinds like `TYPE (RepRep Int)` into ids with types with kinds like `TYPE IntRep`. But I don't want to let this hold me up at the moment, so I'm posting here as a reminder to revisit this problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12708: RFC: Representation polymorphic Num
by GHC 04 Sep '17

04 Sep '17

#12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | 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 can create a GHC proposal for this but I need a sanity check first {{{#!hs import Prelude hiding (Num (..)) import qualified Prelude as P import GHC.Prim import GHC.Types class Num (a :: Type k) where (+) :: a -> a -> a (-) :: a -> a -> a (*) :: a -> a -> a negate :: a -> a abs :: a -> a signum :: a -> a fromInteger :: Integer -> a instance Num Int# where (+) :: Int# -> Int# -> Int# (+) = (+#) (-) :: Int# -> Int# -> Int# (-) = (-#) (*) :: Int# -> Int# -> Int# (*) = (*#) negate :: Int# -> Int# negate = negateInt# ... fromInteger :: Integer -> Int# fromInteger (fromInteger -> I# int) = int instance Num Double# where (+) :: Double# -> Double# -> Double# (+) = (+##) (-) :: Double# -> Double# -> Double# (-) = (-##) (*) :: Double# -> Double# -> Double# (*) = (*##) negate :: Double# -> Double# negate = negateDouble# ... fromInteger :: Integer -> Double# fromInteger (fromInteger -> D# dbl) = dbl }}} Note how the `fromInteger` views aren't qualified? That's because we can branch on the kind and all of a sudden, all instances of old `Num` are instances of our `Num` {{{#!hs instance P.Num a => Num (a :: Type) where (+) = (P.+) (-) = (P.-) (*) = (P.*) negate = P.negate abs = P.abs signum = P.signum fromInteger = P.fromInteger }}} ---- Same with `Show` etc. etc. {{{#!hs class Show (a :: TYPE k) where show :: (a :: TYPE k) -> String instance P.Show a => Show (a :: Type) where show :: (a :: Type) -> String show = P.show instance Show Int# where show :: Int# -> String show int = show (I# int) instance Show Double# where show :: Double# -> String show dbl = show (D# dbl) }}} ---- What effects would this have? They are even printed the same by default {{{#!hs >>> :kind Prelude.Num Prelude.Num :: * -> Constraint >>> :kind Main.Num Main.Num :: * -> Constraint >>> :set -fprint-explicit-runtime-reps >>> :kind Main.Num Main.Num :: TYPE k -> Constraint }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12708> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #13956: ghc panic compiling lame-0.1.1
by GHC 03 Sep '17

03 Sep '17

#13956: ghc panic compiling lame-0.1.1 -------------------------------------+------------------------------------- Reporter: uznx | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 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: -------------------------------------+------------------------------------- Compiling the package lame-0.1.1 using cabal, with profiling: [2 of 2] Compiling Codec.Audio.LAME ( Codec/Audio/LAME.hs, dist/build/Codec/Audio/LAME.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170704 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone lvl_soT9 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 504681 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This is a regression; the package compiles fine with GHC 8.0.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13956> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13885: Template Haskell doesn't freshen GADT kind variables properly when imported from another package
by GHC 02 Sep '17

02 Sep '17

#13885: Template Haskell doesn't freshen GADT kind variables properly when imported from another package -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A simple way to illustrate this bug is with this code: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeOperators #-} module Foo where import qualified Data.Type.Equality as DTE ((:~:)) import Language.Haskell.TH data a :~: b where Refl :: a :~: a $(return []) main :: IO () main = do putStrLn "Imported\n-----" putStrLn $(reify ''(DTE.:~:) >>= stringE . pprint) putStrLn "-----\n\nLocally defined\n-----" putStrLn $(reify ''(:~:) >>= stringE . pprint) putStrLn "-----" }}} Here, I'm pretty-printing the reified Template Haskell information about two datatypes: one that is imported from another package (`base`), and another that is defined locally. Aside from their definition sites, they are otherwise identical. However, when reifying them with Template Haskell, there is another distinction one can observe: {{{ $ /opt/ghc/8.2.1/bin/runghc Foo.hs Imported ----- data Data.Type.Equality.:~: (a_0 :: k_1) (b_2 :: k_1) where Data.Type.Equality.Refl :: forall (k_1 :: *) (a_0 :: k_1) . Data.Type.Equality.:~: a_0 a_0 ----- Locally defined ----- data Foo.:~: (a_0 :: k_1) (b_2 :: k_1) where Foo.Refl :: forall (k_3 :: *) (a_4 :: k_3) . Foo.:~: a_4 a_4 ----- }}} The locally defined information looks fine, but the one imported from `base` is suspicious. Namely, the `k_1` variable is used both in the datatype head and in the quantified variables for the constructor! To confirm this, you can print out more verbose info with `show` instead of `pprint`: {{{ Imported ----- TyConI (DataD [] Data.Type.Equality.:~: [KindedTV a_6989586621679026781 (VarT k_6989586621679026780),KindedTV b_6989586621679026782 (VarT k_6989586621679026780)] Nothing [ForallC [KindedTV k_6989586621679026780 StarT,KindedTV a_6989586621679026781 (VarT k_6989586621679026780)] [] (GadtC [Data.Type.Equality.Refl] [] (AppT (AppT (ConT Data.Type.Equality.:~:) (VarT a_6989586621679026781)) (VarT a_6989586621679026781)))] []) ----- Locally defined ----- TyConI (DataD [] Foo.:~: [KindedTV a_6989586621679016094 (VarT k_6989586621679016098),KindedTV b_6989586621679016095 (VarT k_6989586621679016098)] Nothing [ForallC [KindedTV k_6989586621679016108 StarT,KindedTV a_6989586621679016096 (VarT k_6989586621679016108)] [] (GadtC [Foo.Refl] [] (AppT (AppT (ConT Foo.:~:) (VarT a_6989586621679016096)) (VarT a_6989586621679016096)))] []) ----- }}} Sure enough, the variable `k_6989586621679026780` is used in both places. I would expect this not to happen, since the two sets of variables are scoped differently, and in practice, I have to work around this by freshening the type variables for the constructor, which is annoying. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13885> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14034: GHC crash instead of compile error on GHC 8.2 with ApplicativeDo
by GHC 31 Aug '17

31 Aug '17

#14034: GHC crash instead of compile error on GHC 8.2 with ApplicativeDo -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm filing this a sa proxy for user `sam2_` from IRC: {{{ $ cat Bug.hs {-# LANGUAGE ApplicativeDo #-} module Bug where doc = do () <- a () <- b c' <- c return d }}} {{{ $ ghc-8.2.1 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: out of memory (requested 1048576 bytes) }}} {{{ $ ghc-8.0.2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:9: error: Variable not in scope: a :: f () Bug.hs:6:9: error: Variable not in scope: b :: f () Bug.hs:7:9: error: Variable not in scope: c :: f a0 Bug.hs:8:10: error: Variable not in scope: d }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8317: Optimize tagToEnum# at Core level
by GHC 29 Aug '17

29 Aug '17

#8317: Optimize tagToEnum# at Core level ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6135 | ------------------------------------+------------------------------------- Old comparison primops that returned Bool were implemented by inserting call to `tagToEnum#` in the code generator. This call to `tagToEnum#` was later optimized away by a special case in the code geenrator (see [[GhcFile(compiler/codeGen/StgCmmExpr.hs)]], Note [case on bool])). Now that we have new comparison primops (see #6135) we no longer insert `tagToEnum#` in the code generator - all uses of `tagToEnum#` come from explicit calls in a source program. But we still have that special case in the code generator to optimize away `tagToEnum#`. We should drop that special case in the code generator and handle scrutinizing of `tagToEnum#` at the Core level by: 1. removing call to `tagToEnum#` in the scrutinee 2. adding calls to `dataToTag#` in case branches 3. constant-folding inserted `dataToTag#` Here is an example. This Haskell code: {{{ if tagToEnum# (a ># b) then E1 else E2 }}} will be translated to this Core: {{{ case tagToEnum# (a ># b) of True -> E1 False -> E2 }}} and optimized like this: {{{ case a ># b of dataToTag# True -> E1 dataToTag# False -> E2 }}} ====> {{{ case a ># b of 1 -> E1 0 -> E2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8317> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14000: Out of scope errors with type families do not mention scope
by GHC 25 Aug '17

25 Aug '17

#14000: Out of scope errors with type families do not mention scope -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) 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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE TypeFamilies #-} class C a where type T a c :: a -> T a main = c noSuchThing }}} yields: {{{ test_bad_error.hs:6:1: error: • Couldn't match expected type ‘T a’ with actual type ‘T a0’ NB: ‘T’ is a type function, and may not be injective The type variable ‘a0’ is ambiguous • In the ambiguity check for the inferred type for ‘main’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the inferred type main :: forall a. T a }}} This makes simple out-of-scope error seem very perplexing and is a huge regression in error quality. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14000> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14051: Unboxed sums-related panic: getUnboxedSumName 513
by GHC 25 Aug '17

25 Aug '17

#14051: Unboxed sums-related panic: getUnboxedSumName 513 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: UnboxedSums | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Originally reported [https://www.reddit.com/r/haskell/comments/6q6yau/unboxed_sums_ghc_panic/ here]. You'll need these two files: {{{#!hs -- Testing.hs {-# LANGUAGE UnboxedSums #-} module Testing where func :: s -> (# Bool | Bool #) func _ = (# True | #) }}} {{{#!hs -- Bug.hs {-# LANGUAGE UnboxedSums #-} module Main where import Testing main :: IO () main = print $ func 1 }}} And you must compile them like so (the `-c` and `-O2` flags are important): {{{ $ ghc -O2 -c Testing.hs $ ghc -O2 -c Bug.hs ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): getUnboxedSumName 513 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/prelude/KnownUniques.hs:104:5 in ghc:KnownUniques }}} Reproducible with GHC 8.2.1 and HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14022: base and ghc-prim should depend upon libm
by GHC 25 Aug '17

25 Aug '17

#14022: base and ghc-prim should depend upon libm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 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: -------------------------------------+------------------------------------- Both `base` and `ghc-prim` have references to symbols provided by `libm`. This dependency should be manifest in their respective cabal files. It seems that some `ld.gold` versions are strict about this. See https://github.com/NixOS/nixpkgs/pull/27584. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor
by GHC 25 Aug '17

25 Aug '17

#13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeOperators #-} module Bug where f :: () -> Int :~: Int f = undefined }}} GHC 8.0.2 gives a reasonable error message: {{{ $ /opt/ghc/8.0.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:4:12: error: Not in scope: type constructor or class ‘:~:’ }}} But GHC 8.2.1's error message is much more confusing: {{{ $ /opt/ghc/8.2.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:4:6: error: Precedence parsing error cannot mix ‘(->)’ [infixr 0] and ‘:~:’ [infixl 0] in the same infix expression | 4 | f :: () -> Int :~: Int | ^^^^^^^^^^^^^^^^^ Bug.hs:4:12: error: Not in scope: type constructor or class ‘:~:’ A data constructor of that name is in scope; did you mean DataKinds? | 4 | f :: () -> Int :~: Int | ^^^^^^^^^^^ }}} I was thrown akilter by the claim that `:~:` was `infixl 0`, since it was displayed before the real cause of the error (that it's out-of-scope). Adding `import Data.Type.Equality` fixes the error, but GHC really shouldn't be making claims about the fixities of out-of-scope type constructors in the first place. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13947> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8