- ghc-tickets - Haskell.org

[GHC] #15825: Core Lint error from Explicit Foralls Proposal
by GHC 29 Oct '18

29 Oct '18

#15825: Core Lint error from Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- This is using the recent Explicit Foralls Proposal #14268 {{{#!hs {-# Language RankNTypes #-} {-# Language PolyKinds #-} {-# Language KindSignatures #-} {-# Language DataKinds #-} {-# Language FlexibleInstances #-} {-# Options_GHC -dcore-lint #-} type C k = (forall (x::k). *) class X (a :: *) instance forall (a :: C k). X (a :: *) }}} {{{ $ ./inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci /tmp/599_bug.hs GHCi, version 8.7.20181025: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 599_bug.hs, interpreted ) *** Core Lint errors : in result of Desugar (before optimization) *** <no location info>: warning: In the expression: C:X @ a_a1yJ Kind application error in type ‘a_a1yJ’ Function kind = C k_a1yI Arg kinds = [(x_a1yH, k_a1yG)] Forall: x_a1xE k_a1yI (x_a1yH, k_a1yG) <no location info>: warning: In the expression: C:X @ a_a1xG Kind application error in type ‘a_a1xG’ Function kind = C k_X1xQ Arg kinds = [(x_a1yv, k_a1xF)] Forall: x_a1xE k_X1xQ (x_a1yv, k_a1xF) *** Offending Program *** Rec { $tcX :: TyCon [LclIdX] $tcX = TyCon 6136962148358085538## 2047526523769221729## $trModule (TrNameS "X"#) 0# $krep_a1zH $tc'C:X :: TyCon [LclIdX] $tc'C:X = TyCon 12994509767826319747## 2028070155085790741## $trModule (TrNameS "'C:X"#) 1# $krep_a1zJ $krep_a1zK [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1zK = $WKindRepVar (I# 0#) $krep_a1zH [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1zH = KindRepFun krep$* $krep_a1zI $krep_a1zI [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1zI = KindRepTyConApp $tcConstraint ([] @ KindRep) $krep_a1zJ [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1zJ = KindRepTyConApp $tcX (: @ KindRep $krep_a1zK ([] @ KindRep)) $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Main"#) $fXa [InlPrag=NOUSERINLINE CONLIKE] :: forall k (x :: k) k (a :: C k). X a [LclIdX[DFunId], Unf=DFun: \ (@ k_a1xF) (@ (x_a1yv :: k_a1xF)) (@ k_a1xF) (@ (a_a1xG :: C k_a1xF)) -> C:X TYPE: a_a1xG] $fXa = \ (@ k_a1yG) (@ (x_a1yH :: k_a1yG)) (@ k_a1yI) (@ (a_a1yJ :: C k_a1yI)) -> C:X @ a_a1yJ end Rec } *** End of Offense *** <no location info>: error: Compilation had errors *** Exception: ExitFailure 1 > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15825> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15076: Typed hole causes GHC to panic (No skolem info)
by GHC 29 Oct '18

29 Oct '18

#15076: Typed hole causes GHC to panic (No skolem info) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: TypedHoles, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #14040 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Spun out from https://ghc.haskell.org/trac/ghc/ticket/14040#comment:2, which was different enough from the original program in #14040 to warrant its own ticket. The following program panics on every version of GHC from 8.0.2 onward: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy newtype S (f :: k1 -> k2) = MkS (forall t. Proxy t -> Proxy (f t)) foo :: forall (a :: Type) (f :: forall (x :: a). Proxy x -> Type). S f -> () foo (MkS (sF :: _)) = () }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.5.20180420: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:15:17: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180420 for x86_64-unknown-linux): No skolem info: [a1_a1Cb[sk:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:3224:5 in ghc:TcErrors }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15076> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15389: -Wall-missed-specialisations warnings not fatal with -Werror
by GHC 29 Oct '18

29 Oct '18

