November 2018 - ghc-tickets

[GHC] #13262: Allow type synonym family application in instance head if it reduces away
by GHC 25 Nov '18

25 Nov '18

#13262: Allow type synonym family application in instance head if it reduces away -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (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: -------------------------------------+------------------------------------- GHC rejects the following program: {{{ {-# LANGUAGE TypeFamilies, FlexibleInstances #-} module F where type family F a type instance F Int = Int -> Int instance Show (F Int) where show _ = "fun" }}} But this doesn't seem fundamentally problematic to me: at the instance declaration, we know that F Int will reduce, and after that reduction there isn't any problem with the instance. Here's a less restrictive instance head test: first, we reduce type families as much as possible. Then, if there are still leftover non- reducing type families, reject the instance. After having typed this up, I have realized that I don't actually need this feature. But I'm filing it here for posterity. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15810: Kind inference error in classes
by GHC 25 Nov '18

25 Nov '18

#15810: Kind inference error in classes -------------------------------------+------------------------------------- Reporter: goldfire | 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 rejected today, but it shouldn't be: {{{#!hs class C a where meth :: Proxy (a :: k) }}} It's the kind signature that kills it. Expected solution: change `tcImplicitTKBndrs` to `kcImplicitTKBndrs` in `kcHsKindSig`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15810> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14690: Pattern match failure in GHCi with :steplocal
by GHC 25 Nov '18

25 Nov '18

#14690: Pattern match failure in GHCi with :steplocal --------------------------------------+--------------------------------- Reporter: Philonous | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Using steplocal after breaking on an exception leads to GHCI giving a pattern match error Minimal testcase: {{{ Prelude> :set -fbreak-on-exception Prelude> error "abc" Stopped in <exception thrown>, <unknown> _exception :: e = _ [<unknown>] [<unknown>] Prelude> :steplocal *** Exception: Pattern match failure in do expression at ghc/GHCi/UI.hs:3149:12-18 }}} :step works as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14690> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13773: Types are not normalized in instance declarations
by GHC 25 Nov '18

25 Nov '18

#13773: Types are not normalized in instance declarations -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) 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: -------------------------------------+------------------------------------- Consider the example below. It does not compile, but replacing 5*2 by 10 makes it compile. This is quite annoying since it forces me to do the normalization that the computer is really much better at doing. {{{#!hs module NatInstance where import GHC.TypeLits type N = 5 * 2 data D (n :: Nat) = D instance Show (D N) where show _ = "" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13773> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15928: Reduction stack overflow when using "coerce"
by GHC 25 Nov '18

25 Nov '18

#15928: Reduction stack overflow when using "coerce" -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling the following snippet results in a "Reduction stack overflow" error message: {{{#!hs {-# Language ScopedTypeVariables #-} {-# Language RankNTypes #-} import Data.Functor.Identity import Data.Coerce newtype Stream m a = Stream { unStream :: forall r. (Stream m a -> m r) -> m r } newtype SerialT m a = SerialT (Stream m a) g :: SerialT Identity a -> Identity Bool g m = undefined idSerial :: SerialT Identity a -> SerialT Identity a idSerial = id f :: SerialT Identity a -> Identity Bool f = g . idSerial . coerce main = undefined }}} The following error message is produced on compiling this with ghc-8.6.2: {{{ xy.hs:26:20: error: • Reduction stack overflow; size = 201 When simplifying the following type: Coercible ((Stream Identity a -> Identity r) -> Identity r) ((Stream Identity a0 -> Identity r) -> Identity r) Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the second argument of ‘(.)’, namely ‘coerce’ In the second argument of ‘(.)’, namely ‘idSerial . coerce’ In the expression: g . idSerial . coerce | 26 | f = g . idSerial . coerce | ^^^^^^ }}} When I use an inline signature like this: {{{#!hs f :: SerialT Identity a -> Identity Bool f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce main = undefined }}} It again results in the same error: {{{ xy.hs:18:60: error: • Reduction stack overflow; size = 201 When simplifying the following type: Coercible ((Stream Identity a -> Identity r) -> Identity r) ((Stream Identity a0 -> Identity r) -> Identity r) Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the second argument of ‘(.)’, namely ‘coerce’ In the second argument of ‘(.)’, namely ‘(id :: SerialT Identity a -> SerialT Identity a) . coerce’ In the expression: g . (id :: SerialT Identity a -> SerialT Identity a) . coerce | 18 | f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce | ^^^^^^ }}} Everything works fine is I use an inline signature with a `forall` keyword like this: {{{#!hs f :: forall a. SerialT Identity a -> Identity Bool f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce }}} I have following questions: 1) Why the first version results in a panic? Is that a bug? 2) The second version might possibly be incorrect code because the types do not unify, but still it should not result in a panic, because of the panic I could not figure out what the problem is. It took a long time to isolate the code and then do some trial and error on it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15928> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15085: :type-at/:all-types and :r don't mix
by GHC 25 Nov '18

25 Nov '18

