February 2017 - ghc-tickets

[GHC] #10800: vector-0.11
by GHC 13 Apr '17

13 Apr '17

#10800: vector-0.11 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- vector-0.11 takes substantially longer to compile with 7.10 than 7.8 Unfortunately the issue appears to be in generated code. Lacking time right now so I'm just going to drop the IRC log here, Compile log: https://travis-ci.org/haskell/vector/builds/56179052 {{{ * hvr thought some compile-time improvements landed in 7.10.2 <dolio> I don't think it uses sufficiently less memory to prevent it from using all memory on travis and failing. <dolio> Which is why it suddenly went from 8 minutes to 35. <dolio> Although it's also significantly worse even when you have enough memory. <dolio> hvr: 7.8.4 takes 4m40s, 7.10.2 takes 16m40s. <dolio> i7 4770, 32GB RAM. <dolio> vector 0.11 branch. <dolio> It's not as bad in the 0.10 branch. <dolio> It uses like 60% more memory, too. <dolio> Maybe more. <dolio> It's really just one or two files in the test suite that take all the time/memory. <hvr> dolio: does vector do some aggressive INLINEing? <dolio> Well, yes. <hvr> more in 0.11 than in 0.10? <dolio> It does more stuff in 0.11, yes. <bgamari> vector 0.11 has this new chunked streaming abstraction IIRC <hvr> there's a generic one though iirc <dolio> 0.11 introduced the generalized stream fusion, so there's like three different things going on that specialization has to select one of. <dolio> Instead of just one thing like in 0.10. <dolio> Anyhow, the problem file(s) generate a bunch of tests using template Haskell, so they're pretty opaque. <dolio> I'm pretty sure it's the generated code that's the problem, though. <dolio> Not the template haskell that generates it. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10800> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9066: Template Haskell cannot splice an infix declaration for a data constructor
by GHC 13 Apr '17

13 Apr '17

#9066: Template Haskell cannot splice an infix declaration for a data constructor ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: | ------------------------------------+------------------------------------- When I say {{{ $([d| data Blargh = (:<=>) Int Int infix 4 :<=> |]) }}} I get {{{ Illegal variable name: ‘:<=>’ When splicing a TH declaration: infix 4 :<=>_0 }}} The code inside the TH quote works when not used with TH. I will fix in due course. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9066> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10109: Kinds aren't checked in the coverage condition
by GHC 13 Apr '17

13 Apr '17

#10109: Kinds aren't checked in the coverage condition -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Following on from the debate in #9103 (but you don't need to read that ticket), I found a curiosity. The following module fails to compile, complaining about the unsatisfied coverage condition: {{{ {-# LANGUAGE PolyKinds, MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, UndecidableInstances #-} module Bug where data Succ a class Add (a :: k1) (b :: k2) (ab :: k3) | a b -> ab, a ab -> b instance (Add a b ab) => Add (Succ a) b (Succ ab) }}} With `-fprint-explicit-kinds`, I get {{{ Bug.hs:9:10: Illegal instance declaration for ‘Add * k * (Succ k a) b (Succ k ab)’ The liberal coverage condition fails in class ‘Add’ for functional dependency: ‘a b -> ab’ Reason: lhs types ‘Succ k a’, ‘b’ do not jointly determine rhs type ‘Succ k ab’ In the instance declaration for ‘Add (Succ a) b (Succ ab)’ }}} But, when I add `k3` to the right-hand side of the first functional dependency (viz. {{{ {-# LANGUAGE PolyKinds, MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, UndecidableInstances #-} module Bug where data Succ a class Add (a :: k1) (b :: k2) (ab :: k3) | a b -> ab k3, a ab -> b instance (Add a b ab) => Add (Succ a) b (Succ ab) }}} ) I get {{{ [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, modules loaded: Bug. }}} I always assumed that fixing a type in a fundep also fixed its kind. I get the same behavior in 7.8 as in 7.10.1RC2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10109> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10564: GHC 7.10.2 RC cannot build HList-0.4.0.0
by GHC 13 Apr '17

13 Apr '17

