February 2018 - ghc-tickets

[GHC] #14866: GHC 8.4.1 rc1 segfaults when compiling the influxdb package
by GHC 28 Feb '18

28 Feb '18

#14866: GHC 8.4.1 rc1 segfaults when compiling the influxdb package -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 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: -------------------------------------+------------------------------------- I tried to build influxdb-1.2.2.3 with GHC 8.4.1 rc1 built with DYNAMIC_GHC_PROGRAMS=NO. Then I got {{{ [ 8 of 10] Compiling Database.InfluxDB.Query ( src/Database/InfluxDB/Query.hs, /home/fumieval/hs/influxdb-haskell/dist- newstyle/build/x86_64-linux/ghc-8.4.0.20180224/influxdb-1.2.2.3/build/Database/InfluxDB/Query.p_o ) cabal: Failed to build influxdb-1.2.2.3. The build process segfaulted (i.e. SIGSEGV). }}} It seems to be related to Template Haskell, as it doesn't happen if I remove `makeLensesWith` in `Query.hs`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14866> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14196: Replace ArrayArray# with either UnliftedArray# or Array#
by GHC 27 Feb '18

27 Feb '18

#14196: Replace ArrayArray# with either UnliftedArray# or Array# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Just to be clear, there currently is nothing named `UnliftedArray#`. I would like to propose that such a thing possibly be added, with the long- term goal of deprecating and removing `ArrayArray#`. The interface for it would look like this: {{{#!hs data UnliftedArray# (a :: TYPE 'UnliftedRep) data MutableUnliftedArray# s (a :: TYPE 'UnliftedRep) indexUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). UnliftedArray# a -> Int# -> a writeUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). MutableUnliftedArray# s a -> Int# -> a -> State# s -> State# s readUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). MutableUnliftedArray# s a -> Int# -> State# s -> (# State# s, a #) unsafeFreezeUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). MutableUnliftedArray# s a -> State# s -> (#State# s, UnliftedArray# a#) newUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). Int# -> a -> State# s -> (# State# s, MutableUnliftedArray# s a #) }}} You would also have a few other things like `sameMutableUnliftedArray#`, `sizeofMutableArray#`, `unsafeThawUnliftedArray#`, `copyUnliftedArray#`, etc. The main difficulty that I see in doing this is that I'm not sure if you can tell a primop that it takes a polymorphic argument whose kind is something other than `TYPE LiftedRep`. The bodies of all of the functions I listed above could simply be copied from the `ArrayArray#` functions. There are a few alternatives I've heard discussed. One is to make `Array#` accepted both boxed or unboxed types. There is a brief discussion of this in the UnliftedDataTypes proposal [#point0 (0)]. Indeed, it appears that some have managed to smuggle unlifted data into `Array#` already, with the caveats one would expect [#point1 (1)]. This interface would look like: {{{#!hs data Array# (a :: TYPE k) data MutableArray# s (a :: TYPE k) indexArray# :: Array# a -> Int -> a -- same as before indexUnliftedArray# :: forall (a :: TYPE UnliftedRep). Array# a -> Int -> a }}} So instead of having `Array#` and `UnliftedArray#` as separate data types, we could have `Array#` handle both cases, but we would need to make a duplicate of every function that operates on `Array#`. This follows all of the appropriate rules for when levity polymorphism is allowed, and it should be backwards-compatible with the previous non-levity-polymorphic definition of `Array#`. I'm not sure how many things in the GHC runtime assume that the values inside an array are lifted, so this might cause a bunch of problems. If it is possible, this approach would be kind of neat because then `SmallArray#` could be similarly adapted. Anyway, I just wanted to get this out there. I would be happy to try implementing the first proposal (involving `UnliftedArray#`) at some point in the next six months. Any feedback on the idea would be appreciated. Also, any comments on how appropriate this is for someone new to contributing to GHC would be appreciated as well. Thanks. * [=#point0 (0)] https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes#Parametricity * [=#point0 (1)] https://www.reddit.com/r/haskell/comments/6v9rmg/an_unified_array_interface… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14196> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #7503: Bug with PolyKinds, type synonyms & GADTs
by GHC 27 Feb '18

27 Feb '18

#7503: Bug with PolyKinds, type synonyms & GADTs -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.1 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14451 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by kcsongor): * wikipage: => https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7503#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #855: Improvements to SpecConstr
by GHC 27 Feb '18

27 Feb '18

