May 2018 - ghc-tickets

Re: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb
by GHC 19 May '18

19 May '18

#7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Phab:D4567 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Trac didn't notice that this was reverted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15144: Type inference regression between GHC 8.0.2 and 8.2.2
by GHC 18 May '18

18 May '18

#15144: Type inference regression between GHC 8.0.2 and 8.2.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (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: -------------------------------------+------------------------------------- I observed this when debugging a test case from the `HList` library that works in GHC 8.0.2, but not in GHC 8.2.2 or later. Consider the following minimized example: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Coerce import Data.Proxy type family TagR a class TypeIndexed r tr | r -> tr, tr -> r where typeIndexed :: (Coercible (TagR a) s, Functor f) => Proxy a -> (tr (TagR a) -> f (tr (TagR a))) -> r s -> f (r s) typeIndexed' pa x = typeIndexed pa x }}} In GHC 8.0.2, the type of `typeIndexed'` is correctly inferred as: {{{ $ /opt/ghc/8.0.2/bin/ghci Bug.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, modules loaded: Bug. λ> :t typeIndexed' typeIndexed' :: (Coercible s (TagR a), TypeIndexed r tr, Functor f) => Proxy a -> (tr (TagR a) -> f (tr (TagR a))) -> r s -> f (r s) }}} In GHC 8.2.2 and later, however, the inferred type is less general: {{{ $ /opt/ghc/8.4.2/bin/ghci Bug.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, one module loaded. λ> :t typeIndexed' typeIndexed' :: (TypeIndexed r tr, Functor f) => Proxy a -> (tr (TagR a) -> f (tr (TagR a))) -> r (TagR a) -> f (r (TagR a)) }}} Notice how the `Coercible s (TagR a)` constraint is no longer inferred. Instead, it seems that GHC is inferring the less general constraint `s ~ TagR a`, since `s` has been substituted for `TagR a` in the type `r (TagR a) -> f (r (TagR a))` (whereas in 8.0.2, it was `r s -> f (r s)`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15144> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11515: PartialTypeSignatures suggests a redundant constraint with constraint families
by GHC 18 May '18

18 May '18

#11515: PartialTypeSignatures suggests a redundant constraint with constraint families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: 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: -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE ConstraintKinds, TypeFamilies #-} module Bug where type family ShowSyn a where ShowSyn a = Show a foo :: (ShowSyn a, _) => a -> String foo x = show x }}} I get {{{ Bug.hs:7:20: error: Found constraint wildcard ‘_’ standing for ‘Show a’ To use the inferred type, enable PartialTypeSignatures In the type signature: foo :: (ShowSyn a, _) => a -> String }}} But if I fill in my wildcard with `Show a`, I'll rightly get a redundant constraint. Just a vanilla type synonym works there, but the type family causes trouble. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11515> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12563: Bad error message around lack of impredicativity
by GHC 18 May '18

18 May '18

#12563: Bad error message around lack of impredicativity -------------------------------------+------------------------------------- Reporter: goldfire | 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: -------------------------------------+------------------------------------- (Broken out from #12557.) Consider {{{ foo :: ((forall a. f a) -> f r) -> f r foo g = undefined x = \g -> foo g }}} Compiling this code produces {{{ Scratch.hs:24:15: error: • Couldn't match expected type ‘(forall (a :: k). f a) -> f r’ with actual type ‘t’ ‘t’ is a rigid type variable bound by the inferred type of x :: t -> f r at Scratch.hs:24:1-15 • In the first argument of ‘foo’, namely ‘g’ In the expression: foo g In the expression: \ g -> foo g • Relevant bindings include g :: t (bound at Scratch.hs:24:6) x :: t -> f r (bound at Scratch.hs:24:1) }}} The code should be rejected. But, really, the problem is that the type of a lambda-bound variable can't be a polytype (unless the type is obvious at the binding site). We should improve this error message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12563> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11513: Work out when GADT parameters should be specified
by GHC 18 May '18

18 May '18

