November 2014 - ghc-tickets

Re: [GHC] #3511: port GHC to OpenBSD/sparc64 (unregisterised is fine)
by GHC 20 Nov '14

20 Nov '14

#3511: port GHC to OpenBSD/sparc64 (unregisterised is fine) -------------------------------------+------------------------------------- Reporter: zooko | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.11 (NCG) | Keywords: port sparc64 Resolution: | Architecture: sparc Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * os: OpenBSD => Unknown/Multiple * component: Compiler => Compiler (NCG) * architecture: Other => sparc -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3511#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9126: -ddump-to-file in TcRnMonad.lhs
by GHC 20 Nov '14

20 Nov '14

#9126: -ddump-to-file in TcRnMonad.lhs ------------------------------------+------------------------------------- Reporter: GregWeber | 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: | ------------------------------------+------------------------------------- As part of #8624, the first thing we realized is -ddump-to-file wasn't being respected. This is against HEAD, but I would really like to merge it to 7.8.3 if that is ok. I tested this with -ddump-tc and -ddump-splices. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[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] #9788: `coerce` has an impossible type
by GHC 20 Nov '14

20 Nov '14

#9788: `coerce` has an impossible type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ GHCi, version 7.8.3: 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> :set -fprint-explicit-foralls Prelude> :set -fprint-explicit-kinds Prelude> import Data.Coerce Prelude Data.Coerce> :t coerce coerce :: forall (k :: BOX) (a :: k) (b :: k). Coercible k a b => a -> b }}} Are those types `a` and `b` really of kind `k`? They certainly shouldn't be. This is worse in HEAD: GHC panics. (Actually, I think panicking is an improvement.) Easy to fix, happily. Will do so in the course of other work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9788> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[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