March 2016 - ghc-tickets

[GHC] #9980: TcS monad is too heavy
by GHC 24 May '18

24 May '18

#9980: TcS monad is too heavy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The typehcecker's constraint-solving monad, `TcS`, is simply built on top of `TcM`, but it doesn't use most of `TcM`'s facilities. That was fine while `TcS` was only called from the typechecker, but now (as part of [wiki:PatternMatchCheck fixing pattern-match overlap checking]) we invoke it from the desugarer. It seems quite wrong to construct a vast, and unnecessary `TcM` context just to invoke `TcS`. Better: make `TcS` into its own monad, with its own `TcSLclEnv`, built on `IOEnv` like the others. Main objection: the plugins mechanism exposes `unsafeTcPluginTcM`, which would become unavailable. But it it used? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable)
by GHC 24 May '18

24 May '18

#11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Linux ImpredicativeTypes | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I don't have the latest version of GHC, trying to derive `Functor A` and `Foldable A` is fine but when I derive `Traversable A` in the attachment Error.hs: {{{#!hs {-# LANGUAGE DeriveFunctor, DeriveFoldable, DeriveTraversable, ImpredicativeTypes #-} import Data.Functor (Functor) import Data.Foldable (Foldable) import Data.Traversable (Traversable) data A a = A deriving (Functor, Foldable, Traversable) }}} GHC barks at me (verbose log attached): {{{#!hs /tmp/Error.hs:8:32: error: • Couldn't match type ‘forall a1. A a1’ with ‘A b’ Expected type: f (A b) Actual type: f (forall a. A a) • In the expression: pure A In an equation for ‘traverse’: traverse f A = pure A When typechecking the code for ‘traverse’ in a derived instance for ‘Traversable A’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Traversable A’ • Relevant bindings include f :: a -> f b (bound at /tmp/Error.hs:8:32) traverse :: (a -> f b) -> A a -> f (A b) (bound at /tmp/Error.hs:8:32) }}} With `-ddump-deriv` we get this (unqualified) instance: {{{#!hs instance Traversable A where traverse f_a2Le A = pure A }}} which by itself causes the same problem in the attachment Error2.hs: {{{#!hs {-# LANGUAGE DeriveFunctor, DeriveFoldable, ImpredicativeTypes #-} import Data.Functor (Functor) import Data.Foldable (Foldable) import Data.Traversable (Traversable) data A a = A deriving (Functor, Foldable) instance Traversable A where traverse f A = pure A }}} Works fine in GHC-7.10.2 and GHC-7.10.0.20150316 and GHC-7.4 (with some additional imports), is this an `ImpredicativeTypes` regression? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11319> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #10089: feature: warn about unused data definitions (with typeclass instances)
by GHC 23 May '18

23 May '18

#10089: feature: warn about unused data definitions (with typeclass instances) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Let's consider an example: {{{#!hs -- M.hs: module M () where -- ghc knows about uselessness of those data D = D -- but doesn't about this: data E = E deriving (Show, Read) }}} '''ghc''' warns about useless '''D''', but not '''E''': {{{ $ ghc-7.8.4 -Wall -c M.hs -fforce-recomp M.hs:5:1: Warning: Defined but not used: type constructor or class ‘D’ M.hs:5:10: Warning: Defined but not used: data constructor ‘D’ }}} There is no way to refer to '''E''' type outside or call it's unstances, correct? I would expect no code should be generated for this module. '''ghc''' could also warn about defined, but not used instances for types, that are not exported. Some background on where those stray types come from: 1. programmer usually adds a set of data types into their program (say, 10-15 types to represent an AST) 2. then annotates them with 'deriving (Read, Show)' convenience instances 3. (months later) amends AST representation a bit and leaves leftover data types not used anywhere Does that make sense? Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10089> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family
by GHC 23 May '18

23 May '18

#9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- We hoped that closed type families could replace overlapping instances. It is not currently the case: GHC can resolve overlapping instances but cannot resolve the similar closed type family. I'm attaching a minimized example of program where it can be observed. This is reproducible on ghc-7.8.3 and HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9918> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely
by GHC 21 May '18

21 May '18

