February 2019 - ghc-tickets

[GHC] #11514: Impredicativity is still sneaking in
by GHC 21 Mar '19

21 Mar '19

#11514: Impredicativity is still sneaking in -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 erroneously accepted: {{{ {-# LANGUAGE RankNTypes #-} module Bug where foo :: forall a. (Show a => a -> a) -> () foo = undefined }}} `undefined` is being instantiated at `(Show a => a -> a) -> ()`, which requires impredicativity. GHC does the right thing (reject!) if we try to instantiate with a type involving proper foralls. I imagine this is a simple missing check. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11514> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14828: panic! when using :print on some functions with class constraints?
by GHC 21 Mar '19

21 Mar '19

#14828: panic! when using :print on some functions with class constraints? -------------------------------------+------------------------------------- Reporter: jol | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 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: -------------------------------------+------------------------------------- These are the problematic ones I've found: {{{ > :t foldl foldl :: Foldable t => (b -> a -> b) -> b -> t a -> b > :print foldl ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1H7[rt] :: TYPE t_a1H6[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :t fmap fmap :: Functor f => (a -> b) -> f a -> f b > :print fmap ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1Hu[rt] :: TYPE t_a1Ht[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :t return return :: Monad m => a -> m a > :print return ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1Wt[rt] :: TYPE t_a1Ws[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :t pure pure :: Applicative f => a -> f a > :print pure ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1WP[rt] :: TYPE t_a1WO[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} These that don't have constraints are fine: {{{ > :print id id = (_t1::a -> a) > :print map map = (_t2::(a1 -> b) -> [a1] -> [b]) > :print const const = (_t3::a2 -> b1 -> a2) }}} This value and function created in the session are fine: {{{ > let x :: Monad m => m (); x = return () Prelude| > :p x x = (_t5::Monad m1 => m1 ()) > let f :: Monad m => Int -> m Int; f n = return (n + 1) Prelude| > :p f f = (_t6::Monad m2 => Int -> m2 Int) }}} mempty and mappend imported from Data.Monoid are fine: {{{ > :m + Data.Monoid > :p mempty mempty = (_t7::Monoid a4 => a4) > :p mappend mappend = (_t8::Monoid a4 => a4 -> a4 -> a4) }}} foldl' and foldr imported from Data.List are not fine: {{{ > :m + Data.List > :p foldl' ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a6Qy[rt] :: TYPE t_a6Qx[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :p Data.List.foldr ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t2_a6RG[rt] :: TYPE t1_a6RF[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} but `all` and `init` from that same module are fine: {{{ > :p Data.List.all all = (_t13::Foldable t1 => (a22 -> Bool) -> t1 a22 -> Bool) > :p Data.List.init init = (_t14::[a29] -> [a29]) }}} So, in a given module, among functions with class constraints, some have the error and others don't. I haven't found a value that's not a function with the error, and I haven't found a function with no class constraints exhibit the error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14828> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13101: Enable GHC to be loaded into GHCi
by GHC 18 Mar '19

18 Mar '19

#13101: Enable GHC to be loaded into GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | 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: -------------------------------------+------------------------------------- It would be very helpful for development to be able to load GHC itself into GHCi. In principle this shouldn't be so hard since GHC is just another Haskell program. However, in practice there are a number of modules which use unboxed tuples, which the interpreter does not support. However, it should be possible to the convince GHC to use object code for just these modules and interpret the rest. I have a few attempts at this here (https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e) See the following related mailing list threads, * https://mail.haskell.org/pipermail/ghc-devs/2017-January/013545.html * https://mail.haskell.org/pipermail/ghc-devs/2016-March/011555.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13101> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15454: Have GHCi automatically use -fobject-code for modules that use UnboxedTuples
by GHC 18 Mar '19

18 Mar '19

