October 2018 - ghc-tickets

[GHC] #15791: typeKind confuses Type and Constraint
by GHC 03 Dec '18

03 Dec '18

#15791: typeKind confuses Type and Constraint -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 `typeKind` function takes a type and reports its kind. It gets this wrong, sometimes: if you ask for `typeKind` of the quantified constraint `Eq a => C a` (where `C` is a class), you get `Type`. This is wrong, though I don't have a concrete case where GHC misfires. We ''could'' fix `typeKind` to get this right, but doing so would require making the `FunTy` case recursive (right now, it always returns `Type`). This is wasteful, because most clients of `typeKind` do not care about the distinction between `Type` and `Constraint`. Instead, I propose making a new `tcTypeKind` which behaves correctly in this case. We could also muse about making `tcTypeKind` monadic so that it can look through unification variables. This might also simplify the story around `Note [The tcType invariant]`. Regardless of the "make monadic" idea, I claim that, when this is done, we should have `isPredTy` be functionally equivalent to `(== Constraint) . tcTypeKind`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15791> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13256: Warn on out-of-range literals in pattern matches too
by GHC 03 Dec '18

03 Dec '18

#13256: Warn on out-of-range literals in pattern matches too -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- We have these nice warnings for numeric literal expressions that are out of range of their type: {{{ Prelude> 100000000000000000000000000000000 :: Int <interactive>:1:1: warning: [-Woverflowed-literals] Literal 100000000000000000000000000000000 is out of the Int range -9223372036854775808..9223372036854775807 }}} but nothing for numeric patterns: {{{ Prelude> (\x -> case (x :: Int) of 100000000000000000000000000000000 -> 0) 8 :: Int <interactive>:3:8: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: p where p is not one of {100000000000000000000000000000000} *** Exception: <interactive>:3:8-64: Non-exhaustive patterns in case }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13256> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10930: missing empty-Enumeration warning for `Natural`
by GHC 03 Dec '18

03 Dec '18

#10930: missing empty-Enumeration warning for `Natural` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #7881, #10929 Differential Rev(s): | -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10930> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9505: Bounded instance for Word (and possibly others) uses unboxed literals
by GHC 03 Dec '18

03 Dec '18

#9505: Bounded instance for Word (and possibly others) uses unboxed literals -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- There's a comment above saying GHC won't optimise. I think since 7.8 they are unboxed by default, so that comment and the explicit constructors can be removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9505> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14298: Let Template Haskell dynamically add a library against which to link
by GHC 02 Dec '18

02 Dec '18

#14298: Let Template Haskell dynamically add a library against which to link -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.2.1 Haskell | 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: -------------------------------------+------------------------------------- As of today, Template Haskell supports emitting foreign files (for C compiler languages) via `addForeignFile`. In doing so, GHC takes on the work of compiling these, linking against them, and then cleaning up any other files. This makes packages like `inline-c` ([https://hackage.haskell.org/package/inline-c] possible, where you can write C snippets in quasiquotes and these can interact with your Haskell code. The user doesn't need to pass extra options to GHC (except to enable the right language extensions), and they don't have to see any of the intermediate generated artifacts. Unfortunately, that breaks down for non C compiler languages. It would be nice for TH to also support directly adding a static library, since then one could * use TH's `runIO` to generate static libraries by calling out to whatever other compilers * add the contents of those libraries via TH * delete the temporary files created in the process (again using `runIO`) * have GHC statically link against the content (from the second bullet point) I'm not sure what the API for this could be, but maybe adding a `StaticLibrary` constructor to the `ForeignSrcLang` data type (so one could use `addForeignFile :: ForeignSrcLang -> String -> Q ()`)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12643: class declaration works in ghci, but not in a file
by GHC 02 Dec '18

02 Dec '18

