December 2018 - ghc-tickets

[GHC] #12953: Use computed gotos in the interpreter when the compiler supports it
by GHC 22 Jan '19

22 Jan '19

#12953: Use computed gotos in the interpreter when the compiler supports it -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: interpreter | 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: -------------------------------------+------------------------------------- We can use computed gotos to speed up the interpreter on systems that support them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12953> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14475: Upload documentation dumps
by GHC 22 Jan '19

22 Jan '19

#14475: Upload documentation dumps -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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: -------------------------------------+------------------------------------- Having a nightly job that would update https://downloads.haskell.org/~ghc/master/users-guide/ would be lovely. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14475> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9251: ghc does not expose brancheless max/min operations as primops
by GHC 21 Jan '19

21 Jan '19

#9251: ghc does not expose brancheless max/min operations as primops ------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9246 | ------------------------------------+------------------------------------- It was pointed out in #9246 that GHC currently does not expose primops for Max and Min on various unlifted types such as Float# and Double# and Int# and Word#, but that on most modern CPU architectures there is instruction level support for these operations. (Eg, Float# and #Double min and max can be provided on any 64bit x86 system pretty easily ) This ticket is to track doing that task. I'll probably do it one of the next two weekends to get back in the GHC hacking groove, or maybe this should be used as a "getting started" ticket for a new contributor? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[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] #15726: Don't include Haskeline (and others) in the global package DB
by GHC 19 Jan '19

19 Jan '19

#15726: Don't include Haskeline (and others) in the global package DB -------------------------------------+------------------------------------- Reporter: judah | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | Version: 8.6.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: -------------------------------------+------------------------------------- GHC installations include `haskeline` in their global DB, as well as its dependencies (currently: `stm` and `terminfo`). However, Haskeline isn't a dependency of the `ghc` library, so that shouldn't be necessary. Originally suggested by hvr here, in response to needing to pull `stm` into the global DB: https://github.com/judah/haskeline/pull/61#issuecomment-294878302 This change would let Haskeline add dependencies more easily. See in particular the pending PR to depend on the "exceptions" package: https://github.com/judah/haskeline/pull/97 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15726> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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