March 2017 - ghc-tickets

[GHC] #9718: Avoid TidyPgm predicting what CorePrep will do
by GHC 10 Dec '18

10 Dec '18

#9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At the moment the `TidyPgm` pass is forced to predict, accurately but unpleasantly, some aspects of what `CorePrep` and `Core2Stg` will do. Reason: * Each `Id` in the interface file records (among other things) the '''arity''' of the `Id`, and whether it has '''CAF references''' * We really only know these two things for sure after `CorePrep`. The conversion from Core to STG makes no structural changes. * However the result of `TidyPgm` (which preceded `CorePrep`) is used to generate the interface file. So it has to predict the arity and CAF-ref status of each `Id`. * This is not good. It restricts what `CorePrep` can do (notably, it must not change the arity of a top-level `Id`), and it leads to unsavoury code (e.g. look at the call to `CorePrep.cvtLitInteger` in `TidyPgm.cafRefsL`. It's also dangerous: an inconsistency could lead to a crash. This is a long-standing problem. My current thought for how to unravel it is this: * `TidyPgm` does not attach arity or CAF-ref info. * Instead, run `CorePrep` after `TidyPgm`, and generate accurate arity and CAF-ref info * Then use that auxiliary mapping during the conversion from tidied program to `ModIface`. I don't think this would be hard. It would mean that the tidied program and the core-prep'd program would have to exist in memory at the same time. An alternative would be to generate the `ModIface` from the tidied program ''sans'' arity and CAF-ref info, and then, after `CorePrep` run over it to add arity and CAF-ref info. (You'd have to do this before generating the fingerprints.) The advantage of this is that the `ModIface` can be a lot smaller than the code for the entire module. A long-standing wart which needs some careful attention. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 42

[GHC] #12893: Profiling defeats stream fusion when using vector library
by GHC 09 Dec '18

09 Dec '18

#12893: Profiling defeats stream fusion when using vector library -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: stream-fusion | Operating System: MacOS X profiling | Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have this problem where enabling profiling in Haskell undoes stream fusion and I’d like to do my profiling with stream fusion intact. The following reproduces my problem: {{{ $ git clone git@github.com:haskell-works/hw-tutorial-performance.git $ cd hw-tutorial-performance/ $ stack init $ stack build --executable-profiling $ time $(find .stack-work/dist/ -type f -name hw-tutorial-performance- rwhe) 1e7 5000000.5 real 0m4.432s user 0m3.484s sys 0m0.936s $ rm -rf .stack-work/ $ stack build $ time $(find .stack-work/dist/ -type f -name hw-tutorial-performance- rwhe) 1e7 5000000.5 real 0m0.034s user 0m0.018s sys 0m0.013s With profiling, my program takes over 4 seconds to run. Without profiling, it only takes 0.034 seconds. }}} The problem has nothing to do with stack. {{{ (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ ghc -fforce-recomp --make -O2 -funbox-strict-fields -rtsopts -optc-O2 Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ time ./Main +RTS -sstderr -RTS 1e7 5000000.5 115,888 bytes allocated in the heap 3,480 bytes copied during GC 44,384 bytes maximum residency (1 sample(s)) 17,056 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.000s 0.005s 0.0049s 0.0049s INIT time 0.000s ( 0.002s elapsed) MUT time 0.010s ( 0.025s elapsed) GC time 0.000s ( 0.005s elapsed) EXIT time 0.000s ( 0.005s elapsed) Total time 0.012s ( 0.037s elapsed) %GC time 1.8% (13.1% elapsed) Alloc rate 11,904,262 bytes per MUT second Productivity 97.1% of total user, 31.2% of total elapsed real 0m0.057s user 0m0.012s sys 0m0.010s (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ ghc -prof -fforce-recomp --make -O2 -funbox-strict-fields -rtsopts -optc-O2 Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ time ./Main +RTS -sstderr -RTS 1e7 5000000.5 3,012,099,000 bytes allocated in the heap 4,079,698,408 bytes copied during GC 1,162,199,352 bytes maximum residency (13 sample(s)) 19,313,368 bytes maximum slop 1990 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 4869 colls, 0 par 1.046s 1.055s 0.0002s 0.0017s Gen 1 13 colls, 0 par 1.230s 1.960s 0.1508s 0.5764s INIT time 0.000s ( 0.004s elapsed) MUT time 0.963s ( 0.825s elapsed) GC time 2.276s ( 3.016s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.009s ( 0.185s elapsed) Total time 3.251s ( 4.029s elapsed) %GC time 70.0% (74.8% elapsed) Alloc rate 3,126,345,026 bytes per MUT second Productivity 30.0% of total user, 24.2% of total elapsed real 0m4.197s user 0m3.251s sys 0m0.883s }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12893> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8109: Type family patterns should support as-patterns.
by GHC 09 Dec '18