#12643: class declaration works in ghci, but not in a file -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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 following ghci session prints no errors: {{{ > :set -XStandaloneDeriving -XDeriveGeneric > import GHC.Generics > import Control.Monad.Except > deriving instance Generic (ExceptT e m a) > class F a where f :: Rep (Except String a) x }}} However, when I transfer this to a file: {{{ {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE DeriveGeneric #-} import GHC.Generics import Control.Monad.Except deriving instance Generic (ExceptT e m a) class F a where f :: Rep (Except String a) x }}} I get a mysterious error: {{{ test.hs:6:17: error: • Couldn't match type ‘Rep (Except String a0)’ with ‘Rep (Except String a)’ Expected type: Rep (Except String a) x Actual type: Rep (Except String a0) x NB: ‘Rep’ is a type function, and may not be injective The type variable ‘a0’ is ambiguous • In the ambiguity check for ‘f’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: f :: forall a. F a => forall x. Rep (Except String a) x In the class declaration for ‘F’ }}} If I turn on -fdefer-type-errors, I can verify that the type family indeed reduces far enough for a and x to be arguments to injective types, so I believe GHC should not consider this an error: {{{ > :set -XRankNTypes > :kind! forall a x. Rep (Except String a) x forall a x. Rep (Except String a) x :: * = D1 ('MetaData "ExceptT" "Control.Monad.Trans.Except" "transformers-0.5.2.0" 'True) (C1 ('MetaCons "ExceptT" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 (Data.Functor.Identity.Identity (Either [Char] a))))) x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12643> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15561: TypeInType: Type error conditioned on ordering of GADT and type family definitions
by GHC 02 Dec '18

02 Dec '18

#15561: TypeInType: Type error conditioned on ordering of GADT and type family definitions -------------------------------------+------------------------------------- Reporter: Bj0rn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies, GADTs | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this code which successfully compiles: {{{#!hs {-# LANGUAGE TypeInType, TypeFamilies, GADTs #-} module Bug where class HasIndex a where type Index a emptyIndex :: IndexWrapper a instance HasIndex [a] where type Index [a] = Int emptyIndex = Wrap 0 data IndexWrapper a where Wrap :: Index a -> IndexWrapper a type family UnwrapAnyWrapperLikeThing (a :: t) :: k type instance UnwrapAnyWrapperLikeThing ('Wrap a :: IndexWrapper [b]) = a }}} The mere act of moving the definition of `IndexWrapper` anywhere below the definition of `UnwrapAnyWrapperLikeThing` makes the type family instance at the bottom of the example fail compilation, with this error: {{{ Bug.hs:17:15: error: • Illegal type synonym family application in instance: Index [b] • In the type instance declaration for ‘UnwrapAnyWrapperLikeThing’ | 17 | type instance UnwrapAnyWrapperLikeThing ('Wrap a :: IndexWrapper [b]) = a | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This is the smallest example that I could come up with; my real scenario of course has more things going on, but I can share if it would help. The problem for me (other than that I'm pretty sure reordering definitions in Haskell should never affect anything) is that I would like just the definition of the type family (`UnwrapAnyWrapperLikeThing` in this example) in module `A` and all of the other definitions in module `B` that imports `A`. Ideally, I would have liked to add a `HasIndex a` constraint to the `Wrap` constructor, but that disqualifies use of `'Wrap` on the type level. This does make me feel like I'm on shaky ground to begin with. I have reproduced this bug on 8.2.2, 8.4.3 and 8.6.0.20180810 (NixOS). I should note that 8.0.2 rejects even the code that I pasted here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15561> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14668: Ordering of declarations can cause typechecking to fail
by GHC 02 Dec '18

02 Dec '18

#14668: Ordering of declarations can cause typechecking to fail -------------------------------------+------------------------------------- Reporter: heptahedron | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- The following will successfully typecheck: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeFamilies #-} data CInst data G (b :: ()) = G class C a where type family F a class (C a) => C' a where type family F' a (b :: F a) -- data CInst instance C CInst where type F CInst = () instance C' CInst where type F' CInst (b :: F CInst) = G b }}} But if the `data CInst` declaration is moved to where it is currently commented out, typechecking fails with this error: {{{ Test.hs:23:18: error: • Expected kind ‘F CInst’, but ‘b’ has kind ‘()’ • In the second argument of ‘F'’, namely ‘(b :: F CInst)’ In the type instance declaration for ‘F'’ In the instance declaration for ‘C' CInst’ | 23 | type F' CInst (b :: F CInst) = G b | }}} However, the data declaration //can// be in the lower position if the kind annotation for its argument is instead written as `data G (b :: F CInst) = G`. This behavior is also exhibited when G is a type family (I believe the sort of type family does not matter, but I know for sure closed and open type families). I was using GHC 8.2.2 when I discovered this, but user `erisco` on `#haskell` confirmed for 8.2.1 as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14668> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15777: Ordering of code in file affects compilation
by GHC 02 Dec '18

