September 2018 - ghc-tickets

[GHC] #13600: surprising error message with bang pattern
by GHC 15 Oct '18

15 Oct '18

#13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Poor/confusing (amd64) | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- the following code {{{ f3 :: [Int] -> IO Int f3 x = return (sum x) f4 :: [Int] -> IO Int f4 !x = return (sum x) }}} gives `The type signature for ‘f4’ lacks an accompanying binding` for the second function (the two functions are exactly the same except for the added bang). I do not understand bang patterns well, but would expect a more instructive error message. without the type definition, the second function f4 compiles with the bang). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #12430: TypeFamilyDependencies accepts invalid injectivity annotation
by GHC 15 Oct '18

15 Oct '18

#12430: TypeFamilyDependencies accepts invalid injectivity annotation -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | 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: -------------------------------------+------------------------------------- Consider this code (depends on singletons-2.2): {{{#!hs {-# LANGUAGE TypeFamilies, DataKinds, PolyKinds, TypeOperators, KindSignatures, TypeInType, TypeFamilyDependencies, UndecidableInstances #-} module Bug where import Data.Kind (Type) import Data.Singletons.Prelude (Map, SndSym0) import GHC.TypeLits (Nat) data Payload = A | B newtype NewType a = NewType Int type NatList = [(Nat, Payload)] type StripNatList (natList :: NatList) = Map SndSym0 natList type family Family (natList :: NatList) = (r :: Type) | r -> natList where Family '[] = () Family xs = NewType (StripNatList xs) }}} Why GHC is okay with injectivity annotation for `Family`: `r -> natList`? These two types: {{{#!hs type Foo = Family '[ '(0, 'A), '(1, 'B)] type Bar = Family '[ '(0, 'A), '(0, 'B)] }}} are obviously map to the same type: {{{#!hs *Bug Data.Singletons.Prelude> :kind! Foo Foo :: * = NewType ('A :$$$ '['B]) *Bug Data.Singletons.Prelude> :kind! Bar Bar :: * = NewType ('A :$$$ '['B]) }}} ---- If inline `StripNatList` inside `Family` definition: {{{#!hs type family Family (natList :: NatList) = (r :: Type) | r -> natList where Family '[] = () Family xs = NewType (Map SndSym0 xs) }}} or change `StripNatList` definition to type family: {{{#!hs type family StripNatList (natList :: NatList) where StripNatList '[] = '[] StripNatList ('(n, x) ': xs) = x ': StripNatList xs }}} compilation expectedly fails with `Type family equation violates injectivity annotation.` ---- Moreover, if I remove `NewType` from `Family` and change result kind: {{{#!hs type family Family (natList :: NatList) = (r :: [Payload]) | r -> natList where Family xs = StripNatList xs }}} it fails with correct error regardless of `StripNatList` definition. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12430> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14341: Show instance for TypeReps is a bit broken
by GHC 15 Oct '18

15 Oct '18

#14341: Show instance for TypeReps is a bit broken -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.2.1 Libraries | Keywords: Typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4084 | Wiki Page: -------------------------------------+------------------------------------- There are two problems. 1. Showing typereps of tuples can produce unnecessary parentheses: {{{ Prelude K T> typeRep @(Int, Maybe Bool) (Int,(Maybe Bool)) }}} The fix is trivial. 2. Showing typereps of ticked (i.e., lifted) tuples and lists gives hard- to-read results, because it does not use the usual special syntax: {{{ Prelude K T> typeRep @'(Int, Maybe Bool) '(,) * * Int (Maybe Bool) Prelude K T> typeRep @'[1,2,3] ': Nat 1 (': Nat 2 (': Nat 3 ('[] Nat))) }}} Fixing the lifted tuple case is trivial. Fixing the lifted list case is slightly less trivial, but not hard. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14341> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14088: Allow users to omit`forall`
by GHC 15 Oct '18

15 Oct '18

#14088: Allow users to omit`forall` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Just an idea I wanted to get out there, I don't think it causes parsing ambiguity {{{#!hs -- id :: forall a. a -> a id :: a. a -> a -- everywhere :: (forall b. Term b => b -> b) -> (forall a. Term a => a -> a) everywhere :: (b. Term b => b -> b) -> (a. Term a => a -> a) }}} I think it looks beautiful but clearly more difficult to Google or grep for. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14088> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0
by GHC 15 Oct '18