#15454: Have GHCi automatically use -fobject-code for modules that use UnboxedTuples -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- This is related to a relatively old issue, that the bytecode interpreter cannot handle UnboxedTuples: https://ghc.haskell.org/trac/ghc/ticket/1257 . Rather than fix that issue, which sounds quite challenging, how about adding some automagic to GHCi which builds object code for modules that use UnboxedTuples? This is a bit trickier than just compiling those modules to object code, because object code cannot be linked against byte code (see https://ghc.haskell.org/trac/ghc/ticket/10965) A potential solution to this is to also build all of the dependencies of modules that use UnboxedTuples using object code. This idea has some precedent, though as an external script - see https://ghc.haskell.org/trac/ghc/ticket/13101 and https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e . I think it would be best to put the solution to this directly in GHCi. What do you think? If y'all think it is a good idea, then I can volunteer to try to make it happen. As described in that ticket, this would be particularly helpful for loading GHC into GHCi, because GHC's code uses UnboxedTuples. Currently, `-fobject-code` must be used, which means that the speedup from using GHCi isn't quite as much as it could be. It is possible to get around this by first loading it with object code and then doing another load without object code, but that's rather inconvenient. Since this may be a surprising behavior change (the user may not have specified -odir and -hidir), it could possibly be enabled via a flag. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15454> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12770: Shrink list of RUNPATH entries for GHC libraries
by GHC 15 Mar '19

15 Mar '19

#12770: Shrink list of RUNPATH entries for GHC libraries -------------------------------------+------------------------------------- Reporter: slyfox | 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: -------------------------------------+------------------------------------- Recently Cabal/GHC acquired '''dynamic-library-dirs''' file tag support in ''' .conf''' files. Cabal-HEAD when used with GHC-HEAD puts all shared libraries into a single directory except the GHC itself (a fallout of https://github.com/haskell/cabal/issues/4046 ). In https://github.com/haskell/cabal/issues/4046#issuecomment-256603828 Christiaan explains our current sources of RUNPATH tags. Basically, current GHC dynamic library layout is still per-directory: {{{ /usr/lib64/ghc-8.1.20161026/Cabal-1.25.0.0/libHSCabal-1.25.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/array-0.5.1.1/libHSarray-0.5.1.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/base-4.9.0.0/libHSbase-4.9.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/binary-0.8.3.0/libHSbinary-0.8.3.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/bytestring-0.10.8.1/libHSbytestring-0.10.8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/compact-1.0.0.0/libHScompact-1.0.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/containers-0.5.7.1/libHScontainers-0.5.7.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/deepseq-1.4.2.0/libHSdeepseq-1.4.2.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/directory-1.2.6.2/libHSdirectory-1.2.6.2-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/filepath-1.4.1.0/libHSfilepath-1.4.1.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghc-8.1/libHSghc-8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghc-boot-8.1/libHSghc- boot-8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghc-boot-th-8.1/libHSghc-boot- th-8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghc-prim-0.5.0.0/libHSghc- prim-0.5.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghci-8.1/libHSghci-8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/haskeline-0.7.2.3/libHShaskeline-0.7.2.3-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/hoopl-3.10.2.1/libHShoopl-3.10.2.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/hpc-0.6.0.3/libHShpc-0.6.0.3-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/integer-gmp-1.0.0.1/libHSinteger- gmp-1.0.0.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/pretty-1.1.3.3/libHSpretty-1.1.3.3-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/process-1.4.2.0/libHSprocess-1.4.2.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_debug-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_l-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_thr-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_thr_debug-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_thr_l-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/template-haskell-2.11.0.0/libHStemplate- haskell-2.11.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/terminfo-0.4.0.2/libHSterminfo-0.4.0.2-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/time-1.6.0.1/libHStime-1.6.0.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/transformers-0.5.2.0/libHStransformers-0.5.2.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/unix-2.7.2.0/libHSunix-2.7.2.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/xhtml-3000.2.1/libHSxhtml-3000.2.1-ghc8.1.20161026.so }}} Could we store them exactly as Cabal does? Namely {{{ dynamic-library-dirs: /usr/lib64/x86_64-linux-ghc-8.1.20161026 }}} Then for globally installed packages (how distributions usually build packages) we would have exactly one RUNPATH. Currently we have: {{{ $ readelf -a /usr/bin/read-idiii | grep RUNPATH 0x000000000000001d (RUNPATH) Library runpath: [/usr/lib64/ghc-8.1.20161026/array-0.5.1.1:/usr/lib64/ghc-8.1.20161026/base-4.9.0.0:/usr/lib64/ghc-8.1.20161026/binary-0.8.3.0:/usr/lib64/ghc-8.1.20161026/bytestring-0.10.8.1:/usr/lib64/ghc-8.1.20161026/containers-0.5.7.1:/usr/lib64/ghc-8.1.20161026/deepseq-1.4.2.0:/usr/lib64/ghc-8.1.20161026/directory-1.2.6.2:/usr/lib64/ghc-8.1.20161026/filepath-1.4.1.0:/usr/lib64/ghc-8.1.20161026 /ghc-prim-0.5.0.0:/usr/lib64/ghc-8.1.20161026/integer- gmp-1.0.0.1:/usr/lib64/ghc-8.1.20161026/process-1.4.2.0:/usr/lib64/ghc-8.1.20161026/rts:/usr/lib64/ghc-8.1.20161026/time-1.6.0.1:/usr/lib64/ghc-8.1.20161026/transformers-0.5.2.0:/usr/lib64/ghc-8.1.20161026/unix-2.7.2.0:/usr/lib64/x86_64 -linux-ghc-8.1.20161026] }}} And that could be just single {{{ /usr/lib64/x86_64-linux-ghc-8.1.20161026 }}} It's close to ticket #11587. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12770> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15382: heapprof001 segfaults in prof_hc_hb way on i386
by GHC 13 Mar '19