#11513: Work out when GADT parameters should be specified -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Right now, there's not a clear specification of when GADT data constructor parameters should be specified, and what order they appear in. For example: {{{ data G a where MkG :: b -> a -> G a }}} To my eye, we should get `MkG :: forall b a. b -> a -> G a`. But GHC now gives `MkG :: a {b}. b -> a -> G a`. At least two things are going on here: 1. GHC puts all universals before existentials. 2. There is an outright bug in `mkDataCon` that makes existentials act as inferred variables, but only for the representation type, not the wrapper type. You can witness (2) by noting that the `b` magically becomes specified if you put a strictness annotation (thereby necessitating the construction of a wrapper) anywhere. I'm not sure what to do about (1), from a design standpoint. Here are some thoughts. A. Having universals always come before existentials is convenient in pattern matching. When we have type application in patterns, you'll want to match only on existentials, never universals. So keeping the existentials together makes some sense. The universals will be omitted from the match entirely. B. FC absolutely requires that the universals come first. So if we allow the user to reorder the variables, that will necessitate creating a wrapper. Are there performance implications? That would be sad. C. We could tread a middle path, where if the user writes a `forall`, they get the order requested. Otherwise, they get universals first (whose order is taken from the ordering in the `data` declaration head) followed by existentials (whose order is taken from left-to-right first occurrence in the constructor type signature). But this is different than for functions, where we always use left-to-right ordering, even when lacking a `forall`. I tend to think that we should always just do what the user asks, but I'm worried about performance implications of this decision. It will make wrappers necessary for existential constructors that otherwise don't need them. Note that this whole debate is about only GADT constructors, not Haskell98 ones. Haskell98 constructors will always have universals before existentials, because that's quite obvious from the way they're declared. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11513> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14691: Replace EvTerm with CoreExpr
by GHC 18 May '18

18 May '18

#14691: Replace EvTerm with CoreExpr -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 (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: -------------------------------------+------------------------------------- I asked > I had some funky idea where a type checker plugin would have to | synthesize code for a custom-solved instances on the fly. But it seems that does not work because EvTerm is less expressive than Core (especially, no lambdas) > > What would break if we had > {{{ > | EvExpr CoreExpr > }}} > as an additional constructor there? And Simon said > This has come up before. I think that'd be a solid win. > > In fact, eliminate all the existing evidence constructors with "smart constructors" that produce an EvExpr. That'd mean moving stuff from the desugarer into these smart constructors, but that's ok. > > I /think/ I didn't do that initially only because there were very few forms and it mean that there was no CoreExpr stuff in the type checker. But as we add more forms that decision looks and less good. > > You'd need to add `zonkCoreExpr` in place of `zonkEvTerm`. > > `evVarsOfTerm` is called quite a bit; you might want to cache the result in the `EvExpr` constructor. This ticket tracks it. Not sure if i get to it right away, but I am happy to advise, review, and play around with the result. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14691> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

[GHC] #9840: Permit empty closed type families
by GHC 18 May '18

18 May '18

#9840: Permit empty closed type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At the moment, closed type families without any equations fail with a parse error. In addition, they cannot be created by TH (see #8028). Would it be possible to permit these instead? My use case is in my typechecker plugin for units of measure, where I want to add new type-level operators without any equational theory (because it will be supplied by the plugin) and without users having the ability to introduce their own type family instances. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9840> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't
by GHC 18 May '18

18 May '18