#10564: GHC 7.10.2 RC cannot build HList-0.4.0.0 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Another Stackage find: http://lpaste.net/135061 {{{ Data/HList/Record.hs:575:10: Illegal instance declaration for ‘HasFieldM l (r xs) v’ The liberal coverage condition fails in class ‘HasFieldM’ for functional dependency: ‘l r -> v’ Reason: lhs types ‘l’, ‘r xs’ do not jointly determine rhs type ‘v’ In the instance declaration for ‘HasFieldM l (r xs) v’ Data/HList/Record.hs:587:10: Illegal instance declaration for ‘HasField l (Record (Tagged l1 v1 : r)) v’ The liberal coverage condition fails in class ‘HasField’ for functional dependency: ‘l r -> v’ Reason: lhs types ‘l’, ‘Record (Tagged l1 v1 : r)’ do not jointly determine rhs type ‘v’ In the instance declaration for ‘HasField l (Record (Tagged l1 v1 : r)) v’ Data/HList/Record.hs:646:10: Illegal instance declaration for ‘HDeleteAtLabel Record l v v'’ The liberal coverage condition fails in class ‘HDeleteAtLabel’ for functional dependency: ‘l v -> v'’ Reason: lhs types ‘l’, ‘v’ do not jointly determine rhs type ‘v'’ In the instance declaration for ‘HDeleteAtLabel Record l v v'’ Data/HList/Record.hs:723:10: Illegal instance declaration for ‘HUpdateAtLabel2 l v (Tagged l' e : xs) xs'’ The liberal coverage condition fails in class ‘HUpdateAtLabel2’ for functional dependency: ‘l r v -> r'’ Reason: lhs types ‘l’, ‘Tagged l' e : xs’, ‘v’ do not jointly determine rhs type ‘xs'’ In the instance declaration for ‘HUpdateAtLabel2 l v (Tagged l' e : xs) xs'’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10564> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10570: Too restrictive liberate coverage condition
by GHC 13 Apr '17

13 Apr '17

#10570: Too restrictive liberate coverage condition -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hello! Let's look at this small example: {{{haskell class ConsByIdx2 x a m cls | x -> m where consByIdx2 :: x -> a -> m cls instance ConsByIdx2 Int a Proxy cls where consByIdx2 _ _ = Proxy }}} It fails to compile with the following error: {{{haskell Illegal instance declaration for ‘ConsByIdx2 Int a Proxy cls’ The liberal coverage condition fails in class ‘ConsByIdx2’ for functional dependency: ‘x -> m’ Reason: lhs type ‘Int’ does not determine rhs type ‘Proxy’ In the instance declaration for ‘ConsByIdx2 Int a Proxy cls’ }}} But Int determines the Proxy in a nice way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10570> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10797: Kind-level functional dependencies are not resolved properly
by GHC 13 Apr '17

13 Apr '17

#10797: Kind-level functional dependencies are not resolved properly -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hello! Let's consider such funny class and its instances. {{{ {-# LANGUAGE PolyKinds #-} ... class BaseType (a :: k) (b :: l) | a -> b, k -> l where baseType :: Proxy a -> Proxy b instance BaseType (a :: j -> k) (out :: l) => BaseType (a (t :: j) :: k) (out :: l) }}} The instance does not compile: {{{ Illegal instance declaration for ‘BaseType (a t) out’ The liberal coverage condition fails in class ‘BaseType’ for functional dependency: ‘k -> l’ Reason: lhs type ‘k’ does not determine rhs type ‘l’ In the instance declaration for ‘BaseType (a (t :: j) :: k) (out :: l)’ }}} While the LHS determines the RHS. The problem is that it seems, that GHC doesn't infer the functional dependency of {{{k ~> l}}} from the dependency {{{j -> k ~> l}}}.. I've used a {{{~>}}} arrow to indicate fundeps. Is this a bug or am I missing something? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10797> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12647: Can't capture improvement of functional dependencies
by GHC 13 Apr '17

13 Apr '17