09 Dec '18

#8109: Type family patterns should support as-patterns. ------------------------------------+------------------------------------- Reporter: carlhowells | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I recently wrote code similar to the following: {{{ {-# LANGUAGE DataKinds, ScopedTypeVariables, TypeOperators, TypeFamilies #-} {-# LANGUAGE PolyKinds, FlexibleInstances, FlexibleContexts #-} import GHC.TypeLits data P n = P fromNat :: forall (p :: Nat -> *) (n :: Nat). SingI n => p n -> Integer fromNat _ = fromSing (sing :: Sing n) class C (a :: [Nat]) where type T a :: * val :: p a -> T a instance SingI n => C '[n] where type T '[n] = Integer val _ = fromNat (P :: P n) instance (SingI n, C (n2 ': ns)) => C (n ': n2 ': ns) where type T (n ': n2 ': ns) = (Integer, T (n2 ': ns)) val _ = (fromNat (P :: P n), val (P :: P (n2 ': ns))) }}} There were semantic constraints in my case that made an empty list nonsensical, so it wasn't an appropriate base case. But the resulting effort in ensuring type family patterns didn't overlap got unwieldy. I would have much preferred to write that second instance more like this: {{{ instance (SingI n, C ns) => C (n ': ns@(_ ': _)) where type T (n ': ns) = (Integer, T ns) val _ = (fromNat (P :: P n), val (P :: P ns)) }}} The reasoning here is identical to as-patterns in value-level pattern matching. If you only want to match an expression when it has a particular sub-structure, it's way more convenient to do it with an as-pattern. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8109> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12126: Bad error messages for SPECIALIZE pragmas
by GHC 09 Dec '18

09 Dec '18

#12126: Bad error messages for SPECIALIZE pragmas -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Specialize, | Operating System: Unknown/Multiple ErrorMessages | Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When playing with SPECIALIZE pragmas, I've encountered one large problem with the error messages, and two minor ones. 1. Given a function with a `Num` constraint, applying `SPECIALIZE` at a non-function type triggers defaulting incorrectly; the code {{{#!hs f1 :: Num a => a -> a f1 x = x + x {-# SPECIALIZE f1 :: Bool #-} }}} produces the error {{{ …/Test1.hs:5:1: error: • Couldn't match expected type ‘Integer -> Integer’ with actual type ‘Bool’ • In the SPECIALISE pragma {-# SPECIALIZE f1 :: Bool #-} }}} (This is in the attached file `Test1.hs`.) 2. Given a function, applying `SPECIALIZE` at a well-formed type without the looked-for instance produces an error with some extra text (the first line ends with "a SPECIALISE pragma for ‘f2’", even though this is repeated on the next line); the code {{{#!hs f2 :: Num a => a -> a f2 x = x + x {-# SPECIALIZE f2 :: Bool -> Bool #-} }}} produces the error {{{ …/Test2.hs:5:1: error: • No instance for (Num Bool) a SPECIALISE pragma for ‘f2’ • In the SPECIALISE pragma {-# SPECIALIZE f2 :: Bool -> Bool #-} }}} (This is in the attached file `Test2.hs`.) 3. This is minor, but: both of these error messages talk about a `SPECIALISE` pragma when I wrote a `SPECIALIZE` pragma. Even more so, case is not preserved in the quoted pragma; if I provide a {{{#!hs {-# specialize … #-} }}} pragma, the error message ends with {{{ • In the SPECIALISE pragma {-# SPECIALIZE … #-}`. }}} even though that isn't what I wrote. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13165: Speed up the RTS hash table
by GHC 09 Dec '18

09 Dec '18