#12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- The following has been compiled against ghc version 8.1.20161022, my apologies if this bug has already been fixed. The following program compiles fine: {{{#!hs {-# LANGUAGE TypeFamilyDependencies #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ConstraintKinds #-} main :: IO () main = return () type family F p = t | t -> p type IsF p t = (C p, t ~ F p) class C p where f :: (IsF p t) => t f = undefined g :: (IsF p t) => t g = f }}} But if we define a "do nothing" type checker plugin like so: {{{#!hs {-# OPTIONS_GHC -dynamic-too #-} module MyPlugin (plugin) where import Plugins ( Plugin(tcPlugin), defaultPlugin, tcPlugin ) import TcRnTypes ( TcPlugin(TcPlugin), tcPluginInit, tcPluginSolve, tcPluginStop, TcPluginSolver, TcPluginResult(TcPluginContradiction, TcPluginOk) ) plugin :: Plugin plugin = defaultPlugin { tcPlugin = const (Just myPlugin) } myPlugin :: TcPlugin myPlugin = TcPlugin { tcPluginInit = return (), tcPluginSolve = const solver, tcPluginStop = const (return ()) } solver :: TcPluginSolver solver _ _ _ = return $ TcPluginOk [] [] }}} And call it from our original source file by adding: {{{#!hs {-# OPTIONS_GHC -fplugin MyPlugin #-} }}} We get the following error: {{{ pluginbug.hs:18:5: error: • Could not deduce (C p0, t ~ F p0) arising from a use of ‘f’ from the context: IsF p t bound by the type signature for: g :: IsF p t => t at pluginbug.hs:17:1-19 The type variable ‘p0’ is ambiguous Relevant bindings include g :: t (bound at pluginbug.hs:18:1) • In the expression: f In an equation for ‘g’: g = f }}} Note that not just calling my "do nothing" type checking plugin does this, to be sure, instead I called `ghc-typelits-natnormalise` like so: {{{#!hs {-# OPTIONS_GHC -fplugin GHC.TypeLits.Normalise #-} }}} And the same error results. One solution is to remove `(C p)` from the `IsF` type declaration, and instead adding it to `g`s definition, like so: {{{#!hs --type IsF p t = (C p, t ~ F p) type IsF p t = (t ~ F p) --g :: (IsF p t) => t g :: (C p, IsF p t) => t }}} But I'm unsure why this should be necessary, and I certainly don't think this should only be necessary if one calls a type checker plugin. Note that the error requires a type checking plugin to be called, if one does not override `defaultPlugin` like so: {{{#!hs plugin = defaultPlugin { tcPlugin = const (Just myPlugin) } }}} and instead just does: {{{#!hs plugin = defaultPlugin }}} then the issue will not occur. So in summary, it seems that calling a type checking plugin somehow affects ordinary type checking. I don't think this should happen. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12780> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10078: tcPluginStop of a type checker plugin is not called if an error occurs
by GHC 18 May '18

18 May '18

