April 2018 - ghc-tickets

[GHC] #10490: Missing binder type check in coercion equality test?
by GHC 25 May '18

25 May '18

#10490: Missing binder type check in coercion equality test? -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I was reading the equality testing code for coercions and I noticed this line: {{{ coreEqCoercion2 env (ForAllCo v1 co1) (ForAllCo v2 co2) = coreEqCoercion2 (rnBndr2 env v1 v2) co1 co2 }}} This doesn't test if the types of the binders are equal. Should it? (Or is the type always trivially the same?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10490> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks.
by GHC 25 May '18

25 May '18

#9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. -------------------------------------+------------------------------------- Reporter: oleg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: type family, | Unknown/Multiple ambiguity check | Type of failure: GHC Architecture: Unknown/Multiple | rejects valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Before the type ambiguity check was introduced, I could write the following code {{{ {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} -- {-# LANGUAGE AllowAmbiguousTypes #-} module T where type family Arr (repr :: * -> *) (a :: *) (b :: *) :: * class ESymantics repr where int :: Int -> repr Int add :: repr Int -> repr Int -> repr Int lam :: (repr a -> repr b) -> repr (Arr repr a b) app :: repr (Arr repr a b) -> repr a -> repr b {- te4 :: (Arr repr (Arr repr Int Int) (Arr repr Int Int) ~ Arr repr (Arr repr Int Int) (Arr repr Int b), ESymantics repr) => repr b -} te4 = let c3 = lam (\f -> lam (\x -> f `app` (f `app` (f `app` x)))) in (c3 `app` (lam (\x -> x `add` int 14))) `app` (int 0) -- t = lam (\f -> f `app` int 0) newtype R a = R{unR :: a} type instance Arr R a b = a -> b instance ESymantics R where int = R add (R x) (R y) = R $ x + y lam f = R $ unR . f . R app (R f) (R x) = R $ f x tR = unR te4 }}} (This is a simple code abstracted from a longer code that for sure worked in 2010: I showed it in a SSGIP lecture at Oxford.) The inferred type of te4 is shown in comments. The type is not ideal but the best what can be done under circumstances. In tR, repr is instantiated to R and the type function Arr can finally be applied and the equality constraint resolved. Since then, the type inference has changed and the code no longer type checks: {{{ Could not deduce (Arr repr (Arr repr a0 b0) (Arr repr a2 b0) ~ Arr repr (Arr repr a b) (Arr repr a4 b)) from the context (ESymantics repr, Arr repr a4 a3 ~ Arr repr a b, Arr repr a3 a ~ Arr repr a b) bound by the inferred type for ‘c3’: (ESymantics repr, Arr repr a4 a3 ~ Arr repr a b, Arr repr a3 a ~ Arr repr a b) => repr (Arr repr (Arr repr a b) (Arr repr a4 b)) }}} What is worse, there does not appear to be *any* way to get the code to type check. No amount of type annotations helps. The code has to be dramatically re-written, or just given up. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9587> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9607: Type checking regression between GHC 7.6 and 7.8
by GHC 25 May '18

25 May '18

#9607: Type checking regression between GHC 7.6 and 7.8 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Jason McCarty [http://www.haskell.org/pipermail/haskell- cafe/2014-September/116076.html reported on Haskell-cafe] that this code used to work with GHC 7.6 but in GHC 7.8 it requires `AllowAmbiguousTypes`: {{{#!hs -- The code below is simplified from code that computes a tensor product of -- a tensor with an identity matrix whose size is determined from the -- shapes of the input and output tensors. {-# LANGUAGE DataKinds, KindSignatures, TypeFamilies, TypeOperators #-} --{-# LANGUAGE AllowAmbiguousTypes #-} module Tensors where import GHC.TypeLits type family (as :: [Nat]) ++ (bs :: [Nat]) :: [Nat] type instance '[] ++ bs = bs type instance (a ': as) ++ bs = a ': (as ++ bs) data Tensor (s :: [Nat]) = Tensor -- content elided -- apparently GHC reduces (++) enough to see that n is determined leftUnit :: Tensor s -> Tensor ('[n, n] ++ s) leftUnit Tensor = Tensor -- accepted in 7.6, not accepted in 7.8 without AllowAmbiguousTypes rightUnit :: Tensor s -> Tensor (s ++ '[n, n]) rightUnit Tensor = Tensor -- also accepted without AllowAmbiguousTypes outsideUnit :: Tensor s -> Tensor ('[n] ++ s ++ '[n]) outsideUnit Tensor = Tensor useleftUnit :: Tensor '[1,1,2] useleftUnit = leftUnit Tensor -- type of Tensor is inferred userightUnit :: Tensor '[1,2,2] userightUnit = rightUnit (Tensor :: Tensor '[1]) -- type must be provided }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9607> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12387: Template Haskell ignores class instance definitions with methods that don't belong to the class
by GHC 24 May '18

