June 2014 - ghc-tickets

[GHC] #9109: Improve error messages around "untouchable" type variables
by GHC 20 Nov '14

20 Nov '14

#9109: Improve error messages around "untouchable" type variables ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE GADTs #-} data G a where GBool :: G Bool foo GBool = True }}} I get {{{ Couldn't match expected type ‘t’ with actual type ‘Bool’ ‘t’ is untouchable inside the constraints (t1 ~ Bool) bound by a pattern with constructor GBool :: G Bool, in an equation for ‘foo’ at /Users/rae/temp/Bug.hs:6:5-9 ‘t’ is a rigid type variable bound by the inferred type of foo :: G t1 -> t at /Users/rae/temp/Bug.hs:6:1 Relevant bindings include foo :: G t1 -> t (bound at /Users/rae/temp/Bug.hs:6:1) In the expression: True In an equation for ‘foo’: foo GBool = True }}} My code is indeed bogus and the error message is accurate. But, it's really unhelpful in that the solution to my problem is "add a type signature". In general, I occasionally see folks complain about "untouchable" error messages. Most recently, see [http://www.haskell.org/pipermail/glasgow-haskell- users/2014-May/024993.html this thread], which inspired this report. Is the solution ''always'' to just add a type signature/annotation? Would it make sense to include a link to a stable wiki page about just what "untouchable" variables are? I don't necessarily have a solution to this problem, but I think it's worth thinking about. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9109> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9201: GHC unexpectedly refines explicit kind signatures
by GHC 20 Nov '14

20 Nov '14

#9201: GHC unexpectedly refines explicit kind signatures -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts Architecture: Unknown/Multiple | invalid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The following program should be rejected by the type checker: {{{ {-# LANGUAGE PolyKinds, FunctionalDependencies, MultiParamTypeClasses #-} class MonoidalCCC (f :: x -> y) (d :: y -> y -> *) | f -> d where ret :: d a (f a) }}} Instead it is accepted, but the kind variables specified above are 'corrected' during typechecking to: {{{ >>> :browse class MonoidalCCC (f :: x -> x) (d :: x -> x -> *) | f -> d where ret :: d a (f a) }}} This may be similar in root cause to issue #9200, but there a valid program is rejected, and here an invalid program is accepted, so the fixes may be quite different. It seems these kind variables are just being allowed to unify rather than being checked for subsumption. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9201> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9151: Recursive default associated types don't kind-generalize properly
by GHC 20 Nov '14

20 Nov '14

#9151: Recursive default associated types don't kind-generalize properly ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE PolyKinds, DataKinds, TypeFamilies, UndecidableInstances #-} module Bug where import Data.Proxy class PEnum (kproxy :: KProxy a) where type ToEnum (x :: a) :: Bool type ToEnum x = TEHelper type TEHelper = ToEnum Int }}} I get {{{ /Users/rae/temp/Bug.hs:11:24: The first argument of ‘ToEnum’ should have kind ‘a’, but ‘Int’ has kind ‘*’ In the type ‘ToEnum Int’ In the type declaration for ‘TEHelper’ }}} I believe my original code should kind-check, as `ToEnum` should be applicable to any kind. My guess is that this sort of recursion isn't properly accounted for in the kind-checking algorithm in !TcTyClsDecls, and that we kind-check `TEHelper` before `ToEnum` is kind-generalized. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9151> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9220: type roles for unboxed arrays
by GHC 20 Nov '14

20 Nov '14

#9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{ rwbarton@morphism:~$ ghci GHCi, version 7.8.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :i Data.Array.Unboxed.UArray type role Data.Array.Base.UArray representational phantom data Data.Array.Base.UArray i e = Data.Array.Base.UArray !i !i {-# UNPACK #-} !Int GHC.Prim.ByteArray# -- Defined in ‘Data.Array.Base’ -- [instances trimmed] Prelude> :i Data.Array.IO.IOUArray type role Data.Array.IO.Internals.IOUArray representational phantom newtype Data.Array.IO.Internals.IOUArray i e = Data.Array.IO.Internals.IOUArray (Data.Array.Base.STUArray GHC.Prim.RealWorld i e) -- Defined in ‘Data.Array.IO.Internals’ Prelude> :i Data.Array.ST.STUArray type role Data.Array.Base.STUArray nominal representational phantom data Data.Array.Base.STUArray s i e = Data.Array.Base.STUArray !i !i {-# UNPACK #-} !Int (GHC.Prim.MutableByteArray# s) -- Defined in ‘Data.Array.Base’ Prelude> :i Data.Array.Storable.StorableArray type role Data.Array.Storable.Internals.StorableArray representational phantom data Data.Array.Storable.Internals.StorableArray i e = Data.Array.Storable.Internals.StorableArray !i !i Int !(GHC.ForeignPtr.ForeignPtr e) -- Defined in ‘Data.Array.Storable.Internals’ }}} These phantom roles for the element types let me create an unboxed array of one type (like Word8), cast it with `coerce` to another type (like Word64) and read outside the bounds of the array. I think they should all be nominal, since a newtype of an existing type could have a totally unrelated MArray or Storable instance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9220> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #9209: Template haskell panic
by GHC 20 Nov '14

20 Nov '14