#12647: Can't capture improvement of functional dependencies -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple FunctionalDependencies | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [http://www.diku.dk/~paba/pubs/files/serrano15haskell-paper.pdf Type Families with Class, Type Classes with Family] discusses [https://gist.github.com/Icelandjack/5afdaa32f41adf3204ef9025d9da2a70#pdf- instance-improvement instance improvement] with the example {{{#!hs class Collection c e | c -> e where empty :: c add :: e -> c -> c instance Collection [a] a where empty :: [a] empty = [] add :: a -> [a] -> [a] add = (:) }}} I wondered how to express that `x ~ Int` can be deduced from `Collection [Int] x` using improvement, I first attempted using the [https://hackage.haskell.org/package/constraints constraints] machinery: {{{#!hs data Dict c where Dict :: c => Dict c newtype a :- b = Sub (a => Dict b) }}} but I'm not able to construct a term of type `Collection [Int] x :- (Int ~ x)` proving that `Collection [Int] x` entails `Int ~ x`: {{{ ghci> Sub Dict :: Collection [Int] x :- (Int ~ x) <interactive>:52:5: error: • Couldn't match type ‘x1’ with ‘Int’ arising from a use of ‘Dict’ ‘x1’ is a rigid type variable bound by an expression type signature: forall x1. Collection [Int] x1 :- Int ~ x1 at <interactive>:52:13 • In the first argument of ‘Sub’, namely ‘Dict’ In the expression: Sub Dict :: Collection [Int] x :- (Int ~ x) In an equation for ‘it’: it = Sub Dict :: Collection [Int] x :- (Int ~ x) }}} Is this due to overlapping instances or something? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12704: Check if constraint synonym satisfies functional dependencies
by GHC 13 Apr '17

13 Apr '17

#12704: Check if constraint synonym satisfies functional dependencies -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | 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: -------------------------------------+------------------------------------- When we resolve #12679, it will be possible to implement an abstract type class using a constraint synonym. However, in my implementation, I didn't implement functional dependency checking: {{{ signature H where class F a b | a -> b -- This should be an invalid implementation module H where type F a b = (Eq a, Eq b) }}} The check is annoying fiddly: we have to descend into the constraint synonym, collect all the implied fundeps, and then see if we have the ones we need, so I didn't implement it. Maybe some time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12763: Incorrect behavior with empty functional dependencies
by GHC 13 Apr '17

13 Apr '17

#12763: Incorrect behavior with empty functional dependencies -------------------------------------+------------------------------------- Reporter: diatchki | 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a corner case, but it would appear that GHC doesn't do proper improvements for classes with "empty" functional dependencies. Consider the following example: {{{#!hs class C a | -> a where m :: a -> () instance C Int f x = m x }}} The inferred type for `f` is `C a => a -> ()`, however I was expecting it to infer `Int -> ()`. The reasoning is as follows: the use of `m` generates a `C a` constraint (`a` is a unification variable). This should have interacted with the `C Int` instance (in a rather odd vacuous sort of way) to generate a derived constraint `a ~ Int`, which should have then instantiated `a` to `Int`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13160: Simplify CoreFV.FVAnn
by GHC 12 Apr '17

12 Apr '17

#13160: Simplify CoreFV.FVAnn -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- When introducing type-in-type, Richard elaborated the free varaible finder so that it finds three things at once (in `CoreFV`): {{{ data FVAnn = FVAnn { fva_fvs :: DVarSet -- free in expression , fva_ty_fvs :: DVarSet -- free only in expression's type , fva_ty :: Type -- expression's type } }}} I think `fva_ty` is needed only to support `fva_ty_fvs`. And `fva_ty_fvs` seems to be used only to support the calls to `freeVarsOfType` in `FloatIn`. And those calls in turn are only to suppor `used_in_ty` in `FloatIn.sepBindsByDropPoint`. In conversation yesterday, Richard and I agreed that all this is unnecessary. Coercion bindings simply do not float inwards, so we do not need to take these precautions. (We should add a Note to explain why they don't float, and what problem might arise if they did.) To confirm this I set `used_in_ty` to `False` and compiled from scratch; everything is fine. So I propose that we * get rid of the `ty_fvs` argument to `sepBindsByDropPoint` * simplfy `FVAnn` to just gather free variables (ie one field only) Result: it's all simpler. Richard will do this when he gets a moment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13160> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6