September 2018 - ghc-tickets

[GHC] #14670: -XRebindableSyntax needs return?
by GHC 21 Jan '19

21 Jan '19

#14670: -XRebindableSyntax needs return? -------------------------------------+------------------------------------- Reporter: jackkelly | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple RebindableSyntax | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The documentation for -XRebindableSyntax ( https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… #rebindable-syntax-and-the-implicit-prelude-import ) reads: > “Do” notation is translated using whatever functions (>>=), (>>), and fail, are in scope (not the Prelude versions). List comprehensions, mdo (The recursive do-notation), and parallel array comprehensions, are unaffected. The following code fails to compile (also confirmed to fail on GHC 8.0.2): {{{ {-# LANGUAGE RebindableSyntax #-} module Lib where import Prelude (IO) foo :: IO () foo = do pure () }}} It fails with this error: {{{ /home/kel317/z/src/Lib.hs:9:3: error: Not in scope: ‘return’ Perhaps you want to add ‘return’ to the import list in the import of ‘Prelude’ (src/Lib.hs:5:1-19). | 9 | pure () | ^^^^^^^ }}} To my reading, either something funky is going on with the way the do- notation is desugared, or the documentation needs to be corrected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14670> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15613: GHCi command, tracing steps of instance resolution for Constraint or expression
by GHC 20 Jan '19

20 Jan '19

#15613: GHCi command, tracing steps of instance resolution for Constraint or expression -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: lowest | Milestone: Component: GHCi | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15610 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Another GHCi command (#15610) to trace the process of instance resolution for a constraint. This is already something people do by hand (ticket:10318#comment:6) and would be a great tool for explorers of Haskell This constraint ultimately boils down to lists being monoids and `Int` being a number {{{ >> :elab Monoid (a -> b -> ([c], Sum Int)) Monoid (a -> b -> ([c], Sum Int)) ==> Monoid (b -> ([c], Sum Int)) ==> Monoid ([c], Sum Int) ==> Monoid [c] ==> Monoid (Sum Int) ==> Num Int }}} If resolving the type class fails, it can pinpoint what caused it to fail {{{ >> data A >> :elab Show (A, Int -> Int) Show (A, Int -> Int) <~bRZsz NO instance~> ==> Show A <NO instance> ==> Show (Int -> Int) <NO instance> }}} A verbose version can explain each step {{{ >> :elab +v Monoid (a -> b -> ([c], Sum Int) Monoid (a -> b -> ([c], Sum Int)) -- Monoid b => Monoid (a -> b) (‘GHC.Base’) ==> Monoid (b -> ([c], Sum Int)) -- Monoid b => Monoid (a -> b) (‘GHC.Base’) ==> Monoid ([c], Sum Int) -- Monoid b => Monoid (a -> b) (‘GHC.Base’) ==> Monoid [c] -- Monoid [a] (‘GHC.Base’) ==> Monoid (Sum Int) -- Num a => Monoid (Sum a) (‘Data.Monoid’) ==> Num Int -- Num Int (‘GHC.Num’) }}} {{{ >> :elab +v Num (Int, Float, Rational) Num (Int, Float, Rational) -- (Num a, Num b, Num c) => Num (a, b, c) (‘Data.NumInstances.Tuple’) ==> Num Int -- Num Int (‘GHC.Num’) ==> Num Float -- Num Float (‘GHC.Float’) ==> Num Rational -- type Rational = Ratio Integer (‘GHC.Real’) = Num (Ration Integer) -- Integral a => Num (Ratio a) (‘GHC.Real’) ==> Integral Integer -- Integral Integer (‘GHC.Real’) }}} ---- Not the same idea but similar. Listing instance resolution that takes place in an expression {{{ >> :elab (+) @Int from: (+) @Int Num Int }}} {{{ >> :elab2 comparing (length @[]) <> compare from: length @[] Foldable [] from: comparing (length @[]) Ord Int from: comparing (length @[]) <> compare Monoid ([a] -> [a] -> Ordering) ==> Monoid ([a] -> Ordering) ==> Monoid Ordering }}} {{{ >> :elab2 ask 'a' from: ask 'a' MonadReader Char ((->) m) ==> MonadReader Char ((->) Char) }}} not sure about that last one, or how to visualize them but I think it gives the right idea. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15613> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14193: Add RTS flag to disable 1TB address space allocaiton
by GHC 20 Jan '19