#855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Long story short, I had success with the following [https://github.com/sgraf812/ghc/compare/master...sgraf812:stream-fusion diff]. Currently, it optimizes `ex1` to this code: {{{ -- RHS size: {terms: 39, types: 21, coercions: 0, joins: 3/3} Main.$wex1 [InlPrag=NOINLINE] :: GHC.Prim.Int# -> GHC.Prim.Int# [GblId, Arity=1, Caf=NoCafRefs, Str=<S,U>, Unf=OtherCon []] Main.$wex1 = \ (ww_s4pl :: GHC.Prim.Int#) -> joinrec { $s$wgo_s4rk :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# [LclId[JoinId(3)], Arity=3, Str=<L,A><S,U><S,U>] $s$wgo_s4rk _ [Occ=Dead] (sc1_s4ri :: GHC.Prim.Int#) (sc2_s4rh :: GHC.Prim.Int#) = jump $s$wgo2_s4rc sc1_s4ri sc2_s4rh; $s$wgo1_s4rg :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# [LclId[JoinId(3)], Arity=3, Str=<S,U><S,U><S,U>] $s$wgo1_s4rg (sc_s4rf :: GHC.Prim.Int#) (sc1_s4re :: GHC.Prim.Int#) (sc2_s4rd :: GHC.Prim.Int#) = jump $s$wgo_s4rk sc_s4rf sc1_s4re (GHC.Prim.+# sc2_s4rd sc_s4rf); $s$wgo2_s4rc [Occ=LoopBreaker] :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# [LclId[JoinId(2)], Arity=2, Str=<S,U><S,U>, Unf=OtherCon []] $s$wgo2_s4rc (sc_s4rb :: GHC.Prim.Int#) (sc1_s4ra :: GHC.Prim.Int#) = case GHC.Prim.<# sc_s4rb ww_s4pl of { __DEFAULT -> sc1_s4ra; 1# -> jump $s$wgo1_s4rg (GHC.Prim.*# sc_s4rb sc_s4rb) (GHC.Prim.+# sc_s4rb 1#) sc1_s4ra }; } in jump $s$wgo2_s4rc 1# 0# }}} Which is just a stone throw (or rather an inlining pass) away from the `goal`! For the examples `ex{2,3}` with increasing nesting level, things don't look so bright yet. Also I got some cleanup work to do tomorrow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/855#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5927: A type-level "implies" constraint on Constraints
by GHC 27 Feb '18

27 Feb '18

#5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Keywords: Resolution: duplicate | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Hm. That is not at all how I would have expected that instance to be solved. I agree that when typechecking `$dmshowsPrec`, we should start with: * `[W] Show (Exists c)` But don't we get that immediately? In other words, this typechecks: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE UndecidableInstances #-} module T5927 where import Text.Show data Exists c where Exists :: c a => a -> Exists c instance Show (Exists c) where show = show showsPrec = undefined showList = undefined }}} Because when typechecking the RHS of `show`, we need `[W] Show (Exists c)`, but we already have that. It's only when we strengthen the context: {{{#!hs instance (forall a. c a => Show a) => Show (Exists c) where show = show showsPrec = undefined showList = undefined }}} That GHC complains: {{{ Bug.hs:12:10: error: • Could not deduce: c (Exists c) arising from a use of ‘show’ from the context: forall a. c a => Show a bound by the instance declaration at Bug.hs:11:10-53 • In the expression: show In an equation for ‘show’: show = show In the instance declaration for ‘Show (Exists c)’ • Relevant bindings include show :: Exists c -> String (bound at Bug.hs:12:3) | 12 | show = show | ^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5927#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14861: QuantifiedConstraints: Can't use forall'd variable in context
by GHC 27 Feb '18

27 Feb '18

#14861: QuantifiedConstraints: Can't use forall'd variable in context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints wipT2893 | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This fails to typecheck, to my surprise: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind data ECC1 :: (Type -> Constraint) -> (Type -> Type) -> Type -> Type where ECC1 :: c p => f p -> ECC1 c f p class Foldable' f where foldMap' :: Monoid m => (a -> m) -> f a -> m instance (forall p. c p => Foldable' f) => Foldable' (ECC1 c f) where foldMap' f (ECC1 x) = foldMap' f x instance Foldable' [] where foldMap' = foldMap test :: ECC1 Show [] Ordering -> Ordering test = foldMap' id }}} {{{ $ ghc-cq/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:18:25: error: • Could not deduce: c p0 arising from a use of ‘foldMap'’ from the context: forall p. c p => Foldable' f bound by the instance declaration at Bug.hs:17:10-63 or from: Monoid m bound by the type signature for: foldMap' :: forall m a. Monoid m => (a -> m) -> ECC1 c f a -> m at Bug.hs:18:3-10 or from: c a bound by a pattern with constructor: ECC1 :: forall (f :: * -> *) p (c :: * -> Constraint). c p => f p -> ECC1 c f p, in an equation for ‘foldMap'’ at Bug.hs:18:15-20 • In the expression: foldMap' f x In an equation for ‘foldMap'’: foldMap' f (ECC1 x) = foldMap' f x In the instance declaration for ‘Foldable' (ECC1 c f)’ • Relevant bindings include foldMap' :: (a -> m) -> ECC1 c f a -> m (bound at Bug.hs:18:3) | 18 | foldMap' f (ECC1 x) = foldMap' f x | ^^^^^^^^^^^^ }}} I would have expected the `(forall p. c p => Foldable' f)` quantified constraint to kick in there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14861> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #5927: A type-level "implies" constraint on Constraints
by GHC 27 Feb '18

