March 2017 - ghc-tickets

[GHC] #11174: Traversable can't be derived for datatypes with unboxed arguments
by GHC 01 Aug '17

01 Aug '17

#11174: Traversable can't be derived for datatypes with unboxed arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | 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: -------------------------------------+------------------------------------- Unlike `Functor` and `Foldable`, `Traversable` cannot be derived for datatypes that contain arguments with unboxed types. A simple example: {{{#!hs {-# LANGUAGE DeriveTraversable, MagicHash #-} import GHC.Prim (Int#) data IntHash a = IntHash Int# deriving (Functor, Foldable, Traversable) }}} The generated `Traversable` instance reveals the issue: {{{#!hs instance Traversable IntHash where traverse f (IntHash a1) = fmap IntHash (pure a1) }}} {{{ Couldn't match kind `*' with `#' When matching types a0 :: * Int# :: # Expected type: a0 -> IntHash b Actual type: Int# -> IntHash b In the first argument of `fmap', namely `IntHash' In the expression: fmap IntHash (pure a1) When typechecking the code for `traverse' in a derived instance for `Traversable IntHash': To see the code I am typechecking, use -ddump-deriv }}} We have to avoid calling `pure` on `a1`, since `pure` expects an argument with a `*`-kinded type, not a `#`-kinded one. One way to fix this would be restructuring the derived `traverse` implementation such that unboxed arguments are moved to the function initially lifted with `pure`, and doing nothing with them later. To better articulate what I mean, envision something like this: {{{#!hs data IntHash2 a = IntHash2 Int# a (IntHash2 a) Int# deriving (Functor, Foldable) }}} Then a derived `Traversable` instance that would typecheck would be: {{{#!hs instance Traversable IntHash2 where traverse f (IntHash2 a1 a2 a3 a4) = pure (\x2 x3 -> IntHash2 a1 x2 x3 a4) <*> f a2 <*> traverse f a3 }}} Conceptually, this doesn't sound hard to implement. The tricky part is figuring out how much of the existing `Functor`/`Foldable`/`Traversable` deriving machinery would need to be tweaked to make this work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11174> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12399: DeriveFunctor fail
by GHC 01 Aug '17

01 Aug '17

#12399: DeriveFunctor fail -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- {{{#!haskell {-# LANGUAGE DeriveFunctor, MagicHash, UnboxedTuples #-} module Lib where import GHC.Exts newtype RmLoopsM a = RmLoopsM { runRmLoops :: Int# -> (# Int#, a #) } }}} Functor instance for this can be derived like this: {{{#!haskell instance Functor RmLoopsM where fmap f (RmLoopsM m) = RmLoopsM $ \i -> case m i of (# i', r #) -> (# i', f r #) }}} `DeriveFunctor` instead generates something like this: {{{#!haskell instance Functor RmLoopsM where fmap f_a2Oh (Lib.RmLoopsM a1_a2Oi) = RmLoopsM ((\ b6_a2Oj b7_a2Ok -> (\ b5_a2Ol -> case b5_a2Ol of { ((#,#) a1_a2Om a2_a2On a3_a2Oo a4_a2Op) -> (#,#) ((\ b2_a2Oq -> b2_a2Oq) a1_a2Om) ((\ b3_a2Or -> b3_a2Or) a2_a2On) ((\ b4_a2Os -> b4_a2Os) a3_a2Oo) (f_a2Oh a4_a2Op) }) (b6_a2Oj ((\ b1_a2Ot -> b1_a2Ot) b7_a2Ok))) a1_a2Oi) }}} which fails with {{{ Main.hs:17:25: error: • The constructor ‘(#,#)’ should have 2 arguments, but has been given 4 • In the pattern: (#,#) a1_a2Om a2_a2On a3_a2Oo a4_a2Op In a case alternative: ((#,#) a1_a2Om a2_a2On a3_a2Oo a4_a2Op) -> (#,#) ((\ b2_a2Oq -> b2_a2Oq) a1_a2Om) ((\ b3_a2Or -> b3_a2Or) a2_a2On) ((\ b4_a2Os -> b4_a2Os) a3_a2Oo) (f_a2Oh a4_a2Op) In the expression: case b5_a2Ol of { ((#,#) a1_a2Om a2_a2On a3_a2Oo a4_a2Op) -> (#,#) ((\ b2_a2Oq -> b2_a2Oq) a1_a2Om) ((\ b3_a2Or -> b3_a2Or) a2_a2On) ((\ b4_a2Os -> b4_a2Os) a3_a2Oo) (f_a2Oh a4_a2Op) } }}} I think it's supposed to ignore RuntimeRep args during the fold (`TcGenDeriv.functorLikeTraverse`). Tried with: HEAD, 8.0.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12399> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13263: cant derive functor on function newtype with unboxed tuple result
by GHC 01 Aug '17