20 Jan '19

#14193: Add RTS flag to disable 1TB address space allocaiton -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9706, #14192 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.0 changed the default behaviour on Linux to allocate 1 TB virtual memory for Haskell programs (#9706). While shown to be good for performance (a small percentage gain), it has created me a couple problems, especially when: * trying to disable overcommit in Linux to get more reliable memory behaviour and avoid swapping / the OOM-killer (all Haskell programs crash at startup) * and in debugging (e.g. #14192) Currently you can turn that feature off only via a compile-time switch, e.g. `./configure --disable-large-address-space`. I'd like to request to make it possible to turn this behaviour off at run- time with an RTS flag, so that when the flag is given, it uses the old block-allocator. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14193> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #14420: Data families should not instantiate to non-Type kinds
by GHC 19 Jan '19

19 Jan '19

#14420: Data families should not instantiate to non-Type kinds -------------------------------------+------------------------------------- Reporter: goldfire | 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: -------------------------------------+------------------------------------- {{{#!hs data family Any :: k -- allowable now due to fix for #12369 type family F (a :: Bool) :: Nat where F True = 0 F False = 1 F Any = 2 }}} {{{ ghci> :kind! F True F True :: Nat = 0 ghci> :kind! F False F False :: Nat = 1 ghci> :kind! F Any F Any :: Nat = 2 }}} Oh dear. We should require that any instantiation of a data family be to a kind that ends in `Type`. Inspired by comment:31:ticket:9429 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14420> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14976: WebAssembly support
by GHC 19 Jan '19

19 Jan '19

#14976: WebAssembly support -------------------------------------+------------------------------------- Reporter: sven | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Keywords: wasm, | Operating System: Unknown/Multiple webassembly | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I would like to suggest adding a wasm backend to GHC. PureScript is also offering something similar. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14976> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13452: Lock .tix file
by GHC 19 Jan '19

19 Jan '19

#13452: Lock .tix file -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Code Coverage | 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: -------------------------------------+------------------------------------- The HPC documentation [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.h… #caveats-and-shortcomings-of-haskell-program-coverage warns] that > HPC does not attempt to lock the `.tix` file, so multiple concurrently running binaries in the same directory will exhibit a race condition. This sounds like something that shouldn't be too terribly hard to fix, once we determine exactly how we want to deal with contention. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13452> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15381: Write documentation for iserv-proxy
by GHC 19 Jan '19

19 Jan '19

#15381: Write documentation for iserv-proxy -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- We merged `iserv-proxy` but it doesn't yet have users guide documentation. We should fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15381> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9279: Optimisation bug
by GHC 18 Jan '19

18 Jan '19