27 Feb '18

#5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Keywords: Resolution: duplicate | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hmm. This is interesting. We have {{{ $dmshowsPrec :: Show a => Int -> a -> ShowS }}} and the implied instance decl is {{{ instance (forall a. c a => Show a) => Show (Exists c) where show (Exists a) = show a showsPrec = $dmshowsPrec }}} From the RHS of `showsPred` we get `[W] Show (Exists c)`. And ''alas'' we try to solve that from the quantified constraint (which takes precedence over top-level instances), by instantiating `a` to `(Exists c)`. So we get {{{ [W} c (Exists c) }}} which we can't solve. This would happen on any recursive invocation of a method at the same type. It's not clear what we want here. The quantified constraint claims to provide an instance ''for every type a'' which is jolly suspicious. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5927#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14864: Suggestion: Turn on +RTS -xt by default
by GHC 27 Feb '18

27 Feb '18

#14864: Suggestion: Turn on +RTS -xt by default -------------------------------------+------------------------------------- Reporter: ryantrinkle | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Runtime | Version: 8.2.2 System | 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 found it quite surprising and difficult to debug that my heap profile showed no leak while the GC stats showed a clear leak. As a user who is somewhat familiar with this stuff, I was quite surprised that those two data sources didn't agree. I wasn't sure how to determine why they disagreed, since none of the output referenced anything interesting. I'm not familiar with the reasoning behind disabling -xt by default, but I think it may be easier for users to figure out that they need to *disable* it (since they'll be able to see its results in the heap profile) than to figure out that they need to *enable* it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14864> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14835: QuantifiedConstraints: Can't deduce "(a, b)" from "a" and "b"
by GHC 27 Feb '18

27 Feb '18

#14835: QuantifiedConstraints: Can't deduce "(a, b)" from "a" and "b" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs, LiberalTypeSynonyms, TypeOperators, MultiParamTypeClasses, FlexibleInstances #-} data Dict c where Dict :: c => Dict c infixr |- class (a => b) => (a |- b) instance (a => b) => (a |- b) type a :- b = Dict (a |- b) class ((a, b) => c) => Curried a b c instance ((a, b) => c) => Curried a b c curryC :: forall a b c. ((a, b) |- c) :- (a |- b |- c) curryC = Dict }}} This fails with {{{ GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Test.hs, interpreted ) /tmp/Test.hs:16:10: error: • Could not deduce (a, b) arising from a use of ‘Dict’ from the context: (a, b) |- c bound by a quantified context at /tmp/Test.hs:1:1 or from: a bound by a quantified context at /tmp/Test.hs:1:1 or from: b bound by a quantified context at /tmp/Test.hs:1:1 Possible fix: add (a, b) to the context of the type signature for: curryC :: forall (a :: Constraint) (b :: Constraint) (c :: Constraint). ((a, b) |- c) :- (a |- (b |- c)) • In the expression: Dict In an equation for ‘curryC’: curryC = Dict | 16 | curryC = Dict | ^^^^ Failed, no modules loaded. }}} but it works by changing the type of `curryC`: {{{#!hs curryC :: forall a b c. Curried a b c :- (a |- b |- c) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14835> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14833: QuantifiedConstraints: GHC can't deduce (() :: Constraint)?
by GHC 27 Feb '18

27 Feb '18

#14833: QuantifiedConstraints: GHC can't deduce (() :: Constraint)? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs #-} import Data.Kind data Dict c where Dict :: c => Dict c class (a => b) => Implies a b instance (a => b) => Implies a b type a :- b = Dict (Implies a b) iota :: (Implies () a) :- a iota = Dict }}} GHC claims that it can't deduce `(() :: Constraint)` :) {{{ GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/H.hs, interpreted ) /tmp/H.hs:14:8: error: • Could not deduce () :: Constraint arising from a use of ‘Dict’ from the context: Implies () :: Constraint a bound by a quantified context at /tmp/H.hs:1:1 Possible fix: add () :: Constraint to the context of the type signature for: iota :: forall (a :: Constraint). Implies () :: Constraint a :- a • In the expression: Dict In an equation for ‘iota’: iota = Dict | 14 | iota = Dict | ^^^^ Failed, no modules loaded. Prelude> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14833> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4