July 2017 - ghc-tickets

[GHC] #13968: TH gives "Illegal binding of built-in syntax" error
by GHC 26 Jul '17

26 Jul '17

#13968: TH gives "Illegal binding of built-in syntax" error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you try to splice in a definition that borrows an already existing `Name` using Template Haskell, GHC gives a confusing error message: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH $(pure [ValD (VarP 'succ) (NormalB (ConE 'True)) []]) }}} {{{ $ /opt/ghc/8.2.1/bin/runghc Bug.hs Bug.hs:6:3: error: Illegal binding of built-in syntax: succ | 6 | $(pure [ValD (VarP 'succ) (NormalB (ConE 'True)) []]) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} I'm not exactly sure what should happen here. My hunch was that my spliced-in `succ` would shadow the `succ` that's already in-scope. But in any case, the error message you get currently is quite awful, so at the very least that should be improved. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13968> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 26 Jul '17

26 Jul '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is where we stand on this: This bug seeks to address the fact that we currently have few good ways of encoding literal strings verbatim (e.g. as raw, unchanged bytes) in object code. This is because we insist on encoding primitive strings as null- terminated modified UTF-8. This means that things like `bytestring` and `text` have a rather complicated and inefficient handling of these literals. This inefficiency stems from two reasons, * One needs to look for and correctly handle the U+0000 codepoints (encoded as `0xc0 0x80`) in the primitive string * It's impossible to know what the length of the string is without walking it The solution here is to rework our desugaring of primitive strings such that, {{{#!hs "hello"# }}} Will be desugared as, {{{#!hs let x = "hello"# :: Addr# in (# 5#, "hello"# #) }}} This means that we can encode the string contents in plain UTF-8 without a NULL terminator. The type of `unpackCString#` then becomes, {{{#!hs unpackCString# :: (# Int#, Addr# #) -> String }}} and the implementation gets a tiny bit simpler (since it simply decodes a fixed number of bytes, instead of looking for a NULL). Consequently, libraries can then provide rules matching on `unpackCString#` applications, replacing them with what is essentially `memcpy`. This is for the most part a simple change, with the exception being GHCi support due to the need for unboxed tuples. jscholl started implementing this nearly a year ago but stalled. I recently rebased his work (Phab:D2443) and addressed several of the issues that came up in review. Unfortunately currently GHCi segmentation faults, which will take some to work out. Note that are two related problems that this does not address, * pure ASCII literals (which might be used to, for instance, encode a binary representation of a static `Array`) * `ByteArray#` literals, as requested in ticket:11312 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:73> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14033: Invalid newtype causes GHC to panic rather than fail to compile
by GHC 26 Jul '17

26 Jul '17

#14033: Invalid newtype causes GHC to panic rather than fail to compile -------------------------------------+------------------------------------- Reporter: | Owner: (none) InThisStyle10s6p | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code: {{{#!hs {-# LANGUAGE TypeFamilies #-} newtype Zero = Zero newtype Succ a = Succ a type family Add n m :: * where Add Zero m = m Add (Succ n) m = Succ (Add n m) }}} causes the following GHC error: {{{ $ ghc foo.hs [1 of 1] Compiling Main ( foo.hs, foo.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): isInjectiveTyCon sees a TcTyCon Zero }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14033> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13998: Default Signature messes up arity of type constructor
by GHC 26 Jul '17

26 Jul '17

#13998: Default Signature messes up arity of type constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) 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: -------------------------------------+------------------------------------- I have a situation that's shown up in my `quantification` library that I believe is an issue with GHC's typeclass method defaulting mechanism. Here is a self-contained example: {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE GADTs #-} import Data.Type.Equality class EqForall f where eqForall :: f a -> f a -> Bool class EqForall f => EqForallPoly f where eqForallPoly :: f a -> f b -> Bool default eqForallPoly :: TestEquality f => f a -> f b -> Bool eqForallPoly = defaultEqForallPoly defaultEqForallPoly :: (TestEquality f, EqForall f) => f a -> f b -> Bool defaultEqForallPoly x y = case testEquality x y of Nothing -> False Just Refl -> eqForall x y data Atom = AtomInt | AtomString | AtomBool data Value (a :: Atom) where ValueInt :: Int -> Value 'AtomInt ValueString :: String -> Value 'AtomString ValueBool :: Bool -> Value 'AtomBool instance TestEquality Value where testEquality (ValueInt _) (ValueInt _) = Just Refl testEquality (ValueString _) (ValueString _) = Just Refl testEquality (ValueBool _) (ValueBool _) = Just Refl testEquality _ _ = Nothing instance EqForall Value where eqForall (ValueInt a) (ValueInt b) = a == b eqForall (ValueString a) (ValueString b) = a == b eqForall (ValueBool a) (ValueBool b) = a == b instance EqForallPoly Value main :: IO () main = putStrLn "done" }}} This fails to compile both with GHC 8.0 and with GHC 8.2rc3. The error reads: {{{ default_sig_limitation.hs:40:10: error: • Expecting one more argument to ‘Value’ Expected a type, but ‘Value’ has kind ‘Atom -> *’ • In the type ‘Value’ In the expression: Main.$dmeqForallPoly @Value In an equation for ‘eqForallPoly’: eqForallPoly = Main.$dmeqForallPoly @Value }}} If I replace `EqForallPoly` instance with something more explicit, it will compile just fine: {{{ instance EqForallPoly Value where eqForallPoly = defaultEqForallPoly }}} Fortunately, this workaround isn't bad at all. I don't really mind it, but I thought I'd bring it up here in case it bites someone else in the future. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13998> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14018: Expose more pipeline functionality to GHC API
by GHC 26 Jul '17

26 Jul '17

#14018: Expose more pipeline functionality to GHC API -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- There's many useful functionality in non-exposed modules. For example, `ghc/Main.hs` contains `doMake` [0], which is a one-shop stop for compiling all (non-Haskell + Haskell) source files. Now a GHC API client has to replicate much of this logic to get GHC-alike behavior. Similarly for `parseModeFlags`. Or is the intent here to encourage using of Frontend plugins instead of relying on these internals? [0]: http://stuff.codereview.me/#ghc/ghc/Main.hs?corpus=ghc-8.2.1-rc2&signature&… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14018> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13799: -ddump-splices prints out declarations in the wrong order
by GHC 25 Jul '17

25 Jul '17

#13799: -ddump-splices prints out declarations in the wrong order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where $([d| data A = A data B = B |]) $([d| deriving instance Eq A deriving instance Eq B |]) }}} {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(8,6): Splicing declarations [d| data A_a13D = A_a13E data B_a13B = B_a13C |] ======> data A_a3IA = A_a3IB data B_a3IC = B_a3ID Bug.hs:(10,3)-(12,6): Splicing declarations [d| deriving instance Eq B deriving instance Eq A |] ======> deriving instance Eq A deriving instance Eq B }}} Notice that it printed {{{#!hs [d| deriving instance Eq B deriving instance Eq A |] }}} instead of {{{#!hs [d| deriving instance Eq A deriving instance Eq B |] }}} which is what I originally wrote. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13799> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12801: Misleading error message when deriving Functor
by GHC 25 Jul '17

25 Jul '17

#12801: Misleading error message when deriving Functor -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling this trivial demo program: {{{ data Container = Container [Wibble Int] deriving (Eq, Show) data Wibble a = Wibble a | Wobble deriving (Eq, Functor, Show) }}} results in the error message: {{{ a.hs:6:13: error: • No instance for (Eq (Wibble Int)) arising from the first field of ‘Container’ (type ‘[Wibble Int]’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Eq Container) a.hs:6:17: error: • No instance for (Show (Wibble Int)) arising from the first field of ‘Container’ (type ‘[Wibble Int]’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Show Container) a.hs:12:17: error: • Can't make a derived instance of ‘Functor Wibble’: You need DeriveFunctor to derive an instance for this class • In the data declaration for ‘Wibble’ }}} The "No instance for (Eq|Show)" are rather misleading, because the *actual* error is that the `{-# LANGUAGE DeriveFunctor #-}` pragma is missing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12801> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10684: Error cascade when unrelated class derivation fails
by GHC 25 Jul '17

25 Jul '17

#10684: Error cascade when unrelated class derivation fails -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Pretty minor bug, but I thought I'd point it out: {{{ module A where import Data.Typeable data A = A deriving (Show, Typeable) data B = B A deriving (Show) }}} I get two errors when I expect one: {{{ A.hs:3:28: Can't make a derived instance of `Typeable A': You need -XDeriveDataTypeable to derive an instance for this class In the data declaration for `A' A.hs:4:24: No instance for (Show A) arising from the 'deriving' clause of a data type declaration Possible fix: add an instance declaration for (Show A) or use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Show B) }}} The failed Typeable derivation also causes the Show derivation to fail, which causes an error later in the file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14010: UndecidableSuperClasses - Could not deduce (Category d)
by GHC 25 Jul '17

25 Jul '17

#14010: UndecidableSuperClasses - Could not deduce (Category d) -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple UndecidableSuperClasses | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this well-typed code: {{{#!hs {-# LANGUAGE NoImplicitPrelude, TypeInType, TypeFamilies, UndecidableSuperClasses, RankNTypes, TypeOperators, FlexibleContexts, TypeSynonymInstances, FlexibleInstances, UndecidableInstances #-} module Monolith where import Data.Kind (Type) import GHC.Exts (Constraint) type family (~>) :: c -> c -> Type type instance (~>) = (->) type instance (~>) = ArrPair type family Fst (p :: (a, b)) :: a where Fst '(x, _) = x type family Snd (p :: (a, b)) :: b where Snd '(_, y) = y data ArrPair a b = ArrPair (Fst a ~> Fst b) (Snd a ~> Snd b) type family Super c :: Constraint where Super Type = () Super (c, d) = (Category c, Category d) class Super cat => Category cat where id :: forall (a :: cat). a ~> a instance Category Type where id = \x -> x instance (Category c, Category d) => Category (c, d) where id = ArrPair id id class Category (c, d) => Functor (f :: c -> d) where --class (Category c, Category d) => Functor (f :: c -> d) where map :: (a ~> b) -> (f a ~> f b) data OnSnd f a b = OnSnd (f '(a, b)) instance Functor (f :: (c, d) -> Type) => Functor (OnSnd f a) where map f (OnSnd x) = OnSnd (map (ArrPair id f) x) }}} The compiler accepts it. But if I change the definition of 'Functor' for the commented one, I get an error: {{{ super.hs:39:10: error: • Could not deduce (Category d) arising from the superclasses of an instance declaration from the context: Functor f bound by the instance declaration at super.hs:39:10-61 Possible fix: add (Category d) to the context of the instance declaration • In the instance declaration for ‘Functor (OnSnd f a)’ | 39 | instance Functor (f :: (c, d) -> Type) => Functor (OnSnd f a) where | }}} I can reproduce this on 8.0.1, 8.2.0.20170704 and HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14010> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13168: Ambiguous interface errors in GHCi, even with -XPackageImports
by GHC 24 Jul '17

24 Jul '17

#13168: Ambiguous interface errors in GHCi, even with -XPackageImports -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 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: -------------------------------------+------------------------------------- Originally reported in https://github.com/haskell/cabal/issues/4253, but I moved it here after being reassured that this was a GHCi bug, not a `Cabal` one. To reproduce this issue, you'll need to install two libraries that export two constructors with the same name. The original issue uses `GLFW` and `GLFW-b` as examples, but for the puposes of test case minimalization, I've prepared a repo here (https://github.com/RyanGlScott/cabal-gh4253) with as small of an example as I can manage. To reproduce the issue, do the following: {{{ $ git clone https://github.com/RyanGlScott/cabal-gh4253 $ cd cabal-gh4253/ $ cabal install package1/ package2/ $ ghci -XPackageImports GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> import "package1" DuplicateModuleName λ> Window <interactive>:1:1: error: Ambiguous interface for ‘DuplicateModuleName’: it was found in multiple packages: package1-0.1.0.0 package2-0.1.0.0 }}} This seems to be specific to GHCi, because I cannot find a way to trigger the same issue with `ghc --make`. I've reproduced this with GHC 8.0.2 and HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13168> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10