- ghc-tickets - Haskell.org

[GHC] #14140: Better treatment for dataToTag
by GHC 12 Sep '17

12 Sep '17

#14140: Better treatment for dataToTag -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- In `libraries/Cabal/Cabal/Distribution/System.hs` I found {{{ eqOS :: OS -> OS -> Bool eqOS (OtherOS s1) (OtherOS s2) = s1 == (s2 :: String) eqOs a b = dataToTag a == dataTag b }}} (actually it's not called `eqOS`; it's the derived equality for `OS`). By the time this gets to Core it looks something like this {{{ eqOS a b = case a of OtherOS s1 -> case b of OtherOS s2 -> eqString s1 s2 _ -> case dataToTag b of 16# -> True r -> False _ -> dataToTag a == dataToTag b }}} The `dataToTag` code has been duplicated; and in the `OtherOS s1` branch GHC can constant-fold the `dataToTag` on `a` to `16#`, the tag of `OtherOS`. But GHC is no so clever for the `dataToTag b`. We know that `b` is not `OtherOS`, so we know its tag is not `16#`, so the innermost case is entirely redundant. But we don't spot that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14140> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14186: CSE fails to CSE
by GHC 12 Sep '17

12 Sep '17

#14186: CSE fails to CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- Consider this code: {{{ module CSEBug where data Succs a = Succs a [a] instance Functor Succs where fmap f (Succs o s) = Succs (f o) (map f s) foo, bar :: (a -> b) -> (b -> c) -> Succs a -> Succs c foo f g x = fmap (g . f) x bar f g x = fmap (g . f) x }}} If I compile this with `-O`, `foo` and `bar` are not CSEd, which can be seen with `-ddump-cse`. Removing either the first or the second argument of `Succs` makes CSE work. Is there a size limit on CSE? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14186> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14219: Include source location information in -ddump-rule-rewrites
by GHC 12 Sep '17

12 Sep '17

#14219: Include source location information in -ddump-rule-rewrites -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Debugging) | 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: -------------------------------------+------------------------------------- Inlining is one of the most common and powerful optimizations and it interacts with rewrite-rules which is also common the libraries including base. When debugging a performance problem we are interacting with the rewrite-rules written by others hidden somewhere in some library that we are using. When I use the `-ddump-rule-rewrites` option I get an output like this: {{{ Rule fired Rule: Class op >>= Module: (BUILTIN) Before: GHC.Base.>>= TyArg GHC.Types.IO ValArg GHC.Base.$fMonadIO After: GHC.Base.$fMonadIO1 }}} This does not say where exactly this rule is defined in the source. It is sort of ok if this is my code I would perhaps know where this rule is. But when it is in some dependency that I am using it is hard to find. It will be really helpful if the source location information can be provided in this dump information, so that one can go and examine the source. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14219> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14220: GeneralizedNewtypeDeriving and polymorphic arguments don't play nicely together
by GHC 12 Sep '17

12 Sep '17

#14220: GeneralizedNewtypeDeriving and polymorphic arguments don't play nicely together --------------------------------------+--------------------------------- Reporter: ivanm | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I'm not sure if this is a bug per se, but ghci says to report it so here it is: test.hs: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} class NameOf a where nameOf :: proxy a -> String instance NameOf Int where nameOf _ = "Int" newtype MyInt = MyInt Int deriving (NameOf) }}} {{{ $ ghci test.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( test.hs, interpreted ) test.hs:10:13: warning: [-Wdeferred-type-errors] • Couldn't match representation of type ‘proxy1 Int’ with that of ‘proxy1 MyInt’ arising from a use of ‘GHC.Prim.coerce’ NB: We cannot know what roles the parameters to ‘proxy1’ have; we must assume that the role is nominal • In the expression: GHC.Prim.coerce @(forall (proxy :: TYPE GHC.Types.PtrRepLifted -> TYPE GHC.Types.PtrRepLifted). proxy Int -> String) @(forall (proxy :: TYPE GHC.Types.PtrRepLifted -> TYPE GHC.Types.PtrRepLifted). proxy MyInt -> String) nameOf In an equation for ‘nameOf’: nameOf = GHC.Prim.coerce @(forall (proxy :: TYPE GHC.Types.PtrRepLifted -> TYPE GHC.Types.PtrRepLifted). proxy Int -> String) @(forall (proxy :: TYPE GHC.Types.PtrRepLifted -> TYPE GHC.Types.PtrRepLifted). proxy MyInt -> String) nameOf When typechecking the code for ‘nameOf’ in a derived instance for ‘NameOf MyInt’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘NameOf MyInt’ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): opt_univ fell into a hole {a15j} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14220> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14216: Compare compiler performance of GHC 8.0.2 and 8.2.1 on Stackage
by GHC 11 Sep '17

11 Sep '17

#14216: Compare compiler performance of GHC 8.0.2 and 8.2.1 on Stackage -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Simon M. suggests that we take a sample of Stackage packages (perhaps the top 200 by Hackage download count) and compare their compiler performance statistics with GHC 8.0.2 and 8.2.1. We'll want to collect overall GHC wall clock time, as well as the per-pass metrics produced by `-v`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14216> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8583: Associated pattern synonyms
by GHC 11 Sep '17

11 Sep '17

#8583: Associated pattern synonyms ------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The PatternSynonyms wiki page has a section on (typeclass-)associated pattern synonyms: {{{ class ListLike l where pattern Nil :: l a pattern Cons :: a -> l a -> a isNil :: l a -> Bool isNil Nil = True isNil (Cons _ _) = False append :: l a -> l a -> l a instance ListLike [] where pattern Nil = [] pattern Cons x xs = x:xs append = (++) headOf :: (ListLike l) => l a -> Maybe a headOf Nil = Nothing headOf (Cons x _) = Just x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8583> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #10818: GHC 7.10.2 takes much longer to compile some packages
by GHC 11 Sep '17