#15389: -Wall-missed-specialisations warnings not fatal with -Werror -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- When compiling a program with GHC 8.4.3, vector 0.12.0.1 (with a dependency on primitive 0.6.4.0) and `-Wall-missed-specialisations -Werror`, warnings are produced, but they aren't fatal. `-Werror` should make them fatal but doesn't. A somewhat-minimal example: {{{#!hs {-# OPTIONS_GHC -Wall-missed-specialisations -Werror #-} {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} module Warnings3 where import GHC.Base (liftM) import qualified Data.Vector.Generic.Base as G (Vector, basicUnsafeFreeze, basicUnsafeThaw, basicLength, basicUnsafeSlice, basicUnsafeIndexM, basicUnsafeCopy, elemseq) import qualified Data.Vector.Generic.Mutable.Base as GM (MVector, basicLength, basicUnsafeSlice, basicOverlaps, basicUnsafeNew, basicInitialize, basicUnsafeReplicate, basicUnsafeRead, basicUnsafeWrite, basicClear, basicSet, basicUnsafeCopy, basicUnsafeMove, basicUnsafeGrow) import qualified Data.Vector.Unboxed as U (Unbox, Vector) import qualified Data.Vector.Unboxed.Mutable as U (MVector) newtype T = T () deriving (Show, Eq, Ord) newtype C = C (U.Vector T) deriving (Show, Eq, Ord) instance U.Unbox T newtype instance U.MVector s T = MV_T (U.MVector s ()) instance GM.MVector U.MVector T where basicLength (MV_T mv) = GM.basicLength mv basicUnsafeSlice i l (MV_T mv) = MV_T (GM.basicUnsafeSlice i l mv) basicOverlaps (MV_T mv1) (MV_T mv2) = GM.basicOverlaps mv1 mv2 basicUnsafeNew l = MV_T `liftM` GM.basicUnsafeNew l basicInitialize (MV_T mv) = GM.basicInitialize mv basicUnsafeReplicate l _ = MV_T `liftM` GM.basicUnsafeReplicate l () basicUnsafeRead (MV_T mv) i = const (T ()) `liftM` GM.basicUnsafeRead mv i basicUnsafeWrite (MV_T mv) i _ = GM.basicUnsafeWrite mv i () basicClear (MV_T mv) = GM.basicClear mv basicSet (MV_T mv) x = GM.basicSet mv () basicUnsafeCopy (MV_T mv1) (MV_T mv2) = GM.basicUnsafeCopy mv1 mv2 basicUnsafeMove (MV_T mv1) (MV_T mv2) = GM.basicUnsafeMove mv1 mv2 basicUnsafeGrow (MV_T mv) l = MV_T `liftM` GM.basicUnsafeGrow mv l newtype instance U.Vector T = V_T (U.Vector ()) instance G.Vector U.Vector T where basicUnsafeFreeze (MV_T mv) = V_T `liftM` G.basicUnsafeFreeze mv basicUnsafeThaw (V_T v) = MV_T `liftM` G.basicUnsafeThaw v basicLength (V_T v) = G.basicLength v basicUnsafeSlice i l (V_T v) = V_T (G.basicUnsafeSlice i l v) basicUnsafeIndexM (V_T v) i = const (T ()) `liftM` G.basicUnsafeIndexM v i basicUnsafeCopy (MV_T mv) (V_T v) = G.basicUnsafeCopy mv v elemseq (V_T v) _ = G.elemseq v () }}} The warnings are: {{{ src/Warnings3.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$w$cshowsPrec’ when specialising ‘Data.Vector.Unboxed.$fShowVector_$cshowsPrec’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$w$cshowsPrec’ src/Warnings3.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$fOrdVector_$cmin’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$fOrdVector_$cmin’ src/Warnings3.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$fOrdVector_$cmax’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$fOrdVector_$cmax’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15389> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15711: Kind inference of class variables does not examine associated types
by GHC 29 Oct '18

29 Oct '18

#15711: Kind inference of class variables does not examine associated types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I say this {{{ {-# LANGUAGE TypeFamilies, PolyKinds, DataKinds #-} module Bug where class C a where type F (x :: Maybe a) }}} then GHCi says this {{{ *Bug> :k C C :: k -> Constraint }}} That's silly. `C` should have kind `Type -> Constraint`, because the usage of `a` in the kind of the associated type constraints `a`'s kind. Will fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15711> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable
by GHC 29 Oct '18

29 Oct '18

#15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Currently packages with .hsc files can't be built with GHC HEAD on some systems becuase of a problem in hsc2hs wrapper script. I don't understand the problem good enough, but we did some debugging with hvr today and he asked me to file a ticket. Here's how to reproduce: {{{ regex-posix-0.95.2 $ cabal new-build --with- ghc=/home/omer/haskell/ghc/inplace/bin/ghc-stage2 Warning: Unknown/unsupported 'ghc' version detected (Cabal 2.4.0.1 supports 'ghc' version < 8.7): /home/omer/haskell/ghc/inplace/bin/ghc-stage2 is version 8.7.20181017 Warning: The package list for 'hackage.haskell.org' is 22 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... Build profile: -w ghc-8.7.20181017 -O1 In order, the following will be built (use -v for more details): - regex-posix-0.95.2 (lib:regex-posix) (first run) Warning: regex-posix.cabal:6:1: The field "build-type" is specified more than once at positions 6:1, 19:1 Configuring regex-posix-0.95.2... Preprocessing library for regex-posix-0.95.2.. hsc2hs: @/home/omer/haskell/regex-posix-0.95.2/dist- newstyle/build/x86_64-linux/ghc-8.7.20181017/regex- posix-0.95.2/build/Text/Regex/Posix/hsc2hs-response17101-2.txt: openBinaryFile: does not exist (No such file or directory) }}} As far as I understand, the problem is that the script runs `hsc2hs -- @foo` instead of `hsc2hs @foo`. Hopefully hvr will correct if I misunderstood. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15758> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7
by GHC 29 Oct '18