01 Aug '17

#13263: cant derive functor on function newtype with unboxed tuple result -------------------------------------+------------------------------------- Reporter: carter | 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'm not sure if this is a bug or a feature request, but i have a simple example that I think should work with deriving functor but falls over {{{ {-# LANGUAGE ScopedTypeVariables, BangPatterns, UnboxedTuples, MagicHash, GADTs #-} {-# LANGUAGE DeriveFunctor #-} module Test where newtype Eww a = Ew# (Int -> (# a, Int #)) deriving (Functor) }}} the error i get is {{{ src/System/Random/SplitMix/Internal.hs:88:13: error: • The constructor ‘(#,#)’ should have 2 arguments, but has been given 4 • In the pattern: (#,#) a1 a2 a3 a4 In a case alternative: ((#,#) a1 a2 a3 a4) -> (#,#) ((\ b2 -> b2) a1) ((\ b3 -> b3) a2) (f a3) ((\ b4 -> b4) a4) In the expression: case b5 of { ((#,#) a1 a2 a3 a4) -> (#,#) ((\ b2 -> b2) a1) ((\ b3 -> b3) a2) (f a3) ((\ b4 -> b4) a4) } When typechecking the code for ‘fmap’ in a derived instance for ‘Functor Eww’: To see the code I am typechecking, use -ddump-deriv }}} and the dumped deriving is {{{ [1 of 1] Compiling System.Random.SplitMix.Internal ( src/System/Random/SplitMix/Internal.hs, /Users/carter/WorkSpace/projects/active/random-hs/dist- newstyle/build/random-2.0.0.0/build/System/Random/SplitMix/Internal.o ) ==================== Derived instances ==================== Derived instances: instance GHC.Base.Functor System.Random.SplitMix.Internal.Eww where GHC.Base.fmap f_a4Vn (System.Random.SplitMix.Internal.Ew# a1_a4Vo) = System.Random.SplitMix.Internal.Ew# ((\ b6_a4Vp b7_a4Vq -> (\ b5_a4Vr -> case b5_a4Vr of { ((#,#) a1_a4Vs a2_a4Vt a3_a4Vu a4_a4Vv) -> (#,#) ((\ b2_a4Vw -> b2_a4Vw) a1_a4Vs) ((\ b3_a4Vx -> b3_a4Vx) a2_a4Vt) (f_a4Vn a3_a4Vu) ((\ b4_a4Vy -> b4_a4Vy) a4_a4Vv) }) (b6_a4Vp ((\ b1_a4Vz -> b1_a4Vz) b7_a4Vq))) a1_a4Vo) GHC.Generics representation types: }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13263> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself
by GHC 01 Aug '17

01 Aug '17