#13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.1 System | 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 RTS hash table is rather slow. Every lookup involves at least one indirect call (to get a hash code). It also uses separate chaining, which is itself slow. Until recently, this didn't really matter, since the RTS hash table wasn't used for anything particularly performance critical other than `StablePtr` operations. However, it has since become the bottleneck when compacting with sharing, to the point that compacting without sharing is around 10x faster and is thus the default. Fortunately, there are easy ways to make the hash table faster. These include: - Use linear probing instead of separate chaining. - Specialize for the case of pointer keys - Don't use indirect calls for hashing - Use a fast, universal hash function for pointers. - Use SSE instructions where available to do fast searches. - Minimize the number of indirections in the use of the table. In both the case of the StablePtr table and that of compact regions, the keys of the table are not GC pointers, but the values are, so there needs to be a way to ensure that the GC handles the table correctly -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13165> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #13104: runRW# ruins join points
by GHC 06 Dec '18

06 Dec '18

#13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Found this while poking around in the example for #12781. Suppose we have code like this: {{{ let loop :: Int -> State# RealWorld -> (State# RealWorld, Int) loop n = ... loop (n+1) {- tail call -} ... in runRW# @ 'PtrRepLifted @ Int (loop 0) }}} We would love for `loop` to be a join point, but it can't be because it's invoked in the argument to `runRW#`. In this situation, we're often rescued by Float In, which we might hope to give us this: {{{ runRW# @ 'PtrRepLifted @ Int ( let loop :: Int -> State# RealWorld -> (State# RealWorld, Int) loop n s = ... loop (n+1) s' {- tail call -} ... in loop 0 ) }}} Two problems: 1. Float In won't do this to begin with because `loop 0` is a partial application. 2. It's still not eligible to be a join point, again because `loop 0` is a partial application. What we would //like// to see is this: {{{ runRW# @ 'PtrRepLifted @ Int ( \s0 -> let loop :: Int -> State# RealWorld -> (State# RealWorld, Int) loop n s = ... loop (n+1) s' {- tail call -} ... in loop 0 s0 ) }}} Now we're golden. But someone has to have thought to eta-expand the argument to `runRW#` first. (Float In should then float `loop` into the lambda because, due to the state hack, the lambda is considered one-shot.) Perhaps the simplifier should //always// eta-expand the argument to `runRW#`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13104> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #12088: Promote data family instance constructors
by GHC 06 Dec '18

06 Dec '18

#12088: Promote data family instance constructors -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #11348 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `TcEnv.hs` there is a note AFamDataCon: not promoting data family constructors. It states that we can't use a promoted data family instance constructor because we would have to interleave the checking of instances and data types. But with the fix of #11348, we now do exactly this. In the example from the note {{{#!hs data family T a data instance T Int = MkT data Proxy (a :: k) data S = MkS (Proxy 'MkT) }}} -ddump-rn-trace shows these groups {{{ rnTycl dependency analysis made groups [[data family T a_apG] [] [data instance T Int = MkT], [data Proxy (a_apF :: k_apE)] [] [], [data S = MkS (Proxy MkT)] [] []] }}} That's to say, the instance `T Int` will in fact be checked before `S`. So let's remove this restriction. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12088> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 53

[GHC] #9091: print and/or apply constraints when showing info for typed holes
by GHC 05 Dec '18

05 Dec '18