13 Mar '19

#15382: heapprof001 segfaults in prof_hc_hb way on i386 --------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- I am seeing the `heapprof001` testcase segmentation fault in the `prof_hc_hb` testsuite way on i386. For instance, https://circleci.com/gh/ghc/ghc/7104. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15382> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #16347: GHC HEAD regression: piResultTys1
by GHC 12 Mar '19

12 Mar '19

#16347: GHC HEAD regression: piResultTys1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.7 (Type checker) | Keywords: TypeInType | 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 program typechecks on GHC 8.0.2 through 8.6.3, but panics on HEAD: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy data T f :: f Type -> Type where MkT :: T f a }}} {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20190219 for x86_64-unknown-linux): piResultTys1 k_a10k[tau:1] [*] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1063:5 in ghc:Type }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13951: InScope set assertion failure from monad-skeleton
by GHC 12 Mar '19

12 Mar '19

#13951: InScope set assertion failure from monad-skeleton -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE PolyKinds, GADTs, Rank2Types, ScopedTypeVariables, Trustworthy #-} module Control.Monad.Skeleton.Internal where data Cat k a b where Empty :: Cat k a a Leaf :: k a b -> Cat k a b Tree :: Cat k a b -> Cat k b c -> Cat k a c viewL :: forall k a b r. Cat k a b -> ((a ~ b) => r) -> (forall x. k a x -> Cat k x b -> r) -> r viewL Empty e _ = e viewL (Leaf k) _ r = k `r` Empty viewL (Tree a b) e r = go a b where go :: Cat k a x -> Cat k x b -> r go Empty t = viewL t e r go (Leaf k) t = r k t go (Tree c d) t = go c (Tree d t) }}} Leads to the assertion failure {{{ [1 of 1] Compiling Control.Monad.Skeleton.Internal ( Internal.hs, Internal.o ) WARNING: file compiler/simplCore/OccurAnal.hs, line 2160 Just 3 [] ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170708 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {x_avF ds_d14c} tenv [avF :-> x_avF] tenvFVs [avF :-> x_avF, a11Z :-> k_a11Z] cenv [] cenvFVs [] tys [k1_a120 a_a121 x_avF] cos [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1188:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2088:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2121:29 in ghc:TyCoRep substTy, called at compiler/coreSyn/CoreArity.hs:1197:19 in ghc:CoreArity Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1186:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2088:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2121:29 in ghc:TyCoRep substTy, called at compiler/coreSyn/CoreArity.hs:1197:19 in ghc:CoreArity Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13951> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11371: Bogus in-scope set in substitutions
by GHC 12 Mar '19

12 Mar '19