#12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | 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: -------------------------------------+------------------------------------- GHC 8.0.1 is able to compile this without a problem and doesn't require FlexibleContexts. {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE ConstrainedClassMethods #-} module A where class C m where foo :: C m => m () newtype N m a = N (m a) deriving C }}} Compare the output of 8.0.1, 8.0.2 and 8.1. I turned on -fdefer-type- errors in order for -ddump-deriv to work. {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.1 $ ghc -ddump-deriv A.hs [1 of 1] Compiling A ( A.hs, A.o ) ==================== Derived instances ==================== Derived instances: instance A.C m_aNK => A.C (A.N m_aNK) where A.foo = GHC.Prim.coerce (A.foo :: m_ap1 ()) :: A.N m_ap1 () GHC.Generics representation types: }}} {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 $ ghc A.hs [1 of 1] Compiling A ( A.hs, A.o ) A.hs:10:12: error: • Couldn't match type ‘m’ with ‘N m’ arising from the coercion of the method ‘foo’ from type ‘C m => m ()’ to type ‘C (N m) => N m ()’ ‘m’ is a rigid type variable bound by the deriving clause for ‘C (N m)’ at A.hs:10:12 • When deriving the instance for (C (N m)) $ ghc -ddump-deriv -fdefer-type-errors A.hs [1 of 1] Compiling A ( A.hs, A.o ) ==================== Derived instances ==================== Derived instances: instance A.C m_awm => A.C (A.N m_awm) where A.foo = GHC.Prim.coerce @(A.C m_ap0 => m_ap0 ()) @(A.C (A.N m_ap0) => A.N m_ap0 ()) A.foo GHC.Generics representation types: A.hs:11:12: warning: [-Wdeferred-type-errors] • Couldn't match type ‘m’ with ‘N m’ arising from a use of ‘GHC.Prim.coerce’ ‘m’ is a rigid type variable bound by the instance declaration at A.hs:11:12 • In the expression: GHC.Prim.coerce @(C m => m ()) @(C (N m) => N m ()) foo In an equation for ‘foo’: foo = GHC.Prim.coerce @(C m => m ()) @(C (N m) => N m ()) foo When typechecking the code for ‘foo’ in a derived instance for ‘C (N m)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘C (N m)’ • Relevant bindings include foo :: N m () (bound at A.hs:11:12) }}} There's no '8.0.2' version to report this against so I've chosen 8.1. GHC 8.1 gives very similar results: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.1.20160930 $ ghc A.hs [1 of 1] Compiling A ( A.hs, A.o ) A.hs:11:12: error: • Couldn't match type ‘m’ with ‘N m’ arising from the coercion of the method ‘foo’ from type ‘C m => m ()’ to type ‘C (N m) => N m ()’ ‘m’ is a rigid type variable bound by the deriving clause for ‘C (N m)’ at A.hs:11:12 • When deriving the instance for (C (N m)) $ ghc -ddump-deriv -fdefer-type-errors A.hs [1 of 1] Compiling A ( A.hs, A.o ) ==================== Derived instances ==================== Derived instances: instance A.C m_awK => A.C (A.N m_awK) where A.foo = GHC.Prim.coerce @(A.C m_app => m_app ()) @(A.C (A.N m_app) => A.N m_app ()) A.foo GHC.Generics representation types: A.hs:11:12: warning: [-Wsimplifiable-class-constraints] The constraint ‘C (N m)’ matches an instance declaration instance C m => C (N m) -- Defined at A.hs:11:12 This makes type inference for inner bindings fragile; either use MonoLocalBinds, or simplify it using the instance A.hs:11:12: warning: [-Wdeferred-type-errors] • Couldn't match type ‘m’ with ‘N m’ arising from a use of ‘GHC.Prim.coerce’ ‘m’ is a rigid type variable bound by the instance declaration at A.hs:11:12 • In the expression: GHC.Prim.coerce @(C m => m ()) @(C (N m) => N m ()) foo In an equation for ‘foo’: foo = GHC.Prim.coerce @(C m => m ()) @(C (N m) => N m ()) foo When typechecking the code for ‘foo’ in a derived instance for ‘C (N m)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘C (N m)’ • Relevant bindings include foo :: N m () (bound at A.hs:11:12) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12768> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #12417: API annotations for unboxed sums needs reworking
by GHC 01 Aug '17

01 Aug '17

#12417: API annotations for unboxed sums needs reworking -------------------------------------+------------------------------------- Reporter: osa1 | 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: -------------------------------------+------------------------------------- API annotations for unboxed sums are not entirely correct. As far as I understand, some of the bars (`|`) in the concrete syntax are not properly attached to any of the AST nodes. Some discussion can be seen in [https://phabricator.haskell.org/D2259#69809 the Phab page]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12417> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12478: Template Haskell support for unboxed sums
by GHC 01 Aug '17

01 Aug '17

#12478: Template Haskell support for unboxed sums -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Template | Version: 8.1 Haskell | Keywords: | Operating System: Unknown/Multiple TemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, you can't use unboxed sums with Template Haskell. This makes me sad. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12478> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11995: Can't infer type
by GHC 31 Jul '17

31 Jul '17

