August 2017 - ghc-tickets

[GHC] #13759: Strange error message for deriving Data
by GHC 01 Aug '17

01 Aug '17

#13759: Strange error message for deriving Data -------------------------------------+------------------------------------- Reporter: alanz | 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: -------------------------------------+------------------------------------- The following code {{{#!hs {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE FlexibleInstances #-} import Data.Data data Pass = Parsed | Renamed | Typechecked deriving (Data) data GHC (c :: Pass) deriving instance Data (GHC 'Parsed) deriving instance Data (GHC 'Renamed) deriving instance Data (GHC 'Typechecked) -- Type synonyms as a shorthand for tagging type GhcPs = GHC 'Parsed type GhcRn = GHC 'Renamed type GhcTc = GHC 'Typechecked }}} loads fine in `ghci-8.2.0.20170507`. In `ghc-8.0.2` and current master (as at https://github.com/ghc/ghc/tree/wip/new-tree-one-param-2) it gives {{{#!hs alanz@alanz-laptop:~/tmp/ghc-bug-data-deriving$ ghci-8.0.2 Main.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/alanz/.ghci [1 of 1] Compiling Main ( Main.hs, interpreted ) Main.hs:16:1: error: Multiple declarations of ‘$tFl4AgeEJ0Vk5ONrnm56S3r’ Declared at: Main.hs:16:1 Main.hs:17:1 Main.hs:16:1: error: Multiple declarations of ‘$tFl4AgeEJ0Vk5ONrnm56S3r’ Declared at: Main.hs:15:1 Main.hs:17:1 Main.hs:16:1: error: Duplicate type signatures for ‘$tFl4AgeEJ0Vk5ONrnm56S3r’ at Main.hs:15:1-36 Main.hs:16:1-37 Main.hs:17:1-41 Failed, modules loaded: none. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13759> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13465: Foldable deriving treatment of tuples is too surprising
by GHC 01 Aug '17

01 Aug '17

#13465: Foldable deriving treatment of tuples is too surprising -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ *> :set -XDeriveFoldable *> data Foo a = Foo ((a,a),a) deriving Foldable *> length ((1,1),1) 1 *> length $ Foo ((1,1),1) 3 }}} I think the right thing is probably to refuse to derive `Foldable` if components of a tuple other than the last one may contain the type variable we're looking for. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13465> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12639: Inconsistent treatment of FlexibleInstances and MPTCs with standard vs. flexible deriving
by GHC 01 Aug '17

01 Aug '17

#12639: Inconsistent treatment of FlexibleInstances and MPTCs with standard vs. flexible deriving -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Given `{-# LANGUAGE GeneralizedNewtypeDeriving #-}`, I can write {{{#!hs import Control.Monad.State.Strict newtype Foo s m a = Foo (StateT s m a) deriving (Functor, Applicative, Monad, MonadState s) }}} However, if I want to use `StandaloneDeriving` to make the `MonadState` instance more explicit, {{{#!hs deriving instance Monad m => MonadState s (Foo s m) }}} I suddenly need to add `FlexibleInstances` and `MultiParamTypeClasses`. In my personal opinion, the most sensible way to handle this is to change two things in two different directions: 1. Allow MPTC instance declarations (but not class declarations) without `MultiParamTypeClasses`. 2. Require `FlexibleInstances` for standard deriving clauses when they would be required for standalone deriving declarations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12639> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9790: Produce coercion rules for derived Functor instances
by GHC 01 Aug '17

01 Aug '17

#9790: Produce coercion rules for derived Functor instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: coercion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I don't ''think'' we do this yet, but I think we probably can. If we derive a `Functor` instance, we should, whenever possible and valid, produce some sort of `fmap coerce = coerce` rule for that type. This is done manually for lists in `GHC.Base`, but I imagine it probably applies (much) more generally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9790> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10598: DeriveAnyClass and GND don't work well together
by GHC 01 Aug '17

01 Aug '17

#10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I think we definitely have a bug here, but I'm not sure what it really is. Here's the program: {{{ newtype MyMaybe a = MyMaybe (Maybe a) deriving (Functor, Show) main = print $ MyMaybe $ Just (10 :: Int) }}} I'm using GHC 7.10.1. {{{ ➜ deriveany_bug ghc --make -fforce-recomp Test.hs -XDeriveAnyClass -XGeneralizedNewtypeDeriving [1 of 1] Compiling Main ( Test.hs, Test.o ) Test.hs:2:13: Can't make a derived instance of ‘Functor MyMaybe’ (even with cunning newtype deriving): You need DeriveFunctor to derive an instance for this class Try GeneralizedNewtypeDeriving for GHC's newtype-deriving extension In the newtype declaration for ‘MyMaybe’ }}} Just to try, changing argument order: {{{ ➜ deriveany_bug ghc --make -fforce-recomp Test.hs -XGeneralizedNewtypeDeriving -XDeriveAnyClass [1 of 1] Compiling Main ( Test.hs, Test.o ) Test.hs:2:13: Can't make a derived instance of ‘Functor MyMaybe’ (even with cunning newtype deriving): You need DeriveFunctor to derive an instance for this class Try GeneralizedNewtypeDeriving for GHC's newtype-deriving extension In the newtype declaration for ‘MyMaybe’ }}} It works fine if I remove `DeriveAnyClass`: {{{ ➜ deriveany_bug ghc --make -fforce-recomp Test.hs -XGeneralizedNewtypeDeriving [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... }}} GHC HEAD is failing in exactly the same way. User manual is saying this in 7.5.6: > In case you try to derive some class on a newtype, and -XGeneralizedNewtypeDeriving is also on, -XDeriveAnyClass takes precedence. But then why is it telling me to enable `GeneralizedNewtypeDeriving` in the error message? Even if I already enabled it? Also, maybe it could try `GND` when `DeriveAnyClass` fails? Because the doc is saying `DeriveAnyClass` has precedence but doesn't specify what happens if it fails. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10598> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 55