#15085: :type-at/:all-types and :r don't mix -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2 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: -------------------------------------+------------------------------------- Steps to reproduce: 1. Put `x = ()` in test.hs. 2. Start ghci. 3. Turn on collection with :set +c. 4. Load the file with :l test.hs. 5. Observe the following output from :all-types {{{ test.hs:(1,1)-(1,2): () test.hs:(1,5)-(1,7): () }}} 6. While ghci is still open, modify the file to say `x = True`. 7. In the same ghci session as before, reload with :r, or load the file again with :l test.hs, chef's choice. 8. Run :all-types again. After step 8, ghci prints the exact same thing as before, indicating that both sides of the equation have type `()`. It should instead update the source spans and types to match the file, reporting `Bool` instead of `()` and `(1,5)-(1,9)` for the second span. Manually exiting and restarting ghci appears to be the only way to freshen the collected type information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15085> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15927: Weird interaction between fundeps and overlappable instances
by GHC 25 Nov '18

25 Nov '18

#15927: Weird interaction between fundeps and overlappable instances -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this code {{{#!hs class MyState s m | m -> s where getMyState :: m s instance {-# OVERLAPPABLE #-} (MyState s m, MonadTrans t, Monad m) => MyState s (t m) where getMyState = lift getMyState instance Monad m => MyState s (StateT s m) where getMyState = get f :: (MyState Int m, MyState Char m, MonadIO m) => m () f = do int <- getMyState str <- getMyState liftIO $ putStrLn (replicate int str) works1 :: (MyState s m, Show s, MonadIO m) => m () works1 = do a <- getMyState liftIO (print a) works2 = runStateT (runStateT f (5 :: Int)) 'a' }}} It defines a class similar to `MonadState` of mtl. There is a functional dependency in place, just like with `MonadState` and we can see that it works the same because `works1` compiles where `a` would have an ambiguous type otherwise. The `f` function "shouldn't" compile because it's using two different states at once subverting the functional dependency restriction. It does however compile because an explicit type signature is provided with an unsolvable constraint. Now the really weird part is that `works2` also compiles and produces the expected result even though it's using `f`. Here's what I think is happening: instance resolution is looking for `MyState Int (StateT Char m)` and it finds the `MyState s (StateT s m)` instance. Instead of complaining that `Int` doesn't match `Char` (due to the fundep), it just rejects the instance and takes the overlappable one that does match. In the case where the state is unknown (i.e. both instances match), the fundep kicks in. That's why `runStateT works1 True` works. Is this intended behavior? It seems pretty useful in some situations and I've tested this with 8.2 and 8.6 with the same results. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15927> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15495: Handling Source Locations via TTG
by GHC 24 Nov '18

24 Nov '18

#15495: Handling Source Locations via TTG -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | 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: -------------------------------------+------------------------------------- == Problem == The current implementation of [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGr… TTG HsSyn AST] in GHC stores source locations for terms of a datatype `Exp` in a separate wrapper datatype `LExp` which is mutually recursive with `Exp` such that every recursive reference to `Exp` is done **indirectly**, via a reference to the wrapper datatype `LExp` (see the example code below). We refer to this style of storing source locations as the ping-pong style. Besides the indirection and the resulting complications of the ping-pong style, there are two key problems with it: a. It bakes-in the source locations in the base TTG AST, forcing all instances to store source locations, even if they don't need them.For example, TH AST does not carry source locations, or even within GHC, there are generated terms without source locations. b. It results in a form of conceptual redundancy: source locations are tree decorations and they belong in the extension points. (see https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGr… TTG Guidance]) == Solution == We can move the source location decorations to a wrapper constructor and remove the ping-pong style. This can be done smoothly, mechanically, and gradually by using a getter/setter methods for source locations. More details can be found at [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSou… the related wiki page]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15495> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15944: Wrong warning given ViewPatterns and -Wmonomorphism-restriction
by GHC 23 Nov '18

23 Nov '18

#15944: Wrong warning given ViewPatterns and -Wmonomorphism-restriction -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I understand ghc complaining about `b`, but not about `a`. No warnings when view patterns are not used. {{{#!hs {-# LANGUAGE ViewPatterns #-} {-# OPTIONS -Wmonomorphism-restriction #-} module Foo where {- demo.hs:11:9: warning: [-Wmonomorphism-restriction] • The Monomorphism Restriction applies to the bindings for ‘a’, ‘b’ Consider giving them a type signature • In the expression: let Foo a (round -> b) = f in a + b In an equation for ‘bar’: bar f = let Foo a (round -> b) = f in a + b | 11 | let Foo a (round -> b) = f | ^^^^^^^^^^^^^^^^^^^^^^ -} data Foo = Foo Int Double bar :: Foo -> Int bar f = let Foo a (round -> b) = f in a + b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15944> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15932: DeriveFunctor and GeneralizedNewtypeDeriving instances never reporting as covered
by GHC 23 Nov '18

23 Nov '18

#15932: DeriveFunctor and GeneralizedNewtypeDeriving instances never reporting as covered -------------------------------------+------------------------------------- Reporter: davean | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.3 Component: Code Coverage | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When testing coverage of test cases, HPC does not report some instances as receiving coverage even though it seems they are. Particularly, when one hand derives the functions they show full coverage. The specific instances in question appear to be ones derived via DeriveFunctor and GeneralizedNewtypeDeriving. Problems have been observed with at least Functor, Applicative, and Monad. A minimal example is attached, and available as a cabal project at https://code.xkrd.net/davean/minimal-coverage-test. To reproduce, run "cabal v2-test --enable-coverage" and view the resulting coverage HTML files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15932> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3