#9091: print and/or apply constraints when showing info for typed holes -------------------------------------------+------------------------------- Reporter: kosmikus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | 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: -------------------------------------------+------------------------------- Typed holes are fantastic already, but could be even better. Consider the following three examples: == Example 1 == {{{ f :: Eq a => a -> a -> Bool f x y = _ }}} GHC-7.8.2 shows: {{{ Found hole ‘_’ with type: Bool Relevant bindings include y :: a (bound at THC.hs:4:5) x :: a (bound at THC.hs:4:3) f :: a -> a -> Bool (bound at THC.hs:4:1) In the expression: _ In an equation for ‘f’: f x y = _ }}} GHC additionally knows that `Eq a` holds. It would be great if it would print that, too. == Example 2 == {{{ g :: (forall a. Eq a => a -> Bool) -> Bool g f = f _ }}} GHC-7.8.2 shows: {{{ Found hole ‘_’ with type: a0 Where: ‘a0’ is an ambiguous type variable Relevant bindings include f :: forall a. Eq a => a -> Bool (bound at THC.hs:7:3) g :: (forall a. Eq a => a -> Bool) -> Bool (bound at THC.hs:7:1) In the first argument of ‘f’, namely ‘_’ In the expression: f _ In an equation for ‘g’: g f = f _ }}} GHC additionally knows the `Eq a0` must hold. It would be nice if it could indicate that. == Example 3 == {{{ data X a where Y :: X Int h :: X a -> a -> a h Y x = _ }}} GHC-7.8.2 shows: {{{ Found hole ‘_’ with type: Int Relevant bindings include x :: a (bound at THC.hs:13:5) h :: X a -> a -> a (bound at THC.hs:13:1) In the expression: _ In an equation for ‘h’: h Y x = _ }}} Interestingly, GHC shows that we have to produce an `Int`. Unfortunately, it shows that `x` is of type `a`. GHC additionally knows that `a ~ Int`. It would be nice if GHC could either apply the constraint to show that `x :: Int` or at least show the constraint. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9091> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13480: GHCi display visible type application
by GHC 05 Dec '18

05 Dec '18

#13480: GHCi display visible type application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | 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: #8751 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Similar to #8751, have a way to get GHCi to dump which types an expression is applied to: {{{ ghci> :tyapp length [1,2,3] length @[] @Integer [1,2,3] }}} It could also function as the [https://downloads.haskell.org/~ghc/master /users-guide/ghci.html#ghci-cmd-:all-types :all-types], [https://downloads.haskell.org/~ghc/master/users-guide/ghci.html#ghci-cmd -:type-at :type-at] commands where we can specify a region of code (from [https://www.researchgate.net/publication /282487445_Combining_Deep_and_Shallow_Embedding_of_Domain- Specific_Languages?ev=pubitem-pub_cit_inc Combining Deep and Shallow Embedding of Domain-Specific Languages]) {{{#!hs fromFunC :: FunC (m (Internal a)) -> Mon m a fromFunC m = M $ \k -> fromFunC Bind m k }}} displays {{{#!hs fromFunC :: FunC (m (Internal a)) -> Mon m a fromFunC m = M @m @a $ \(k :: a -> FunC (m b)) -> fromFunC @(FunC (m (Internal a)) -> (a -> FunC (m b)) -> FunC (m b)) (Bind @m @(Internal a) @b) m k }}} Would be great to get this feature as an IDE support. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13480> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13064: Incorrect redudant imports warning
by GHC 05 Dec '18

05 Dec '18

#13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With a simple package: issue.cabal: {{{ name: issue version: 0 cabal-version: >= 1.10 build-type: Simple library build-depends: base, binary, binary-orphans==0.1.5.2 exposed-modules: Issue }}} Issue.hs: {{{ {-# LANGUAGE DeriveGeneric #-} {-# OPTIONS_GHC -Wall #-} module Issue (T (..)) where import Prelude () import Data.Binary.Orphans import Data.Binary (Binary (..)) import GHC.Generics (Generic) import Data.Aeson (Value) data T = T Value deriving (Generic) instance Binary T }}} GHC 7.10.3 correctly reports: {{{ Issue.hs:7:1: Warning: The import of ‘Data.Binary’ is redundant except perhaps to import instances from ‘Data.Binary’ To import instances alone, use: import Data.Binary() }}} GHC 8.0.1 incorrectly (!!!) reports: {{{ Issue.hs:6:1: warning: [-Wunused-imports] The import of ‘Data.Binary.Orphans’ is redundant except perhaps to import instances from ‘Data.Binary.Orphans’ To import instances alone, use: import Data.Binary.Orphans( }}} but `Binary Value` instance is imported from `Data.Binary.Orphans`. --- In real life while compiling https://github.com/futurice/haskell-mega- repo/blob/93c3f111f39c973769c35725d90c9b8ef9a57de3/futurice- github/src/Futurice/GitHub.hs the `Data.Binary` redundant import isn't reported, as `Futurice.Prelude` exports other stuff, which is used. See https://gist.github.com/phadej/bb26df19c611260ab8f867729def39b9 for minimal imports reported with `-ddump-minimal-imports`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 51