#10078: tcPluginStop of a type checker plugin is not called if an error occurs -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Linux Keywords: | Type of failure: Incorrect result Architecture: x86_64 | at runtime (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When a module using a type checker plugin produces a compiler error the clean up function `tcPluginStop` of the plugin is not called. I am not sure if this is intended, but according to the description of the wiki page (Plugins/TypeChecker) this should always be called. === Test plugin `MyPlugin.hs`: {{{#!hs module MyPlugin ( plugin ) where import Plugins import TcRnTypes import TcPluginM plugin :: Plugin plugin = defaultPlugin { tcPlugin = \clos -> Just $ TcPlugin { tcPluginInit = tcPluginIO $ putStrLn ">>> Plugin Init" , tcPluginSolve = \_ _ _ _ -> do tcPluginIO $ putStrLn ">>> Plugin Solve" return $ TcPluginOk [] [] , tcPluginStop = \_ -> tcPluginIO $ putStrLn ">>> Plugin Stop" } } }}} === Minimal example (with type error) `Main.hs`: {{{#!hs {-# OPTIONS_GHC -fplugin MyPlugin #-} module Main where main :: (Monad m) => m () main = do return 1 }}} Compiling this will lead to the following output: {{{ $ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs [2 of 2] Compiling Main ( Main.hs, Main.o ) >>> Plugin Init >>> Plugin Solve >>> Plugin Solve >>> Plugin Solve Main.hs:6:10: Could not deduce (Num ()) arising from the literal ‘1’ from the context: Monad m bound by the type signature for: main :: Monad m => m () at Main.hs:4:9-25 In the first argument of ‘return’, namely ‘1’ In a stmt of a 'do' block: return 1 In the expression: do { return 1 } }}} Which means `tcPluginStop` was _not_ called. === Minimal example (without type error) `Main.hs`: {{{#!hs {-# OPTIONS_GHC -fplugin MyPlugin #-} module Main where main :: (Monad m) => m () main = do return () }}} Compiling this will lead to the following output: {{{ $ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs [2 of 2] Compiling Main ( Main.hs, Main.o ) [MyPlugin changed] >>> Plugin Init >>> Plugin Solve >>> Plugin Solve >>> Plugin Stop Linking Main ... }}} Which means `tcPluginStop` _was_ called. === Possible solution As far as I can see, the solution to this should be to change the plugin code at the bottom of `typechecker/TcRnDriver.hs` from {{{#!hs withTcPlugins :: HscEnv -> TcM a -> TcM a withTcPlugins hsc_env m = do plugins <- liftIO (loadTcPlugins hsc_env) case plugins of [] -> m -- Common fast case _ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins res <- updGblEnv (\e -> e { tcg_tc_plugins = solvers }) m mapM_ runTcPluginM stops return res where startPlugin (TcPlugin start solve stop) = do s <- runTcPluginM start return (solve s, stop s) }}} to {{{#!hs withTcPlugins :: HscEnv -> TcM a -> TcM a withTcPlugins hsc_env m = do plugins <- liftIO (loadTcPlugins hsc_env) case plugins of [] -> m -- Common fast case _ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins eitherRes <- tryM $ do updGblEnv (\e -> e { tcg_tc_plugins = solvers }) m mapM_ runTcPluginM stops case eitherRes of Left e -> failM Right res -> return res where startPlugin (TcPlugin start solve stop) = do s <- runTcPluginM start return (solve s, stop s) }}} . I have tried this. It compiles and my minimal example delivers the correct result. Are there any arguments against this change? If not, I would try to commit a patch for this problem sometime this weekend. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10078> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11462: Use of typechecker plugin erroneously triggers "unbound implicit parameter" error
by GHC 18 May '18

18 May '18

#11462: Use of typechecker plugin erroneously triggers "unbound implicit parameter" error -------------------------------------+------------------------------------- Reporter: kwf | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (Type checker) | 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: -------------------------------------+------------------------------------- To document this bug, we're going to need a typechecker plugin to test it with. I've built a dummy plugin for this purpose, so we can be sure it is not interference from a particular plugin. {{{dummy-plugin/dummy-plugin.cabal}}} {{{ name: dummy-plugin version: 0.1.0.0 category: Development build-type: Simple cabal-version: >=1.10 library hs-source-dirs: . exposed-modules: DummyPlugin build-depends: base, ghc default-language: Haskell2010 GHC-options: -Wall -O2 }}} {{{dummy-plugin/DummyPlugin.hs}}} {{{#!hs module DummyPlugin(plugin) where import TcRnMonad ( TcPlugin(..), TcPluginResult(..) ) import Plugins ( defaultPlugin, Plugin(..), CommandLineOption ) plugin :: Plugin plugin = defaultPlugin { tcPlugin = Just . thePlugin } thePlugin :: [CommandLineOption] -> TcPlugin thePlugin opts = TcPlugin { tcPluginInit = return () , tcPluginSolve = \_ _ _ _ -> return $ TcPluginOk [] [] , tcPluginStop = \_ -> return () } }}} {{{Bug.hs}}} {{{#!hs {-# OPTIONS_GHC -fplugin=DummyPlugin #-} module Bug where impossible :: a impossible = undefined }}} First, compile the dummy plugin. From its directory, run {{{cabal install}}} to install the plugin. Then, from the main directory, run {{{ghc Bug.hs}}}. Expected result: the file compiles. Actual result: {{{ Bug.hs:6:14: error: • Unbound implicit parameter ?callStack::GHC.Stack.Types.CallStack arising from a use of implicit parameter ‘?callStack’ • In the expression: undefined In an equation for ‘impossible’: impossible = undefined }}} Further, observe that commenting out the line which invokes the type- checker plugin (the pragma on line 1) causes the file to compile correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11462> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6