#9279: Optimisation bug ------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I have a strange problem with a local function binding that is not being inlined. I've attached the repro code, build it like this: {{{ $ ghc -O2 Haxl/Core/Monad.hs }}} There are several modules, but the one with the problem is `Haxl/Core/Monad.hs`. In particular `Haxl.Core.Monad.$fApplicativeGenHaxl2`, which contains this fragment: {{{ let { $wa4_s6YQ $wa4_s6YQ = \ w_s6YF _ ww1_s6YM _ _ w1_s6YI -> case GHC.Prim.readMutVar# ipv7_X5Ne w1_s6YI of _ { (# ipv10_X5QO, ipv11_X5QQ #) -> case ipv11_X5QQ of _ { Haxl.Core.Monad.IVarFull a2_a3kK -> case lvl6_r7qi of wild3_00 { }; Haxl.Core.Monad.IVarEmpty dt2_d4Vs -> case GHC.Prim.writeMutVar# ipv7_X5Ne (Haxl.Core.Monad.IVarFull w_s6YF) ipv10_X5QO of s2#_a5OR { __DEFAULT -> case GHC.Prim.readMutVar# dt2_d4Vs s2#_a5OR of _ { (# ipv12_X5R0, ipv13_X5R2 #) -> case GHC.Prim.readMutVar# ww1_s6YM ipv12_X5R0 of _ { (# ipv14_X5SS, ipv15_X5SU #) -> letrec { go_a5ti go_a5ti = \ ds10_a5tj -> case ds10_a5tj of _ { [] -> ipv15_X5SU; : y_a5to ys_a5tp -> GHC.Types.: (y_a5to w_s6YF) (go_a5ti ys_a5tp) }; } in case go_a5ti ipv13_X5R2 of x'_a5P6 { __DEFAULT -> case GHC.Prim.writeMutVar# ww1_s6YM x'_a5P6 ipv14_X5SS of s2#1_a5P7 { __DEFAULT -> (# s2#1_a5P7, Haxl.Core.Monad.cacheRequest6 #) } } } } } } } } in let { a2_s6lH a2_s6lH = \ w_s6YF _ w2_s6YH w3_s6YI -> case w2_s6YH of _ { Haxl.Core.Monad.SchedState ww1_s6YL ww2_s6YM ww3_s6YN ww4_s6YO -> $wa4_s6YQ w_s6YF ww1_s6YL ww2_s6YM ww3_s6YN ww4_s6YO w3_s6YI } } in }}} I want `$wa4` to be inlined at its single occurrence in `a2`. I believe the reason it is not being inlined is that `a2` is a wrapper, but the situation seems silly because the wrapper isn't going away either, so we have a redundant closure being built (this is in my inner loop). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #15606: Don't float out lets in between lambdsa
by GHC 18 Jan '19

18 Jan '19

#15606: Don't float out lets in between lambdsa -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 {{{ f = \x. let y = <blah> in \z. let v = h x y in <stuff> }}} The full laziness pass will float out that v-binding thus {{{ f = \x. let y = <blah> v = h x y in \z. <stuff> }}} And now (if `h` is, say, imported) it'll stay like that. But suppose `<blah>` simlifies to `Just x`. Then we allow ourselves to eta-expand thus {{{ f = \x z. let y = <blah> v = h x y in <stuff> }}} Now (an early design choice in the let-floater) we never float the v-binding in between the `\x` and `\z`. This is very non-confluent: a smal change in exactly how rapidly `<blah>` simplifies can have a big, irreversible effect on the code for `f`. IDEA: extend the let-floater's design choice to not float out between two lambdas, even if they are separated by lets/cases etc. One way to say this is to ask when a lambda gets a new level number compared to its immediately enclosing lambda. Examples where `y` gets the same level number as `x` * `\x.\y. blah` * `\x. let binds in \y` * `\x. case scrut of pi -> \y.blah` Examples where `y` gets the a level number one bigger than `x` * `\x. let v = \y.rhs in blah` * `\x. f (\y.rhs)` This probably won't make a lot of difference, but it'd be worth trying -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13851: Change in specialisation(?) behaviour since 8.0.2 causes 6x slowdown
by GHC 18 Jan '19

18 Jan '19

#13851: Change in specialisation(?) behaviour since 8.0.2 causes 6x slowdown -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- I was investigating some benchmarks and I noticed some odd results if I duplicated one of my tests. Reproduction: https://github.com/mpickering/probable-eureka Looking at the core, it seems that repeating the definition means that one of the key functions doesn't get specialised as expected which leads to a much slower program. Observe that in the first two benchmarks there is a worker function `go :: Int# -> Int -> ReaderT Int (StateT Int Identity Int` but in the third benchmark this is specialised to `$sgo :: Int# -> Int -> Int -> Int# -> Int# -> Identity (Int, Int)`. Removing the duplicate benchmark means that specialisation happens properly in the first case as well. The proper specialisation also happens in 8.0.2. This causes the first two cases to be 6x slower than the last case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13851> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12