02 Dec '18

#15777: Ordering of code in file affects compilation -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Keywords: | 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: -------------------------------------+------------------------------------- consider the following module: {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} -- | Conversion between unlifted and lifted datatypes module Packed.Levity ( -- * Types Rep , Levity(..) ) where import Data.Kind (Type) import GHC.Types (TYPE, RuntimeRep(..), Int(..), Word(..)) import GHC.Exts (Int#, Word#, ByteArray#) type family Rep (a :: Type) :: RuntimeRep type instance Rep Int = IntRep type instance Rep Word = WordRep type Stuff# = (# Int#, Int# #) data Stuff = Stuff Int# Int# type instance Rep Stuff = TupleRep '[ 'IntRep, 'IntRep ] stuff# :: (# Int#, Int# #) -> Stuff stuff# (# x, y #) = Stuff x y unStuff# :: Stuff -> (# Int#, Int# #) unStuff# (Stuff x y) = (# x, y #) class Levity (a :: Type) where type Unlifted a :: TYPE (Rep a) box :: Unlifted a -> a unbox :: a -> Unlifted a instance Levity Int where type Unlifted Int = Int# box = I# unbox (I# i) = i instance Levity Word where type Unlifted Word = Word# box = W# unbox (W# w) = w instance Levity Stuff where type Unlifted Stuff = Stuff# box = stuff# unbox = unStuff# }}} This succeeds to compile. Now, if we move everything from `type family Rep` to `unStuff# (` to the bottom of the module, it fails to compile. {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} -- | Conversion between unlifted and lifted datatypes module Packed.Levity ( -- * Types Rep , Levity(..) ) where import Data.Kind (Type) import GHC.Types (TYPE, RuntimeRep(..), Int(..), Word(..)) import GHC.Exts (Int#, Word#, ByteArray#) class Levity (a :: Type) where type Unlifted a :: TYPE (Rep a) box :: Unlifted a -> a unbox :: a -> Unlifted a instance Levity Int where type Unlifted Int = Int# box = I# unbox (I# i) = i instance Levity Word where type Unlifted Word = Word# box = W# unbox (W# w) = w instance Levity Stuff where type Unlifted Stuff = Stuff# box = stuff# unbox = unStuff# type family Rep (a :: Type) :: RuntimeRep type instance Rep Int = IntRep type instance Rep Word = WordRep type Stuff# = (# Int#, Int# #) data Stuff = Stuff Int# Int# type instance Rep Stuff = TupleRep '[ 'IntRep, 'IntRep ] stuff# :: (# Int#, Int# #) -> Stuff stuff# (# x, y #) = Stuff x y unStuff# :: Stuff -> (# Int#, Int# #) unStuff# (Stuff x y) = (# x, y #) }}} {{{ ts.hs:33:25-30: error: • Expected kind ‘TYPE (Rep Stuff)’, but ‘Stuff#’ has kind ‘TYPE ('TupleRep '['IntRep, 'IntRep])’ • In the type ‘Stuff#’ In the type instance declaration for ‘Unlifted’ In the instance declaration for ‘Levity Stuff’ | 33 | type Unlifted Stuff = Stuff# | ^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15777> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8043: Feature Request : Qualified module exports
by GHC 01 Dec '18

01 Dec '18

#8043: Feature Request : Qualified module exports ------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I quite like the practice of using `-XNoImplicitPrelude` and then defining my own (often per-project) Prelude doing things like: {{{ module MyProject.Prelude ( module P ) import Data.Text as P (Text) import Prelude as P hiding (head, init, tail, last) }}} As an extension to the above idea, I would like to add qualified module exports defined so that I can do this: {{{ module MyProject.Prelude ( module P , qualified module T ) import Data.Text as P (Text) import Prelude as P hiding (head, init, tail, last) import qualified Data.Text as T }}} so that any file which imports `MyProject.Prelude` will then have all the identifiers that they would normally get if they did: {{{ import qualified Data.Text as T }}} Is this something that would have to go through the Haskell Next procedure? If so, how does one get that kicked off? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8043> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13