#10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely -------------------------------------+------------------------------------- Reporter: asukamirai | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: x86_64 | at runtime (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- BlockedIndefinatelyOnMVar exception is thrown to the main thread in below source code although the thread is not blocked indefinitely. {{{#!hs module Main where import qualified Control.Concurrent.MVar as MV import qualified Control.Concurrent as CC import qualified Control.Exception as E main :: IO () main = do -- call this thread "threadA" mvar1 <- MV.newEmptyMVar :: IO (MV.MVar ()) mvar2 <- MV.newEmptyMVar :: IO (MV.MVar ()) _ <- CC.forkIO $ do -- call this thread "threadB" MV.takeMVar mvar1 `E.catch` errorHandler1 putStrLn "after error catch" CC.threadDelay 1000000 MV.putMVar mvar2 () putStrLn "after putMVar" MV.readMVar mvar2 `E.catch` errorHandler2 putStrLn "after readMVar" CC.threadDelay 5000000 where errorHandler1 :: E.BlockedIndefinitelyOnMVar -> IO () errorHandler1 e = putStrLn $ "errorHandler1 : " ++ show e errorHandler2 :: E.BlockedIndefinitelyOnMVar -> IO () errorHandler2 e = putStrLn $ "errorHandler2 : " ++ show e }}} Save above as "mvar.hs" and run by ghc as below. {{{ > runhaskell mvar.hs errorHandler1 : thread blocked indefinitely in an MVar operation errorHandler2 : thread blocked indefinitely in an MVar operation after error catch after readMVar after putMVar }}} BlockedIndefinitelyOnMVar thrown for mvar1 is correct. It will be caught by errorHandler1 and "threadB" can continue to put the value to mvar2. It means that "threadA" can wait for the value of mvar2 and it is not blocked indefinately. However, BlockedIndefinitelyOnMVar is thrown for mvar2 on "threadA" before "threadB" puts value to the mvar2. I think it is incorrect. ---- I tested another case that adding "CC.threadDelay 10000000" before "readMVar" as below. {{{#!hs module Main where import qualified Control.Concurrent.MVar as MV import qualified Control.Concurrent as CC import qualified Control.Exception as E main :: IO () main = do -- call this thread "threadA" mvar1 <- MV.newEmptyMVar :: IO (MV.MVar ()) mvar2 <- MV.newEmptyMVar :: IO (MV.MVar ()) _ <- CC.forkIO $ do -- call this thread "threadB" MV.takeMVar mvar1 `E.catch` errorHandler1 putStrLn "after error catch" CC.threadDelay 1000000 MV.putMVar mvar2 () putStrLn "after putMVar" CC.threadDelay 10000000 -- <-- this line is added MV.readMVar mvar2 `E.catch` errorHandler2 putStrLn "after readMVar" CC.threadDelay 5000000 where errorHandler1 :: E.BlockedIndefinitelyOnMVar -> IO () errorHandler1 e = putStrLn $ "errorHandler1 : " ++ show e errorHandler2 :: E.BlockedIndefinitelyOnMVar -> IO () errorHandler2 e = putStrLn $ "errorHandler2 : " ++ show e }}} And it will run correctly (BlockedIndefinitelyOnMVar is not thrown for mvar2). {{{ > runhaskell mvar.hs errorHandler1 : thread blocked indefinitely in an MVar operation after error catch after putMVar after readMVar }}} ---- I found this behavior is same on STM / BlockedIndefinitelyOnSTM. {{{#!hs module Main where import qualified Control.Concurrent.STM as STM import qualified Control.Concurrent as CC import qualified Control.Exception as E main :: IO () main = do tmv1 <- STM.newEmptyTMVarIO :: IO (STM.TMVar ()) tmv2 <- STM.newEmptyTMVarIO :: IO (STM.TMVar ()) _ <- CC.forkIO $ do STM.atomically (STM.takeTMVar tmv1) `E.catch` errorHandler1 putStrLn "after error catch" CC.threadDelay 1000000 STM.atomically $ STM.putTMVar tmv2 () putStrLn "after putTMVar" STM.atomically (STM.readTMVar tmv2) `E.catch` errorHandler2 putStrLn "after readTMVar" CC.threadDelay 5000000 where errorHandler1 :: E.BlockedIndefinitelyOnSTM -> IO () errorHandler1 e = putStrLn $ "errorHandler1 : " ++ show e errorHandler2 :: E.BlockedIndefinitelyOnSTM -> IO () errorHandler2 e = putStrLn $ "errorHandler2 : " ++ show e }}} {{{ > runhaskell stm.hs errorHandler1 : thread blocked indefinitely in an STM transaction errorHandler2 : thread blocked indefinitely in an STM transaction after error catch after readTMVar after putTMVar }}} ---- I tested this in below versions/OSs and got same result (exception thrown for mvar2/tmv2). ghc7.8.3 on Windows7 ghc7.8.3 on lubuntu14.04 on VirtualBox on Windows7 ghc7.8.4 on lubuntu14.04 on VirtualBox on Windows7 ghc7.10.1 on lubuntu14.04 on VirtualBox on Windows7 Similar report https://ghc.haskell.org/trac/ghc/ticket/8804 found but not the same. (In this case, the reference to the MVar is not weak) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10241> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9640: Invalid object in processHeapClosureForDead(): 2130762223
by GHC 19 May '18

19 May '18

#9640: Invalid object in processHeapClosureForDead(): 2130762223 -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I just tried using {{{-hb}}} profiling for Yi and hit {{{ yi: internal error: Invalid object in processHeapClosureForDead(): 2130762223 (GHC version 7.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} Unfortunately I don't have an easy way to replicate. In my case it's to check out HEAD version of Yi, build with profiling and run {{{ [nix-shell:~/programming/yi/yi]$ TERM=xterm yi_datadir=. dist/build/yi/yi -fpango --as=emacs -y /tmp /tmp/long +RTS -p -hb }}} where {{{/tmp/long}}} here is just a file with 1MB of the letter {{{A}}} repeated on a single line. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9640> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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] #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] #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] #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