July 2014 - ghc-tickets

[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

[GHC] #8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64)
by GHC 19 Nov '14

19 Nov '14

#8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64) ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This appears to be the x86 assembly for a specialization for `even :: Int -> Bool` that's produced by a SPECIALISE pragma for `(^) :: Int -> Int -> Int` in GHC.Real. The relevant bit is offsets `0x2c` through `0x3b`. {{{ 0000000c <base_GHCziReal_evenzuzdseven1_info>: c: 8b 45 00 mov 0x0(%ebp),%eax f: c7 45 00 2c 00 00 00 movl $0x2c,0x0(%ebp) 12: R_386_32 .text 16: 89 c6 mov %eax,%esi 18: f7 c6 03 00 00 00 test $0x3,%esi 1e: 75 0c jne 2c <c8gO_info> 20: ff 26 jmp *(%esi) 22: 66 90 xchg %ax,%ax 24: 00 00 add %al,(%eax) 26: 00 00 add %al,(%eax) 28: 20 00 and %al,(%eax) ... 0000002c <c8gO_info>: 2c: b8 02 00 00 00 mov $0x2,%eax 31: 89 c1 mov %eax,%ecx 33: 8b 46 03 mov 0x3(%esi),%eax 36: 99 cltd 37: f7 f9 idiv %ecx 39: 85 d2 test %edx,%edx 3b: 75 0b jne 48 <c8gO_info+0x1c> 3d: be 02 00 00 00 mov $0x2,%esi 3e: R_386_32 ghczmprim_GHCziTypes_True_closure 42: 83 c5 04 add $0x4,%ebp 45: ff 65 00 jmp *0x0(%ebp) 48: be 01 00 00 00 mov $0x1,%esi 49: R_386_32 ghczmprim_GHCziTypes_False_closure 4d: 83 c5 04 add $0x4,%ebp 50: ff 65 00 jmp *0x0(%ebp) }}} It would be much better to do a simple `testb $0x1,0x3(%esi)` in place of the first six instructions of `c8gO_info`. The NCG generates similar code on x86_64. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8311> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8313: Poor performance of higher-order functions with unboxing
by GHC 19 Nov '14

19 Nov '14

#8313: Poor performance of higher-order functions with unboxing -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 7.6.3 Keywords: slow unboxed | Operating System: Unknown/Multiple higher order | Type of failure: Runtime Architecture: Unknown/Multiple | performance bug Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- I was testing out some code to see how GHC handled some unboxed higher- order functions, and was suprised by the results I found. Here is some sample code: {{{ {-# LANGUAGE BangPatterns #-} {-# LANGUAGE LambdaCase #-} {-# LANGUAGE MagicHash #-} import GHC.Exts import System.Environment rel# :: Int# -> Int# -> Int# -> Bool rel# i# j# k# = (i# +# j# +# k#) ># 100000000# rel :: Int -> Int -> Int -> Bool rel (I# i#) (I# j#) (I# k#) = rel# i# j# k# manual :: (Int# -> Int# -> Int# -> Bool) -> (Int, Int, Int) manual r# = go 0# 0# 0# where go i# j# k# | r# i# j# k# = (I# i#, I# j#, I# k#) | otherwise = go j# k# (i# +# 1#) {-# NOINLINE manual #-} auto :: (Int -> Int -> Int -> Bool) -> (Int, Int, Int) auto r = go 0 0 0 where go !i !j !k | r i j k = (i, j, k) | otherwise = go j k (i+1) {-# NOINLINE auto #-} main = getArgs >>= \case "manual" : _ -> print $ manual rel# -- This case is significantly slower. "auto" : _ -> print $ auto rel -- Why? }}} A loop that has to box its loop parameters to call a predicate turns out to be significantly faster than one that uses a predicate that takes unboxed values directly. The answer turns out to be (I believe) in ghc/utils/genapply/GenApply.hs. applyTypes has an entry [P,P,P], but only [N]. This means that the manual loop has to use a slower calling convention than the boxed loop. I'm not sure whether this should be 'fixed,' as my encounter with it was experimental in nature, and I don't have a real use case. The comment on applyTypes says its cases cover 99% of uses, and mine is not a real use. This ticket may serve as documentation at least, though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8313> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5