August 2017 - ghc-tickets

[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] #13268: Backpack doesn't work with Template Haskell, even when it should
by GHC 10 Sep '17

10 Sep '17

#13268: Backpack doesn't work with Template Haskell, even when it should -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.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: -------------------------------------+------------------------------------- Obviously, we can't run Template Haskell from an indefinite package when we are (solely) typechecking the indefinite package itself. But in principle, Template Haskell code from other packages should be fair game. Alas, this not the case, because GHC attempts to dynamic link in libraries for ALL dependencies, including the ones we don't have code for. Quick fix should be to not link those in? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13268> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14090: Static pointers are not being registered under certain conditions
by GHC 08 Sep '17

08 Sep '17

#14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | 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: -------------------------------------+------------------------------------- It seems that if the module is compiled with -O2 only the static pointers in the module export list survive the Simplifier. This is a regression. {{{ {-# LANGUAGE StaticPointers #-} import GHC.StaticPtr staticHello :: StaticPtr String staticHello = static "hello" main = do keys <- staticPtrKeys if null keys then error "static ptrs are not being registered" else putStrLn "Everything is fine" }}} {{{ pepe:~/scratch$ stack --resolver ghc-8.2.1 script --optimize bug-spt.hs Using resolver: ghc-8.2.1 specified on command line bug-spt: static ptrs are not being registered CallStack (from HasCallStack): error, called at bug-spt.hs:11:10 in main:Main pepe:~/scratch$ stack --resolver ghc-8.0.2 script --optimize bug-spt.hs Using resolver: ghc-8.0.2 specified on command line Everything is fine }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14090> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9661: Branchless ==# is compiled to branchy code
by GHC 08 Sep '17

08 Sep '17

#9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This started as a comment on #6135, but Jan Stolarek requested that I file a separate report. The branchless tests `<#`, `>#`, `<=#`, and `>=#`, and their wordy cousins, seem to work properly, but `==#` and `eqWord#` don't. If I write {{{#!hs foo x = tagToEnum# ((x <# 3#) `orI#` (x ># 100#) `orI#` (x ==# 12#) `orI#` (x ==# 15#)) }}} I get (in 7.8.3 and in 7.9) {{{#!hs IsDigit.foo :: GHC.Prim.Int# -> GHC.Types.Bool [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType <S,1*U>, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (x3_a2if [Occ=Once!] :: GHC.Prim.Int#) -> case x3_a2if of wild_Xe { __DEFAULT -> GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.orI# (GHC.Prim.<# wild_Xe 3) (GHC.Prim.># wild_Xe 100)); 12 -> GHC.Types.True; 15 -> GHC.Types.True }}] IsDigit.foo = \ (x3_a2if :: GHC.Prim.Int#) -> case x3_a2if of wild_Xe { __DEFAULT -> GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.orI# (GHC.Prim.<# wild_Xe 3) (GHC.Prim.># wild_Xe 100)); 12 -> GHC.Types.True; 15 -> GHC.Types.True }}} and branching assembly to match. Jan Stolarek indicates this is probably a problem with constant folding. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9661> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #10365: Make Semigroup as a superclass of Monoid
by GHC 07 Sep '17

07 Sep '17

#10365: Make Semigroup as a superclass of Monoid -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- See http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a -superclass-of-Monoid-td5767835.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10365> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 45

[GHC] #9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types
by GHC 06 Sep '17

06 Sep '17

#9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When we see `m >>= (\_ -> n)` with a type that admits an optimized `>>` or `<$`, we should try to take advantage of that. I don't currently know if this applies to any types under "GHC HQ" control. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9797> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10328: Control.Monad exports lead to weird Haddocks
by GHC 06 Sep '17

06 Sep '17

#10328: Control.Monad exports lead to weird Haddocks -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Core | Operating System: Unknown/Multiple Libraries | Type of failure: Documentation Keywords: | bug Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `Control.Monad` exports, and therefore documents, the `Functor` class (but only the `fmap` member) and the `Monad` class. It does not export, and therefore does not document, the `Applicative` class. This is all pretty weird. Since `Functor` is in the prelude (and probably most/all alternate preludes), is there actually a reason to export it from `Control.Monad`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10328> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4