15 Oct '18

#15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 -------------------------------------+------------------------------------- Reporter: noah | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux accelerate,memory,compile | Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: accelerate | Blocked By: 1.2.0 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Every time I try to run {{{ cabal install accelerate }}} the compiler take up nearly all 4GB of memory. Stracing it reveals that it seems to be spending nearly all of the time it runs checking a timer file descriptor, and occasionally checking its memory usage without actually doing anything about the problem. This makes installing accelerate nearly impossible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15488> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #15695: Core Lint error, from -fobject-code + defer type errors + pattern synonyms + other stuff
by GHC 14 Oct '18

14 Oct '18

#15695: Core Lint error, from -fobject-code + defer type errors + pattern synonyms + other stuff -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Try running this (`-fobject-code` is required) with '''and''' without `-dcore-lint`. I tried to minimize it but it is still hefty. This is showing it without `-dcore-lint`: {{{#!hs {-# Language RankNTypes, PatternSynonyms, DataKinds, PolyKinds, GADTs, TypeOperators, MultiParamTypeClasses, TypeFamilies, TypeSynonymInstances, FlexibleInstances, InstanceSigs, FlexibleContexts #-} {-# Options_GHC -fdefer-type-errors #-} import Data.Kind import Data.Type.Equality data TyVar :: Type -> Type -> Type where VO :: TyVar (a -> as) a VS :: TyVar as a -> TyVar (b -> as) a data NP :: (k -> Type) -> ([k] -> Type) where Nil :: NP f '[] (:*) :: f a -> NP f as -> NP f (a:as) data NS :: (k -> Type) -> ([k] -> Type) where Here :: f a -> NS f (a:as) There :: NS f as -> NS f (a:as) infixr 6 :&: data Ctx :: Type -> Type where E :: Ctx(Type) (:&:) :: a -> Ctx(as) -> Ctx(a -> as) data NA a type SOP(kind::Type) code = NS (NP NA) code data ApplyT(kind::Type) :: kind -> Ctx(kind) -> Type where AO :: a -> ApplyT(Type) a E AS :: ApplyT(ks) (f a) ctx -> ApplyT(k -> ks) f (a:&:ctx) from' :: ApplyT(Type -> Type -> Type) Either ctx -> NS (NP NA) '[ '[VO] ] from' (ASSO (Left a)) = Here (a :* Nil) from' (ASSO (Right b)) = There (Here undefined) pattern ASSO :: () => forall (ks :: Type) k (f :: k -> ks) (a1 :: k) (ks1 :: Type) k1 (f1 :: k1 -> ks1) (a2 :: k1) a3. (kind ~ (k -> k1 -> Type), a ~~ f, b ~~ (a1 :&: a2 :&: E), f a1 ~~ f1, f1 a2 ~~ a3) => a3 -> ApplyT kind a b pattern ASSO a = AS (AS (AO a)) }}} {{{ $ latestbug -fobject-code 466.hs GHCi, version 8.7.20180828: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 466.hs, 466.o ) 466.hs:35:14: warning: [-Wdeferred-type-errors] • Could not deduce: a2 ~ NA 'VO from the context: ((* -> * -> *) ~ (k1 -> k2 -> *), Either ~~ f, ctx ~~ (a2 ':&: (a3 ':&: 'E)), f a2 ~~ f1, f1 a3 ~~ a4) bound by a pattern with pattern synonym: ASSO :: forall kind (a :: kind) (b :: Ctx kind). () => forall ks k (f :: k -> ks) (a1 :: k) ks1 k1 (f1 :: k1 -> ks1) (a2 :: k1) a3. (kind ~ (k -> k1 -> *), a ~~ f, b ~~ (a1 ':&: (a2 ':&: 'E)), f a1 ~~ f1, f1 a2 ~~ a3) => a3 -> ApplyT kind a b, in an equation for ‘from'’ at 466.hs:35:8-21 ‘a2’ is a rigid type variable bound by a pattern with pattern synonym: ASSO :: forall kind (a :: kind) (b :: Ctx kind). () => forall ks k (f :: k -> ks) (a1 :: k) ks1 k1 (f1 :: k1 -> ks1) (a2 :: k1) a3. (kind ~ (k -> k1 -> *), a ~~ f, b ~~ (a1 ':&: (a2 ':&: 'E)), f a1 ~~ f1, f1 a2 ~~ a3) => a3 -> ApplyT kind a b, in an equation for ‘from'’ at 466.hs:35:8-21 Expected type: a4 Actual type: Either (NA 'VO) a3 • In the pattern: Left a In the pattern: ASSO (Left a) In an equation for ‘from'’: from' (ASSO (Left a)) = Here (a :* Nil) • Relevant bindings include from' :: ApplyT (* -> * -> *) Either ctx -> NS (NP NA) '[ '[ 'VO]] (bound at 466.hs:35:1) | 35 | from' (ASSO (Left a)) = Here (a :* Nil) | ^^^^^^^ 466.hs:36:26: warning: [-Wdeferred-type-errors] • Couldn't match type ‘a0 : as0’ with ‘'[]’ Expected type: NS (NP NA) '[ '[ 'VO]] Actual type: NS (NP NA) ('[ 'VO] : a0 : as0) • In the expression: There (Here undefined) In an equation for ‘from'’: from' (ASSO (Right b)) = There (Here undefined) • Relevant bindings include from' :: ApplyT (* -> * -> *) Either ctx -> NS (NP NA) '[ '[ 'VO]] (bound at 466.hs:35:1) | 36 | from' (ASSO (Right b)) = There (Here undefined) | ^^^^^^^^^^^^^^^^^^^^^^ WARNING: file compiler/types/TyCoRep.hs, line 2378 in_scope InScope {wild_00 wild_Xl wild_Xv wild_X1m a_a1Gv ks_a1Ou k_a1Ov f_a1Ow a_a1Ox ctx_a1Oy co_a1Oz co_a1OA co_a1OB ks_a1OC k_a1OD f_a1OE a_a1OF ctx_a1OG co_a1OH co_a1OI co_a1OJ a_a1OK co_a1OL co_a1OM co_a1ON as_a1Q3 a_a1Q4 ctx_a1Q5 $krep_a2XW $krep_a2XX $krep_a2XY $krep_a2XZ $krep_a2Y0 $krep_a2Y1 $krep_a2Y2 $krep_a2Y3 $krep_a2Y4 $krep_a2Y5 $krep_a2Y6 $krep_a2Y7 $krep_a2Y8 $krep_a2Y9 $krep_a2Ya $krep_a2Yb $krep_a2Yc $krep_a2Yd $krep_a2Ye $krep_a2Yf $krep_a2Yg $krep_a2Yh $krep_a2Yi $krep_a2Yj $krep_a2Yk $krep_a2Yl $krep_a2Ym $krep_a2Yn $krep_a2Yo $krep_a2Yp $krep_a2Yq $krep_a2Yr $krep_a2Ys $krep_a2Yt $krep_a2Yu $krep_a2Yv $krep_a2Yw $krep_a2Yx $krep_a2Yy $krep_a2Yz $krep_a2YA $krep_a2YB $krep_a2YC $krep_a2YD $krep_a2YE $krep_a2YF $krep_a2YG $krep_a2YH $krep_a2YI $krep_a2YJ $krep_a2YK $krep_a2YL ds_d2YO ds_d2YP ds_d2YV fail_d2Z2 from' $bASSO $mASSO $tc':&: $tc':* $tc'AO $tc'AS $tc'E $tc'Here $tc'Nil $tc'There $tc'VO $tc'VS $tcApplyT $tcCtx $tcNA $tcNP $tcNS $tcTyVar $trModule $trModule_s2ZM $trModule_s2ZN $trModule_s2ZO $trModule_s2ZP $krep_s2ZQ $krep_s2ZR $krep_s2ZS $krep_s2ZT $krep_s2ZU $krep_s2ZV $krep_s2ZW $krep_s2ZX $tcTyVar_s2ZY $tcTyVar_s2ZZ $krep_s300 $krep_s301 $krep_s302 $krep_s303 $tc'VO_s304 $tc'VO_s305 $krep_s306 $krep_s307 $tc'VS_s308 $tc'VS_s309 $tcNP_s30a $tcNP_s30b $krep_s30c $krep_s30d $krep_s30e $krep_s30f $krep_s30g $krep_s30h $tc':*_s30i $tc':*_s30j $krep_s30k $krep_s30l $krep_s30m $tc'Nil_s30n $tc'Nil_s30o $tcNS_s30p $tcNS_s30q $krep_s30r $krep_s30s $krep_s30t $krep_s30u $krep_s30v $krep_s30w $tc'Here_s30x $tc'Here_s30y $krep_s30z $krep_s30A $krep_s30B $tc'There_s30C $tc'There_s30D $tcCtx_s30E $tcCtx_s30F $krep_s30G $krep_s30H $krep_s30I $tc':&:_s30J $tc':&:_s30K $krep_s30L $krep_s30M $krep_s30N $krep_s30O $krep_s30P $tc'E_s30Q $tc'E_s30R $tcNA_s30S $tcNA_s30T $tcApplyT_s30U $tcApplyT_s30V $krep_s30W $krep_s30X $krep_s30Y $krep_s30Z $krep_s310 $krep_s311 $tc'AS_s312 $tc'AS_s313 $krep_s314 $krep_s315 $krep_s316 $tc'AO_s317 $tc'AO_s318} tenv [a1Ow :-> f_a1Ow, a1Ox :-> a_a1Ox, a1Oy :-> ctx_a1Oy, a1OE :-> f_a1OE, a1OF :-> a_a1OF, a1OG :-> ctx_a1OG] cenv [a1Oz :-> co_a1Oz, a1OA :-> co_a1OA, a1OB :-> co_a1OB, a1OH :-> co_a1OH, a1OI :-> co_a1OI, a1OJ :-> co_a1OJ, a1OL :-> co_a1OL, a1OM :-> co_a1OM, a1ON :-> co_a1ON] tys [a_a1Ox ~# (NA 'VO |> Sym (Nth:2 (Sym co_a2U0)))] cos [] needInScope [a1Ov :-> k_a1Ov, a1OD :-> k_a1OD, a1Q3 :-> as_a1Q3, a1Q4 :-> a_a1Q4, a2U0 :-> co_a2U0] WARNING: file compiler/types/TyCoRep.hs, line 2378 in_scope InScope {wild_00 wild_Xl wild_Xv wild_X1m a_a1Gv ks_a1Ou k_a1Ov f_a1Ow a_a1Ox ctx_a1Oy co_a1Oz co_a1OA co_a1OB ks_a1OC k_a1OD f_a1OE a_a1OF ctx_a1OG co_a1OH co_a1OI co_a1OJ a_a1OK co_a1OL co_a1OM co_a1ON as_a1Q3 a_a1Q4 ctx_a1Q5 $krep_a2XW $krep_a2XX $krep_a2XY $krep_a2XZ $krep_a2Y0 $krep_a2Y1 $krep_a2Y2 $krep_a2Y3 $krep_a2Y4 $krep_a2Y5 $krep_a2Y6 $krep_a2Y7 $krep_a2Y8 $krep_a2Y9 $krep_a2Ya $krep_a2Yb $krep_a2Yc $krep_a2Yd $krep_a2Ye $krep_a2Yf $krep_a2Yg $krep_a2Yh $krep_a2Yi $krep_a2Yj $krep_a2Yk $krep_a2Yl $krep_a2Ym $krep_a2Yn $krep_a2Yo $krep_a2Yp $krep_a2Yq $krep_a2Yr $krep_a2Ys $krep_a2Yt $krep_a2Yu $krep_a2Yv $krep_a2Yw $krep_a2Yx $krep_a2Yy $krep_a2Yz $krep_a2YA $krep_a2YB $krep_a2YC $krep_a2YD $krep_a2YE $krep_a2YF $krep_a2YG $krep_a2YH $krep_a2YI $krep_a2YJ $krep_a2YK $krep_a2YL ds_d2YO ds_d2YP ds_d2YV fail_d2Z2 from' $bASSO $mASSO $tc':&: $tc':* $tc'AO $tc'AS $tc'E $tc'Here $tc'Nil $tc'There $tc'VO $tc'VS $tcApplyT $tcCtx $tcNA $tcNP $tcNS $tcTyVar $trModule $trModule_s2ZM $trModule_s2ZN $trModule_s2ZO $trModule_s2ZP $krep_s2ZQ $krep_s2ZR $krep_s2ZS $krep_s2ZT $krep_s2ZU $krep_s2ZV $krep_s2ZW $krep_s2ZX $tcTyVar_s2ZY $tcTyVar_s2ZZ $krep_s300 $krep_s301 $krep_s302 $krep_s303 $tc'VO_s304 $tc'VO_s305 $krep_s306 $krep_s307 $tc'VS_s308 $tc'VS_s309 $tcNP_s30a $tcNP_s30b $krep_s30c $krep_s30d $krep_s30e $krep_s30f $krep_s30g $krep_s30h $tc':*_s30i $tc':*_s30j $krep_s30k $krep_s30l $krep_s30m $tc'Nil_s30n $tc'Nil_s30o $tcNS_s30p $tcNS_s30q $krep_s30r $krep_s30s $krep_s30t $krep_s30u $krep_s30v $krep_s30w $tc'Here_s30x $tc'Here_s30y $krep_s30z $krep_s30A $krep_s30B $tc'There_s30C $tc'There_s30D $tcCtx_s30E $tcCtx_s30F $krep_s30G $krep_s30H $krep_s30I $tc':&:_s30J $tc':&:_s30K $krep_s30L $krep_s30M $krep_s30N $krep_s30O $krep_s30P $tc'E_s30Q $tc'E_s30R $tcNA_s30S $tcNA_s30T $tcApplyT_s30U $tcApplyT_s30V $krep_s30W $krep_s30X $krep_s30Y $krep_s30Z $krep_s310 $krep_s311 $tc'AS_s312 $tc'AS_s313 $krep_s314 $krep_s315 $krep_s316 $tc'AO_s317 $tc'AO_s318} tenv [a1Ow :-> f_a1Ow, a1Ox :-> a_a1Ox, a1Oy :-> ctx_a1Oy, a1OE :-> f_a1OE, a1OF :-> a_a1OF, a1OG :-> ctx_a1OG] cenv [a1Oz :-> co_a1Oz, a1OA :-> co_a1OA, a1OB :-> co_a1OB, a1OH :-> co_a1OH, a1OI :-> co_a1OI, a1OJ :-> co_a1OJ, a1OL :-> co_a1OL, a1OM :-> co_a1OM, a1ON :-> co_a1ON] tys [a_a1Ox ~# (NA 'VO |> Sym (Nth:2 (Sym co_a2U0)))] cos [] needInScope [a1Ov :-> k_a1Ov, a1OD :-> k_a1OD, a1Q3 :-> as_a1Q3, a1Q4 :-> a_a1Q4, a2U0 :-> co_a2U0] Ok, one module loaded. Prelude Main> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15695> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15481: TH fails to recover from reifyFixity with -fexternal-interpreter
by GHC 14 Oct '18