#9209: Template haskell panic ------------------------------------+------------------------------------- Reporter: tulcod | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I was trying to get some template haskell thing to work and was messing around and ran into this bug. Prelude> let $([d||]) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): cvBindsAndSigs $[splice{v}]([d| |]) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude> The following file: {-# LANGUAGE TemplateHaskell #-} let $([d||]) main = do return () gives the following error message: test.hs:3:1: parse error (possibly incorrect indentation or mismatched brackets) but doesn't crash. So it seems to be ghci-specific...? the other oxford brackets work fine (or don't suffer from exactly the same bug, anyway) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9209> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9064: Support default class method signatures in Template Haskell
by GHC 20 Nov '14

20 Nov '14

#9064: Support default class method signatures in Template Haskell ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If I say {{{ blah = [d| class C a where foo :: a -> String default foo :: Show a => a -> String foo = show |] }}} I get {{{ Illegal default signature for ‘[foo]’ Default signatures are not supported by Template Haskell }}} I would like this feature. I will implement this in due course. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9200: Milner-Mycroft failure at the kind level
by GHC 20 Nov '14

20 Nov '14

#9200: Milner-Mycroft failure at the kind level -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- This is a reduction of a problem that occurs in real code. {{{ {-# LANGUAGE PolyKinds #-} class D a => C (f :: k) a class C () a => D a }}} Typechecking complains: {{{ The first argument of ‘C’ should have kind ‘k’, but ‘()’ has kind ‘*’ In the class declaration for ‘D’ }}} This program should be accepted, but we're not generalizing enough. A slightly less reduced version of the problem arises in practice in: {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE PolyKinds #-} import Control.Category class (Category c, Category d, Category e) => Profunctor (p :: x -> y -> z) (c :: x -> x -> *) (d :: y -> y -> *) (e :: z -> z -> *) | p -> c d e -- lens-style isomorphism families in an arbitrary category type Iso (c :: i -> i -> *) (s :: i) (a :: i) = forall (p :: i -> i -> *). Profunctor p c c (->) => p a a -> p s s class Category e => Cartesian (e :: z -> z -> *) where type P e :: z -> z -> z associate :: Iso e (P e (P e a b) c) (P e a (P e b c)) }}} This typechecks, but if I replace the line {{{ class (Category c, Category d, Category e) => Profunctor }}} with {{{ class (Category c, Category d, Cartesian e) => Profunctor }}} to say that you can only enrich a category over a monoidal category (using `Cartesian` in the approximation here), then it fails because a more baroque version of the same kind of cycle as the minimal example above as Profunctor references Cartesian which references an Iso which mentions a Profunctor. I'm supplying explicit kind variables in the signature of the class, so we should be able to use those like we do with function signatures a universe down. =/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9200> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 46

[GHC] #8174: GHC should not load packages for TH if they are not used
by GHC 20 Nov '14

20 Nov '14

#8174: GHC should not load packages for TH if they are not used -------------------------+------------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: | Milestone: 7.8.1 normal | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- https://github.com/nh2/ghc-bug-th-loading When you call {{{ ghc --make -package mypackage }}} on a module that uses TH, you will see {{{ Loading package mypackage-1.2.3.4 ... linking ... done. }}} even if no code uses it. This slows down builds, especially cabal ones. GHCI does this better and only loads what is needed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8174> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8310: Can we change the semantics of `Trustworthy`?
by GHC 19 Nov '14

19 Nov '14

#8310: Can we change the semantics of `Trustworthy`? ------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I would like to propose that if I put `{-# LANGUAGE Trustworthy #-}` on a module and it infers as Safe, then the module should get marked `Safe` instead of `Trustworthy`. Putting `Trustworthy` in right now has the semantics "it is at most `Trustworthy`". It would be far more useful to have the semantics "it is at least `Trustworthy`". The current situation is actually a maintenance nightmare. Currently, if I incur a dependency on a package has some `Safe` versions and some non-Safe versions, but I know I'm not using any unsafe componentry of it, I have to either a.) Mark my package Trustworthy unnecessarily enlarging the trusted code base a lot. b.) Track ALL of the dependencies of my dependencies to know when it will be Safe rather than Trustworthy, then insert brittle CPP pragmas that often fail. Consider that `hashable` 1.2.1.0 recently became flagged `Trustworthy`, but was previously not. Now, if I want to properly infer as `Safe`, I have to track the exact version of `hashable` I depend on _and_ whether or not my `Typeable` instance is being rolled manually and make an enormous composite `#ifdef` at the top of the module. Worse, we got the patch in about a month ago, so to future proof my code I'd have had to be psychic. Now consider that I have 50 other packages to maintain in this same manner. I wind up shotgunning `Trustworthy`, do deal with the fact that I deigned to provide instances for `vector`. If `vector` ever refactored to support Safe Haskell, I'd have to go fix up 50 very arcane CPP pragmas to match the internal details of an external package. Then I wind up checking them by round tripping through cabal installs and checking my haddocks. This is further complicated by the fact that some things are just becoming Safe "for free" as they go, due to the fact that they no longer need or can supply hand-rolled `Typeable` instances. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8310> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8354: Add INLINE (or at least INLINABLE) pragmas for methods of Ord in ghc-prim
by GHC 19 Nov '14

19 Nov '14

#8354: Add INLINE (or at least INLINABLE) pragmas for methods of Ord in ghc-prim -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Self-explanatory. Eq already has INLINE on (==) and (/=), and it'd be nice to have it on Ord so that SPECIALIZE pragmas on its methods in user code can fire. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8354> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5