Re: [GHC] #1830: Automatic derivation of Lift
by GHC 01 Aug '17

01 Aug '17

#1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: RyanGlScott Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.1 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1168 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1830#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10938: DeriveAnyClass + deriving Bifunctor causes GHC panic
by GHC 01 Aug '17

01 Aug '17

#10938: DeriveAnyClass + deriving Bifunctor causes GHC panic -------------------------------------+------------------------------------- Reporter: erantapaa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: MacOS X DeriveAnyClass | Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Attempting the derive Bifunctor with DeriveAnyClass caused this message from GHC: {{{ $ ghc Foo.hs [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Var/Type length mismatch: [a_an7, b_an8] [] Var/Type length mismatch: [a_an7, b_an8] [] Var/Type length mismatch: [a_an7, b_an8] [] Foo.hs:8:13:ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): tcTyVarDetails a_an7 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The code: {{{#!hs {-# LANGUAGE DeriveAnyClass #-} module Foo where import Data.Bifunctor data Blah a b = A a | B b deriving (Bifunctor) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10938> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11509: Incorrect error message in StandaloneDeriving: "The data constructors of <typeclass> are not all in scope"
by GHC 01 Aug '17

01 Aug '17

#11509: Incorrect error message in StandaloneDeriving: "The data constructors of <typeclass> are not all in scope" -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 {{{#!hs {-# OPTIONS_GHC -Wall #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE StaticPointers #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE UndecidableSuperClasses #-} module Bug where import Data.Kind import Data.Typeable import GHC.StaticPtr {------------------------------------------------------------------------------- Standard Cloud-Haskell-like infrastructure See <https://ghc.haskell.org/trac/ghc/wiki/TypeableT> for a dicussion of 'SC'. -------------------------------------------------------------------------------} class Serializable a -- empty class, just for demonstration purposes instance Serializable a => Serializable [a] data Static :: * -> * where StaticPtr :: StaticPtr a -> Static a StaticApp :: Static (a -> b) -> Static a -> Static b staticApp :: StaticPtr (a -> b) -> Static a -> Static b staticApp = StaticApp . StaticPtr data Dict :: Constraint -> * where Dict :: c => Dict c class c => SC c where dict :: Static (Dict c) instance (Typeable a, SC (Serializable a)) => SC (Serializable [a]) where dict = aux `staticApp` dict where aux :: StaticPtr (Dict (Serializable a) -> Dict (Serializable [a])) aux = static (\Dict -> Dict) {------------------------------------------------------------------------------- Demonstrate the bug -------------------------------------------------------------------------------} newtype MyList a = MyList [a] deriving instance (Typeable a, SC (Serializable a)) => SC (Serializable (MyList a)) }}} This gives the following type error: {{{ Bug1.hs:40:1: error: • Can't make a derived instance of ‘SC (Serializable (MyList a))’: The data constructors of ‘Serializable’ are not all in scope so you cannot derive an instance for it • In the stand-alone deriving instance for ‘SC (Serializable a) => SC (Serializable (MyList a))’ }}} This of course doesn't make much sense: `Serializable` is a type class, not a datatype, and doesn't have data constructors. I wasn't sure if this deriving clause was going to work at all, or whether I would expect it to. Since `MyList` is a newtype wrapper around `[a]`, and we have the requisite instance {{{#!hs instance (Typeable a, SC (Serializable a)) => SC (Serializable [a]) }}} I was kind of hoping that `GeneralizedNewtypeDeriving` would work its magic. However, even if it cannot, the error message should probably change. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11509> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #13272: DeriveAnyClass regression involving a rigid type variable
by GHC 01 Aug '17

01 Aug '17