24 May '18

#12387: Template Haskell ignores class instance definitions with methods that don't belong to the class -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Main where import Language.Haskell.TH.Lib data Foo = Foo $(do d <- instanceD (cxt []) (conT ''Eq `appT` conT ''Foo) [funD 'compare [clause [] (normalB $ varE 'undefined) []]] return [d]) main :: IO () main = print $ Foo == Foo }}} {{{ $ /opt/ghc/8.0.1/bin/runghc Bug.hs Bug.hs:(9,3)-(11,15): Splicing declarations do { d_a2hL <- instanceD (cxt []) (conT ''Eq `appT` conT ''Foo) [funD 'compare [clause [] (normalB $ varE 'undefined) []]]; return [d_a2hL] } ======> instance Eq Foo where compare = undefined Bug.hs:9:3: warning: [-Wmissing-methods] • No explicit implementation for either ‘==’ or ‘/=’ • In the instance declaration for ‘Eq Foo’ Bug.hs: stack overflow }}} `compare` obviously doesn't belong to `Eq`, yet GHC happily accepts an `Eq Foo` instance with a definition for `compare`! Worse yet, there's now neither a definition for `(==)` nor `(/=)`, so the default definition of `(==)` triggers an infinite loop, blowing the stack at runtime. I don't know how pervasive this bug is. That is, I'm not sure if you could also attach associated type family instances, pattern synonyms, etc. that don't belong to the class either. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12387> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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] #11968: Document AMP in the deviations from the standard
by GHC 24 May '18

24 May '18

#11968: Document AMP in the deviations from the standard -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- The manual includes a section describing deviations from the Haskell2010 standard [https://downloads.haskell.org/~ghc/master/users-guide/bugs.html here]. But this page makes no mention of `Applicative` being a superclass of `Monad`. We should fix this omission. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11968> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[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] #13275: ghci ignores -fprint-explicit-runtime-reps
by GHC 23 May '18

23 May '18

#13275: ghci ignores -fprint-explicit-runtime-reps -------------------------------------+------------------------------------- Reporter: Konrad Gądek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: levity | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The docs [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using.html #ghc-flag--fprint-explicit-runtime-reps here] mentions the following use- case: {{{ ghci> :t ($) ($) :: (a -> b) -> a -> b ghci> :set -fprint-explicit-runtime-reps ghci> :t ($) ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b }}} However, I get this: {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :t ($) ($) :: (a -> b) -> a -> b Prelude> :i ($) ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b -- Defined in ‘GHC.Base’ infixr 0 $ Prelude> :set -fprint-explicit-runtime-reps Prelude> :t ($) ($) :: (a -> b) -> a -> b Prelude> :i ($) ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b -- Defined in ‘GHC.Base’ infixr 0 $ }}} I'm not sure if the docs are wrong or GHCi is erroneously ignoring the flag when using `:t`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13275> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[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] #12201: Wrong instance selection with overlapping instances and local bindings
by GHC 23 May '18

23 May '18

#12201: Wrong instance selection with overlapping instances and local bindings -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- test and test2 should have the same type, but it seems like the {-# OVERLAPPING #-} instance is chosen prematurely. {{{#!hs {-# LANGUAGE NoMonomorphismRestriction, FlexibleContexts, FlexibleInstances #-} module Bug where class A a where class A a => B a where data Foo s a instance {-# OVERLAPPING #-} A (Foo Int Bool) instance A (Foo s a) instance B (Foo s a) bar :: (A a, B a) => a bar = undefined helper :: Foo s Bool -> s -> Int helper = undefined {- *Bug> :t test test :: A (Foo s Bool) => s -> Int -} test = helper bar {- *Bug> :t test2 test2 :: s -> Int -} test2 = let foo = bar in helper foo }}} Compare with 7.10.3: {{{ *Bug> :t test test :: A (Foo s Bool) => s -> Int *Bug> :t test2 test2 :: A (Foo s Bool) => s -> Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12201> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8