29 Oct '18

#15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 -------------------------------------+------------------------------------- Reporter: ki11men0w | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On `Windows 7` call of `ghc-pkg` utility from `32-bit` `ghc-8.2.2` distribution is always ended with `Segmentation fault` error. With use of `Cygwin` the error can be reproduced this way: run `cmd.exe` and in the appeared console window execute the following commands {{{#!bash c:\Users\user.name\wrk> bash $ mkdir ghc-pkg-check $ cd ghc-pkg-check $ curl https://downloads.haskell.org/~ghc/8.2.2/ghc-8.2.2-i386-unknown- mingw32.tar.xz > ghc-8.2.2-i386-unknown-mingw32.tar.xz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 163M 100 163M 0 0 3669k 0 0:00:45 0:00:45 --:--:-- 4776k $ xz -dc ghc-8.2.2-i386-unknown-mingw32.tar.xz | tar -xf - $ cd ghc-8.2.2/bin/ $ ./ghc-pkg.exe --version GHC package manager version 8.2.2 Segmentation fault }}} The error arises irrespective of how and with what arguments to call `ghc- pkg` utility. For example, firstly I has faced the problem using `stack` from Windows console: {{{#!bat > stack build --arch=i386 --resolver=11.9 }}} I checked another distributions of GHC for presence of this bug on `Windows 7`. 64-bit version of ghc-8.2.2, 32-bit and 64-bit versions of ghc-8.0.2 and ghc-8.4.2 are free of the problem. I **did not check** the problem **on another versions** of MS Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15154> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15743: Nail down the Required/Inferred/Specified story
by GHC 29 Oct '18

29 Oct '18

#15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- In a class/data/type declaration we need to say precisely which type variables are Inferred/Specified/Required and, for the specified ones, which order they occur in. See `Note [VarBndrs, TyCoVarBinders, TyConBinders, and visibility]` in `TyCoRep`. Reminder: * Required: explicitly-specified arguments to the type constructor, always appear in any user-written type. * Specified: variables mentioned lexically in the declaration, but not positionally. Available for visible kind application. * Inferred: completely invisible in the declaration; always implicit and not available for visible kind application. The rules for top-level (non-associated) declarations. Running example: {{{ data T (b :: (k2 :: k)) c (a :: k) }}} * Categorisation * Required: the positional arguments in the header (`a`, `b`, `c`) * Specified: all the variables mentioned in the declaration header, that are not Required (`k`, `k2`) * Inferred: all the others (the kind of `c`) * Order. We need to specify the order in which the Specfied variables are quantified. Here is the spec: * Specified variables are always quantified before Required ones. (We could revisit this.) * List the specified variables in the textual order in which they appear [`k2`, `k`] * Sort them into dependency order using ''ScopedSort'' (see below), giving [`k`, `k2`] * Finally quantify Inferred, then Specified, then Required. In the example we get {{{ T :: forall {k1}. forall k k2. k2 -> k1 -> k -> Type }}} The ''ScopedSort'' algorithm works as follows * Do dependency analysis, so for each variable we know what other variables it depends on, transitively. By "depends on" we mean after full kind inference, not just what is written in the source program. * Work left-to-right through the list, with a cursor. * If variable `v` at the cursor is depended on by any earlier variable `w`, move `v` immediately before the leftmost such `w`. The invariant is that the variables to the left of the cursor form a valid telescope. For associated types, use this running example: {{{ class C (a :: k) where type T a (b :: k2) }}} The rules are elaborated a bit for an associated type like `T` * Required: the explicit positional arguments (here `a`, `b`) * Specified: any non-Required variable that is * mentioned (lexically) in the class header and transitively depended on by the Required variables (here `k`), listed left-to-right; followed by * any other variables mentioned in the type header (here `k2`), again listed left-right. * Inferred: all the others, as before. The Specified variables are sorted exactly as before. Relevant tickets * #14887 esp comment:10 (order of Inferred type variables) * #15592 * #15591 comment:4ff (All following discussion with RAE Friday 12 Oct.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15743> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #14552: GHC panic on pattern synonym
by GHC 29 Oct '18