14 Oct '18

#15481: TH fails to recover from reifyFixity with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.4.3 Haskell | Keywords: RemoteGHCi | 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 at https://github.com/glguy/th- abstraction/issues/53.) If you compile the following program: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH main :: IO () main = putStrLn $(recover (stringE "reifyFixity failed") (do foo <- newName "foo" _ <- reifyFixity foo stringE "reifyFixity successful")) }}} It will work fine without the use of `-fexternal-interpreter`. However, using `-fexternal-interpreter` will result in an error: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs -fforce-recomp [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) $ /opt/ghc/8.4.3/bin/ghc Bug.hs -fforce-recomp -fexternal-interpreter [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:7:19: error: • The exact Name ‘foo_a3MT’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful • In the untyped splice: $(recover (stringE "reifyFixity failed") (do foo <- newName "foo" _ <- reifyFixity foo stringE "reifyFixity successful")) | 7 | main = putStrLn $(recover (stringE "reifyFixity failed") | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Bug.hs:7:19: error: • The exact Name ‘foo_a3MT’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful • In the untyped splice: $(recover (stringE "reifyFixity failed") (do foo <- newName "foo" _ <- reifyFixity foo stringE "reifyFixity successful")) | 7 | main = putStrLn $(recover (stringE "reifyFixity failed") | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15481> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12005: Constraint instances not shown in `:info`
by GHC 13 Oct '18