#11995: Can't infer type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- {{{#!hs import Data.Kind data NP :: forall k. (ĸ → Type) → ([k] → Type) where Nil :: NP f '[] (:*) :: f x → NP f xs → NP f (x:xs) newtype K a b = K a deriving Show unK (K a) = a h'collapse :: NP (K a) xs -> [a] h'collapse = \case Nil -> [] K x:*xs -> x : h'collapse xs }}} if we replace `xs` by an underscore: {{{ tJN0.hs:13:29-30: error: … • Could not deduce: (xs :: [ĸ]) ~~ ((':) ĸ x xs :: [ĸ]) from the context: ((k :: *) ~~ (ĸ :: *), (t :: [k]) ~~ ((':) ĸ x xs :: [ĸ])) bound by a pattern with constructor: :* :: forall k (f :: k -> *) (x :: k) (xs :: [k]). f x -> NP k k f xs -> NP k k f ((':) k x xs), in a case alternative at /tmp/tJN0.hs:13:3-9 ‘xs’ is a rigid type variable bound by a pattern with constructor: :* :: forall k (f :: k -> *) (x :: k) (xs :: [k]). f x -> NP k k f xs -> NP k k f ((':) k x xs), in a case alternative at /tmp/tJN0.hs:13:3 Expected type: NP ĸ k (K ĸ a) t Actual type: NP ĸ ĸ (K ĸ a) xs • In the first argument of ‘h'collapse’, namely ‘xs’ In the second argument of ‘(:)’, namely ‘h'collapse xs’ In the expression: x : h'collapse xs • Relevant bindings include xs :: NP ĸ ĸ (K ĸ a) xs (bound at /tmp/tJN0.hs:13:8) h'collapse :: NP ĸ k (K ĸ a) t -> [a] (bound at /tmp/tJN0.hs:11:1) Compilation failed. }}} Should it not be able to infer that? The Glorious Glasgow Haskell Compilation System, version 8.1.20160419 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11995> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12878: Use gold linker by default if available on ELF systems
by GHC 31 Jul '17

31 Jul '17

#12878: Use gold linker by default if available on ELF systems -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Driver | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `ld.gold` is both faster and less buggy than `ld.bfd`, but only works on ELF. On ELF systems, we should thus prefer `ld.gold` when it is installed, even when `ld.bfd` is supported (as it is on x86). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12878> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13283: T5435_dyn_asm fails with gold linker
by GHC 31 Jul '17

31 Jul '17

#13283: T5435_dyn_asm fails with gold linker -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.1 System (Linker) | 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 tried validating with `ld.gold` as my system linker and one test failed: {{{ cd "./rts/T5435_dyn_asm.run" && $MAKE -s --no-print-directory T5435_dyn_asm T5435_dyn_asm failed with ['initArray1', 'initArray2', 'ctors2', 'ctors1', 'success'], see all.T for details }}} The expected output has `ctors1` and then `ctors2`. This looks like a bug in gold to me. ezyang, do you agree? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13283> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9020: Massive blowup of code size on trivial program
by GHC 31 Jul '17

31 Jul '17

#9020: Massive blowup of code size on trivial program ------------------------------------+------------------------------------- Reporter: simonpj | 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: | ------------------------------------+------------------------------------- The test `simplCore/should_compile/simpl015` was leading to massive compile times. This is weird: it looks like: {{{ main = do { return () ; return () ... hundreds more times ... ; return () } }}} It turns out that the cause was over-eager eta-expansion. Each `return ()` gives a top-level PAP thus {{{ lvl17 :: IO () lvl17 = returnIO () }}} But these definitions are then eta-expanded, thus: {{{ lvl17 = ((\eta. returnIO () |> sym g) eta) |> g where g :: State# RealWorld -> (# State# RealWorld, () #) ~ IO () }}} Now in general it makes sense to eta-expand through newtypes (as is done here), because it exposes more lambadas. But it really doesn't make sense to eta-expand a PAP like this. Fortunately the fix is easy: use `exprArity` rather than `manifestArity` in `SimplUtils.tryEtaExpandRhs`. The effect on `simpl015` is dramatic: compiler allocation drops from 6.6G to 812M; and residency drops from 1.8G to 45M. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9020> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13