29 Oct '18

#14552: GHC panic on pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, TypeInType, | ViewPatterns | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language RankNTypes, ViewPatterns, PatternSynonyms, TypeOperators, KindSignatures, PolyKinds, DataKinds, TypeFamilies, TypeInType, GADTs #-} import Data.Kind data family Sing a type a --> b = (a, b) -> Type type family (@@) (f::a --> b) (x::a) :: b data Proxy a = Proxy newtype Limit' :: (k --> Type) -> Type where Limit' :: (forall xx. Proxy xx -> f@@xx) -> Limit' f data Exp :: [Type] -> Type -> Type where TLam' :: Proxy f -> (forall aa. Proxy aa -> Exp xs (f @@ aa)) -> Exp xs (Limit' f) pattern FOO f <- TLam' Proxy (($ Proxy) -> f) }}} ---> {{{ $ ghci -ignore-dot-ghci 119-bug.hs GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 119-bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20171122 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {a_a1Mh b_a1Mi rep_a1MB r_a1MC} tenv [a1MC :-> r_a1MC] cenv [] tys [k_a1Mj[ssk:3]] cos [] needInScope [a1Mj :-> k_a1Mj[ssk:3]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1205:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2136:51 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2159:29 in ghc:TyCoRep substTy, called at compiler/types/TyCoRep.hs:2364:41 in ghc:TyCoRep substTyVarBndr, called at compiler/coreSyn/CoreSubst.hs:571:10 in ghc:CoreSubst Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1147:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1203:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2136:51 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2159:29 in ghc:TyCoRep substTy, called at compiler/types/TyCoRep.hs:2364:41 in ghc:TyCoRep substTyVarBndr, called at compiler/coreSyn/CoreSubst.hs:571:10 in ghc:CoreSubst Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14552> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15591: Inconsistent kind variable binder visibility between associated and non-associated type families
by GHC 29 Oct '18

29 Oct '18

#15591: Inconsistent kind variable binder visibility between associated and non- associated type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple TypeApplications, TypeFamilies | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program and GHCi session which uses it: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Foo where import Data.Kind type family T1 (x :: f (a :: Type)) class C (a :: Type) where type T2 (x :: f a) }}} {{{ $ ghc2/inplace/bin/ghc-stage2 --interactive Foo.hs -fprint-explicit- foralls GHCi, version 8.7.20180831: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Ok, one module loaded. λ> :kind T1 T1 :: forall (f :: * -> *) a. f a -> * λ> :kind T2 T2 :: forall {a} (f :: * -> *). f a -> * }}} Something is strange about the visibility of `a` in the kinds of `T1` and `T2`. In `T1`, it's visible, but in `T2`, it's not! I would expect them to both be visible, since they were both mentioned by name in each type family's definition. This isn't of much importance at the moment, but it will be once visible kind application lands, as this bug will prevent anyone from instantiating the `a` in `T2` using a kind application. I indicated 8.5 as the version for this ticket since this behavior has changed since GHC 8.4, where you'd get the following: {{{ $ /opt/ghc/8.4.3/bin/ghci Foo.hs -fprint-explicit-foralls GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Ok, one module loaded. λ> :kind T1 T1 :: forall (f :: * -> *) a. f a -> * λ> :kind T2 T2 :: forall (f :: * -> *) a. f a -> * }}} Here, both `a`s are visible. However, it's still wrong in that `a` should be listed before `f` in `T2`'s telescope, since `a` was bound first (in `C`'s class head), before `f`. In that sense, the current behavior is a slight improvement, although we're not fully correct yet. The only difference between `T1` and `T2` is that `T2` is associated with a class, which suggests that there is some difference in code paths between the two that is accounting for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15591> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15818: Bump template-haskell version to 2.15.0.0
by GHC 29 Oct '18

29 Oct '18

#15818: Bump template-haskell version to 2.15.0.0 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.7 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #2600, #14268 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Commit 512eeb9bb9a81e915bfab25ca16bc87c62252064 (`More explicit foralls (GHC Proposal 0007)`) introduced breaking changes to the Template Haskell AST. As a consequence of this, there are libraries in the wild that now fail to build on GHC HEAD (for instance, [https://github.com/glguy/th- abstraction/issues/55 th-abstraction]). We should properly bump the `template-haskell` library's version number to `2.15.0.0` so that these libraries can guard against these changes using `MIN_VERSION_template_haskell`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15818> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5