#13272: DeriveAnyClass regression involving a rigid type variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: Generics | 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: -------------------------------------+------------------------------------- I was writing up an example to show off how `DeriveAnyClass` has improved since 639e702b6129f501c539b158b982ed8489e3d09c, and wouldn't you know it, the example doesn't actually compile anymore post- 639e702b6129f501c539b158b982ed8489e3d09c. Oopsie. {{{#!hs module TypeName where import GHC.Generics class TypeName a where typeName :: forall proxy. proxy a -> String default typeName :: forall proxy d f. (Generic a, Rep a ~ D1 d f, Datatype d) => proxy a -> String typeName _ = gtypeName $ from (undefined :: a) gtypeName :: Datatype d => D1 d f p -> String gtypeName = datatypeName data T a = MkT a deriving (Generic, TypeName) }}} This compiles before that commit. After it, however, it fails with the error: {{{ [1 of 1] Compiling TypeName ( Bug.hs, interpreted ) Bug.hs:23:22: error: • Couldn't match type ‘f’ with ‘C1 ('MetaCons "MkT" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 a))’ arising from the 'deriving' clause of a data type declaration ‘f’ is a rigid type variable bound by the deriving clause for ‘TypeName (T a)’ at Bug.hs:14:38 • When deriving the instance for (TypeName (T a)) | 23 | deriving (Generic, TypeName) | ^^^^^^^^ }}} I'm not sure why it's complaining only about `f` and not, say, `d`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13272> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12814: Should GND infer an instance context when deriving method-free classes?
by GHC 01 Aug '17

01 Aug '17

#12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: #11369, #12810 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a design question that emerged from code that I originally discovered [https://ghc.haskell.org/trac/ghc/ticket/11369#comment:17 here] and [https://ghc.haskell.org/trac/ghc/ticket/12810#comment:3 here]. To recap, it's now possible to have code like this: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies #-} class C a where type T a newtype Identity a = Identity a deriving C }}} Compiling this (with `-Wredundant-constraints`) generates this code: {{{#!hs instance C a => C (Identity a) where type T (Identity a) = T a }}} But now GHC will complain: {{{ • Redundant constraint: C a • In the instance declaration for ‘C (Identity a)’ }}} This warning makes sense from the perspective that the `C a` constraint isn't ever used by the associated type family instance. So the question arises: should GND avoid generating an instance context for the representation type in the event it's deriving a class with no methods? Fortunately, patching GHC to do this is trivial: {{{#!diff diff --git a/compiler/typecheck/TcDeriv.hs b/compiler/typecheck/TcDeriv.hs index 4722f16..df2d3d5 100644 --- a/compiler/typecheck/TcDeriv.hs +++ b/compiler/typecheck/TcDeriv.hs @@ -1272,7 +1272,8 @@ mkNewTypeEqn dflags overlap_mode tvs [ let (Pair t1 t2) = mkCoerceClassMethEqn cls dfun_tvs inst_tys rep_inst_ty m in mkPredOrigin (DerivOriginCoerce meth t1 t2) TypeLevel (mkReprPrimEqPred t1 t2) - | meth <- classMethods cls ] + | meth <- meths ] + meths = classMethods cls -- If there are no tyvars, there's no need -- to abstract over the dictionaries we need @@ -1281,7 +1282,11 @@ mkNewTypeEqn dflags overlap_mode tvs -- instance C T -- rather than -- instance C Int => C T - all_preds = rep_pred_o : coercible_constraints ++ sc_theta -- NB: rep_pred comes + all_preds = if null meths then [] else [rep_pred_o] + -- See Note [GND and method-free classes] + ++ coercible_constraints + ++ sc_theta + -- NB: rep_pred_o comes first ------------------------------------------------------------------- -- Figuring out whether we can only do this newtype-deriving thing }}} After implementing this patch, I ran the testsuite, and there were some surprising results. One thing that shocked me was that the program reported in #6088, which had previously failed due to a patch resulting from #8984, was now passing! {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE EmptyDataDecls #-} module T6088 where class C a newtype A n = A Int type family Pos n data True instance (Pos n ~ True) => C (A n) newtype B n = B (A n) deriving (C) }}} That is because previously, GHC was trying to generate an instance like this: {{{#!hs instance (Pos n ~ True) => C (B n) }}} And this was rejected, since we don't infer exotic equality constraints when deriving. But with this patch, it now generates: {{{#!hs instance {- Empty context => -} C (B n) }}} Which is certainly valid. But is it what a user would expect? I'm not so sure. As hvr notes in #11369, sometimes empty classes are used to enforce invariants, like in the following case: {{{#!hs class Throws e readFoo :: Throws IOError => FilePath -> IO Foo readFoo fn = {- ... -} }}} What if you wanted to have a `Throws` instance for a newtype? You'd probably want something like this: {{{#!hs newtype Id a = MkId a instance Throws a => Throws (Id a) }}} Which feels like something GND should be able to take care of with ease. But to your surprise, you try this: {{{#!hs newtype Id a = MkId a deriving Throws }}} And now GHC generates not the instance above, but rather just: {{{#!hs instance Throws (Identity a) }}} So it's possible that we would lose some of the expressiveness of GND by implementing this change. Is that acceptable? I'm not sure, so I though I'd solicit feedback here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12814> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17