13 Oct '18

#12005: Constraint instances not shown in `:info` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci -XKindSignatures -XRank2Types -XConstraintKinds -XAllowAmbiguousTypes -XInstanceSigs GHCi, version 8.1.20160428: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Kind Prelude Data.Kind> class Defer (p :: Constraint) where defer :: (p => r) -> r Prelude Data.Kind> instance Defer () where defer :: r -> r; defer = id Prelude Data.Kind> :i Defer class Defer (p :: Constraint) where defer :: (p => r) -> r {-# MINIMAL defer #-} -- Defined at <interactive>:2:1 }}} Same happens with the [https://github.com/ekmett/constraints/blob/master/src/Data/Constraint/Defer… Data.Constraint.Deferrable] which defines: {{{#!hs instance (Typeable a, Typeable b) => Deferrable (a ~ b) instance (Deferrable a, Deferrable b) => Deferrable (a, b) instance (Deferrable a, Deferrable b, Deferrable c) => Deferrable (a, b, c) }}} but no instances are shown: {{{ ghci> import Data.Constraint.Deferrable ghci> :i Deferrable class Deferrable (p :: Constraint) where deferEither :: proxy p -> (p => r) -> Either String r {-# MINIMAL deferEither #-} -- Defined in ‘Data.Constraint.Deferrable’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12005> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15571: Eager AP_STACK blackholing causes incorrect size info for sanity checks
by GHC 13 Oct '18

