- ghc-tickets - Haskell.org

[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 26 Jul '17

26 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 25 Jul '17

25 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

Re: [GHC] #847: Threaded RTS problems on FreeBSD
by GHC 24 Jul '17

24 Jul '17

#847: Threaded RTS problems on FreeBSD -----------------------------------+--------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.4.3 Component: Runtime System | Version: 6.4.2 Resolution: fixed | Keywords: Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: -----------------------------------+--------------------------------- Changes (by Ben Gamari <ben@…>): * failure: => None/Unknown Comment: In [changeset:"d8051c6cf08f02331f98fed7d5e88a95bd76e534/ghc" d8051c6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d8051c6cf08f02331f98fed7d5e88a95bd76e534" Use libpthread instead of libthr on FreeBSD Since #847 we have used libthr due to reported hangs with FreeBSD's KSE-based M:N pthread implementation. However, this was nearly 12 years ago and today libpthread seems to work fine. Moreover, adding -lthr to the linker flags break when used in conjunction with -r when gold is used (since -l and -r are incompatible although BFD ld doesn't complain). Test Plan: Validate on FreeBSD Reviewers: kgardas, austin Subscribers: rwbarton, thomie GHC Trac Issues: #847 Differential Revision: https://phabricator.haskell.org/D3773 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/847#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13999: Simple function not inlined within declaration marked NOINLINE
by GHC 24 Jul '17

24 Jul '17

#13999: Simple function not inlined within declaration marked NOINLINE -------------------------------------+------------------------------------- Reporter: srb | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.2 Keywords: Inlining | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This seems so shallow that I feel like I must be missing something, but if I implement a function like {{{#!hs eq :: Bool -> Bool -> Bool eq x y = x == y {-# NOINLINE eq #-} }}} the boolean equality operator is not inlined in eq, even at -O2. The generated core is instead {{{#!hs eq = $fEqBool_$c== }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13999> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10064: Add support for "foo"## literals to MagicHash
by GHC 24 Jul '17

24 Jul '17

#10064: Add support for "foo"## literals to MagicHash -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm working on a high-performance library for building up buffers of data. Appending ByteStrings works pretty well, but, for bytestring literals, it's faster to avoid the CAF (and it's associated tag check + indirect jump) entirely and append a zero-terminate MagicHash string literal via Addr#. Then I discovered that it's 30% faster if you can avoid the strlen with an explicit length. See this benchmark: https://github.com/chadaustin /buffer- builder/blob/ac662962d6d3c21f206ab8e8121323b9f18677fa/bench/Bench.hs#L42 That API is not very pleasant, of course. :) Thus, here is a feature request: It would be great if "foo"## produced (# Int#, Addr# #), where the Int# is the length of the buffer in bytes. The compiler could enforce that the literal only contains 8-bit values. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6