11 Sep '17

#10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu- | Owner: yamamoto | Type: bug | Status: new Priority: normal | Milestone: 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: Differential Revisions: | -------------------------------------+------------------------------------- If we compile the iproute package by GHC, GHC 7.10.2 take much longer than GHC 7.8.4. See the report from Travis CI: https://travis-ci.org/kazu-yamamoto/iproute/builds/77427248 I can reproduce this on my local MacBookAir: - GHC 7.8.4: cabal build 8.81s user 0.94s system 103% cpu 9.430 total - GHC 7.10.2: cabal build 37.86s user 3.49s system 98% cpu 42.066 total -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10818> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #13738: TypeApplications-related GHC internal error
by GHC 11 Sep '17

11 Sep '17

#13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is reproducible with GHC 8.0.1, 8.0.2, 8.2.1, and HEAD: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} module Bug where import Data.Coerce class MFunctor t where hoist :: (Monad m) => (forall a . m a -> n a) -> t m b -> t n b newtype TaggedTrans tag trans m a = TaggedTrans (trans m a) instance MFunctor trans => MFunctor (TaggedTrans tag trans) where hoist = coerce @(forall (m :: * -> *) (n :: * -> *) (b :: k). Monad m => (forall (a :: *). m a -> n a) -> trans m b -> trans n b) @(forall (m :: * -> *) (n :: * -> *) (b :: k). Monad m => (forall (a :: *). m a -> n a) -> TaggedTrans tag trans m b -> TaggedTrans tag trans n b) hoist }}} {{{ GHCi, version 8.3.20170516: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:18:26: error: • GHC internal error: ‘k’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a1tR :-> Type variable ‘m’ = m, a1tS :-> Type variable ‘n’ = n, a1tT :-> Type variable ‘b’ = b, a1tV :-> Type variable ‘trans’ = trans, a1tW :-> Type variable ‘tag’ = tag, a1tX :-> Type variable ‘m’ = m, a1tY :-> Type variable ‘n’ = n, a1KE :-> Type variable ‘k’ = k, a1KF :-> Type variable ‘k’ = k] • In the kind ‘k’ In the type ‘(forall (m :: * -> *) (n :: * -> *) (b :: k). Monad m => (forall (a :: *). m a -> n a) -> trans m b -> trans n b)’ In the expression: coerce @(forall (m :: * -> *) (n :: * -> *) (b :: k). Monad m => (forall (a :: *). m a -> n a) -> trans m b -> trans n b) @(forall (m :: * -> *) (n :: * -> *) (b :: k). Monad m => (forall (a :: *). m a -> n a) -> TaggedTrans tag trans m b -> TaggedTrans tag trans n b) hoist | 18 | (b :: k). | ^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13738> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #12025: Order of constraints forced (in pattern synonyms, type classes in comments)
by GHC 10 Sep '17

10 Sep '17

#12025: Order of constraints forced (in pattern synonyms, type classes in comments) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeApplications PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 11513, 10928 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Ever since `TypeApplications` the order of quantification matters. It seems there are some places where the user has no control over the order: {{{#!hs data A a where X :: A [xxx] pattern X' :: forall t. () => forall xxx. t ~ [xxx] => A t pattern X' = X }}} This quantifies the universal `t` and the existential `xxx`.. but in this case `t` is constrained to equal `[xxx]` so when we supply our first type (the universal `t`) it is forced to be of the form `[a]`. Then the existential is forced to equal `a` (there is currently no way to express this without a type annotation `X' @[t] @t :: A [t]`, see ticket #11385 to allow `X' @[_t] @_t`, for this ticket the equality is inherent in `X` so it's no big deal). This means that the first argument really doesn't give any further information but it seems impossible to reorder the existential type before the universal. This either forces the user to supply a dummy type: {{{#!hs X' @_ @ActualType }}} or to write `[ActualType]` explicitly {{{#!hs X' @[ActualType] X' @[ActualType] @ActualType X' @[_] @ActualType }}} This may be a bigger inconvenience than it may seem: the return type can be more complicated `A (B (C a))` and it requires the user to look it up. `X' @_ @ActualType` feels like bad library design, especially as the number of existential variables grows and the user has to remember how many underscores to provide. See also ticket:10928#comment:5 Keep in mind that this usage will be common, since the more obvious (see ticket:10928#comment:16) {{{#!hs pattern X'' :: forall xxx. A [xxx] pattern X'' = X }}} cannot match against a type `A a` {{{#!hs -- Works foo :: A a -> ... foo X' = ... -- Doesn't bar :: A a -> ... bar X'' = ... }}} Thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12025> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14212: Give better error message with non-supported Backpack/TH use
by GHC 10 Sep '17

10 Sep '17

#14212: Give better error message with non-supported Backpack/TH use -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.2.1 Haskell | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is something of a follow up to #13268. Suppose you have an indefinite package. If you use TemplateHaskell with a splice that was defined in the indefinite package itself, there is no reasonable way to expect this to work, since in general you can't have compiled the the imported module before you need to run the splice (and the splice needs to be run before you know how the holes are instantiated.) But say you try and do it anyway. GHC will give an error like this: {{{ ghc: ^^ Could not load 'qzm0zi1zminplacezmENEL5G3hx7IK2t0f6HloyH_A_f_closure', dependency unresolved. See top entry above. ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: qzm0zi1zminplacezmENEL5G3hx7IK2t0f6HloyH_A_f_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} This is not a good error message. A good error message would be to say that you can't use in a splice a function defined in an indefinite package (as per the current library.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14212> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0