November 2018 - ghc-tickets

[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

[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] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux
by GHC 18 Jan '19

18 Jan '19

#15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux ---------------------------------+---------------------------------------- Reporter: pkubaj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc64 | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+---------------------------------------- I'd like to bootstrap GHC for FreeBSD/powerpc64, but GHC seems to be supported only on Linux for powerpc64 architecture. Relevant code: https://github.com/ghc/ghc/blob/1c2c2d3dfd4c36884b22163872feb87122b4528d/rt… https://github.com/ghc/ghc/blob/1c2c2d3dfd4c36884b22163872feb87122b4528d/rt… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15916> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 46

[GHC] #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs
by GHC 18 Jan '19

18 Jan '19

#15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | 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 are investigating various ways to make `for_` and `traverse_` not leak space by changing the type signature from `(a -> f b) -> t a -> f ()` to `(a -> f ()) -> t a -> f ()`. While doing so, we noticed a regression from GHC 8.2.2 to 8.4.3 and 8.6.1. The code: https://gist.github.com/nh2/b8f9f8e60443bdb30c1cd7e0acb8c8eb/bb1cc1a4987091… Run against 3 different GHC releases: {{{ # 8.2.2 stack --resolver lts-11.22 ghc -- --make -O2 -rtsopts ./TraverseMaybePerformance.hs && /usr/bin/time ./TraverseMaybePerformance 8 +RTS -sstderr 460,309,368 bytes allocated in the heap # 8.4.3 stack --resolver lts-12.11 ghc -- --make -O2 -rtsopts ./TraverseMaybePerformance.hs && /usr/bin/time ./TraverseMaybePerformance 8 +RTS -sstderr 860,301,736 bytes allocated in the heap # 8.6.1 stack --resolver nightly-2018-10-06 ghc -- --make -O2 -rtsopts ./TraverseMaybePerformance.hs && /usr/bin/time ./TraverseMaybePerformance 8 +RTS -sstderr 860,301,784 bytes allocated in the heap }}} Allocations doubled starting with 8.4. All was run on Ubuntu 16.04 64-bit. We haven't investigated in detail yet (also whether it's a GHC or libraries problem) since we're actually trying to do something else and this came out on the side, but it looks important enough to share already. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15717> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15813: -Wredundant-constrains emits warning even if constraint is narrowing type
by GHC 18 Jan '19

18 Jan '19

#15813: -Wredundant-constrains emits warning even if constraint is narrowing type -------------------------------------+------------------------------------- Reporter: jvanbruegge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect (amd64) | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am not sure if this is the same as #12700 , but when having a constraint that uses type equality to narrow down a type, -Wredundant-constraints still emits the warning. My particular example is: {{{#!hs class RowCons (label :: Symbol) (ty :: k) (tail :: Row k) (row :: Row k) | label row -> ty tail, label ty tail -> row instance (RowDelete s r ~ tail, RowPrepend s ty tail ~ r) => RowCons s ty tail r get :: forall s ty t r. RowCons s ty t r => Record r -> Proxy s -> ty get _ _ = undefined test_rec = get (Proxy :: Record ('Cons "foo" '[String]) (Proxy :: Proxy "foo") }}} With the RowCons constraint, the inferred type of test_rec is String (or [Char]), but without it it is an ambiguous `ty`. If the implementation of the type classes is needed, they can be found here: https://github.com/jvanbruegge/Megarecord/blob/f65fa5f29dc393e32d42fc878724… I tested this with 8.6.1 and 8.4.3 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15813> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3