#11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- Bartosz [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010892.html reports] that substitution isn't working properly for him. He cites this Note in `TyCoRep`: {{{ -- Note [Generating the in-scope set for a substitution] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- If we want to substitute [a -> ty1, b -> ty2] I used to -- think it was enough to generate an in-scope set that includes -- fv(ty1,ty2). But that's not enough; we really should also take the -- free vars of the type we are substituting into! Example: -- (forall b. (a,b,x)) [a -> List b] -- Then if we use the in-scope set {b}, there is a danger we will rename -- the forall'd variable to 'x' by mistake, getting this: -- (forall x. (List b, x, x)) -- Urk! This means looking at all the calls to mkOpenTCvSubst.... }}} I think this is an outright bug that has been lurking for ages, and which Bartosz has just managed to tickle. Things to do: * We should add an ASSERT to substTy (and similar functions): **when calling `substTy subst ty` it should be the case that the in-scope set in the substitution is a superset of** * **The free vars of the range of the substitution** * **The free vars of ty minus the domain of the substitution** That ASSERT could be added to the immediate callers of `subst_ty` in `TyCoRep`. (Bartosz: if you add that you should find that it trips before the bug you are actually getting.) * How to fix it properly? The places to look are: everywhere that uses (transitively) one of the `mkOpenTCvSubst` or `zipOpenTCvSubst` functions. * Many calls to `mkOpenTCvSubst` produce a substitution that is only applied to closed types; or at least to types whose only free variables are the ones in the domain of the substitution. Example: the call to `zipOpenTCvSubst` in `DataCon.dataConInstSig`. These ones will all satisfy the ASSERT[[BR]][[BR]] * In other cases, we already have the in-scope set in hand. Example: in `CoreLint.lintTyApp` we find a call to `substTyWith`. But Lint carries an in-scope set, so it would be easy to pass it to `substTyWith`.[[BR]][[BR]] * Finally there may be cases where we really have to take the free vars of the type we are substituting into, and add them to the in-scope set. Doubtless all this applies to substituting in coercions too, and indeed into expressions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11371> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 64

[GHC] #16344: GHC infers over-polymorphic kinds
by GHC 11 Mar '19

11 Mar '19

#16344: GHC infers over-polymorphic kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Consider {{{ data T ka (a::ka) b = MkT (T Type Int Bool) (T (Type -> Type) Maybe Bool) }}} GHC accepts this ''even though it uses polymorphic recursion''. But it shouldn't -- we simply do not have reliable way to infer most general types in the presence of polymorphic recursion. In more detail, in `getInitialKinds`, GHC chooses this (bogus) "monomorphic" kind for T: {{{ T :: forall (ka :: kappa1) -> ak -> kappa2 -> Type }}} where `kappa1` and `kappa1` are unification variables. Then it kind- checks the data constructor declaration, given this mono-kind -- and succeeds! But this is extremely fragile. At call-sites of T we are going to instantiate T's kind. But what if `kappa2` is (somewhere, somehow) late unified wtih `ka`. Then, when instantiating T's kind with `ka := blah`we should get `blah -> blha -> Type`. So how it instantiates will vary depending on what we konw about `kappa2`. No no no. The initial monomorphic kind of T (returned by `getInitialKinds`, and used when checking the recursive RHSs) should be {{{ T :: kappa1 -> kappa2 -> kappa3 -> Type }}} Then indeed this program will be rejected, but so be it. Consider {{{ data T ka (a::ka) b = MkT (T Type Int Bool) (T (Type -> Type) Maybe Bool) }}} GHC accepts this ''even though it uses polymorphic recursion''. But it shouldn't -- we simply do not have reliable way to infer most general types in the presence of polymorphic recursion. In more detail, in `getInitialKinds`, GHC decides this "monomorphic" kind for T: {{{ T :: forall (ka :: kappa1) -> ka -> kappa2 -> Type }}} where `kappa1` and `kappa1` are unification variables. Then it kind- checks the data constructor declaration, given this mono-kind -- and succeeds! But this is extremely fragile. At call-sites of T we are going to instantiate T's kind. But what if `kappa2` is (somewhere, somehow) late unified wtih `ka`. Then, when instantiating T's kind with `ka := blah` we might get `blah -> blah -> Type` or `blah -> kappa2 -> Type`, depending on whether `kappa2 := ka` has happened yet. No no no. The initial monomorphic kind of T (returned by `getInitialKinds`, and used when checking the recursive RHSs) should be {{{ T :: kappa1 -> kappa2 -> kappa3 -> Type }}} Then indeed this program will be rejected, but so be it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16344> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6