13 Oct '18

#15571: Eager AP_STACK blackholing causes incorrect size info for sanity checks -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.5 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15508 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While debugging #15508 I found a case where eager blackholing in AP_STACK causes `closure_sizeW()` to return incorrect size, which in turn causes incorrect slop zeroing by `OVERWRITING_CLOSURE()`, which breaks sanity checks. To reproduce, cd into `testsuite/tests/concurrent/prog001`, then: {{{ $ ghc-stage2 Mult.hs -fforce-recomp -debug -rtsopts $ ./Mult +RTS -DS Mult: internal error: checkClosure: stack frame (GHC version 8.7.20180825 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}} Here's how the problem occurs: 1. Allocate an AP_STACK in a generation during a GC. 2. Evaluate the AP_STACK. The entry code first WHITEHOLEs and then eagerly BLACKHOLEs it. At this point size of the STACK becomes 2 because that's the size of (eager or not) BLACKHOLE. 3. To start a GC the thread does `threadPaused`, which in line 342 actually BLACKHOLEs the eager blackhole (is this part really correct?) and zeros the slop, but because the eager blackhole has the same size as BLACKHOLE it doesn't actually zero the stack frames in the original AP_STACK's payload. 4. In the next GC, in pre-GC sanity check we check the whole heap. When checking the generation that the BLACKHOLE (the AP_STACK that became a BLACKHOLE in step (2)) resides in we check the closure, and then check `closure + 2` (2 is the size of BLACKHOLE) instead of `closure + <size of the stack>`, and end up checking a stack frame of the original AP_STACK. This causes the sanity check to fail because we don't expect to see a stack frame outside of a stack. In summary, normally when blackhole an object we zero the space after the blackhole (i.e. some part of the original object's payload) so that in sanity checks we can skip over that space, but we can't do this when eagerly blackholing (because the payload of the original object will be used) which causes sanity check failures. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15571> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15053: Compiler panic on invalid syntax (unterminated pragma)
by GHC 13 Oct '18

13 Oct '18

#15053: Compiler panic on invalid syntax (unterminated pragma) -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Parser) | 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: -------------------------------------+------------------------------------- The following minimal example causes a compiler panic. {{{ {-# OPTIONS_GHC -O1 } " #-} }}} {{{ ghc-stage2.exe: panic! (the 'impossible' happened) (GHC version 8.5.20180413 for x86_64-unknown-mingw32): getOptions'.parseToks: Couldn't read "\r\n\"\r\n " as String Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Happens in HEAD and 8.2.2 at least. Double quotes seem to confuse the parser. Also panics if there are two doublequotes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15053> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8