January 2018 - ghc-tickets

[GHC] #10972: Add a :binfo (beginner info) GHCi command
by GHC 16 Jan '18

16 Jan '18

#10972: Add a :binfo (beginner info) GHCi command -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 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: #10963 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From goldfire: > Add a new command to GHCi, :binfo (for "beginner info") (please suggest a better name) that is like :info but presents different information. It suppresses in-scope instances, but attempts to specialize a function's type and presents specializations, using heuristics. So when we say :binfo find, we'll see Foldable t => (a -> Bool) -> t a -> Maybe a but also (a -> Bool) -> [a] -> Maybe a. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10972> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13647: Tidy up TcTypeable
by GHC 16 Jan '18

16 Jan '18

#13647: Tidy up TcTypeable -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is code in `TcTypeable` that generates a `KindRep` for each `TyCon` (see `Note [Representing TyCon kinds: KindRep]`). There's nothing actually wrong with it. But it's pretty hard to understand. And it generates a staggering amount of data structure, when compiling `GHC.Types`. {{{ Result size of Tidy Core = {terms: 74,615, types: 41,335, coercions: 2, joins: 0/0} }}} Why? Well, it injects a `TyCon` binding for each unboxed tuple size. For example, here is the code for pairs `(#,#)` {{{ $tc(#,#) = TyCon 16533601304077481746## 7902994497850328874## tr$ModuleGHCPrim $tc(#,#)2 2# $tc(#,#)1 -- TYPE #0 -> TYPE #1 -> TYPE (TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep)))) $tc(#,#)1 :: KindRep $tc(#,#)1 = KindRepFun $krep2115_r6ji $krep18009_rarE $krep18009_rarE = KindRepFun $krep2117_r6jk $krep18008_rarD -- TYPE (TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep)))) $krep18008_rarD = KindRepTyConApp $tcTYPE $krep18007_rarC $krep18007_rarC = : @ KindRep $krep18006_rarB ([] @ KindRep) -- TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep))) $krep18006_rarB = KindRepTyConApp $tc'TupleRep $krep18005_rarA $krep18005_rarA = : @ KindRep $krep2283_r6m0 ([] @ KindRep) -- ': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep)) $krep2283_r6m0 = KindRepTyConApp $tc': $krep2282_r6lZ $krep2282_r6lZ = : @ KindRep $tc'AddrRep1 $krep2281_r6lY $krep2281_r6lY = : @ KindRep $krep61_r5Ma $krep2280_r6lX $krep2280_r6lX = : @ KindRep $krep2279_r6lW ([] @ KindRep) -- ': RuntimeRep #1 ('[] RuntimeRep) $krep2279_r6lW = KindRepTyConApp $tc': $krep2278_r6lV $krep2278_r6lV = : @ KindRep $tc'AddrRep1 $krep2277_r6lU $krep2277_r6lU = : @ KindRep $krep60_r5M9 $krep2276_r6lT $krep2276_r6lT = : @ KindRep $krep2274_r6lR ([] @ KindRep) -- '[] RuntimeRep $krep2274_r6lR = KindRepTyConApp $tc'[] $krep2273_r6lQ $krep2273_r6lQ = : @ KindRep $tc'AddrRep1 ([] @ KindRep) -- RuntimeRep $tc'AddrRep1 = KindRepTyConApp $tcRuntimeRep ([] @ KindRep) -------------- TYPE #0 $krep2115_r6ji = KindRepTyConApp $tcTYPE $krep2114_r6jh $krep2114_r6jh = : @ KindRep $krep61_r5Ma ([] @ KindRep) $krep61_r5Ma = KindRepVar 0# -------------- TYPE #1 $krep2117_r6jk = KindRepTyConApp $tcTYPE $krep2116_r6jj $krep2116_r6jj = : @ KindRep $krep60_r5M9 ([] @ KindRep) $krep60_r5M9 = KindRepVar 1# }}} That's a lot, and it's only for pairs. We generate all this up to 62-tuples! Suggestions (read `Note [Representing TyCon kinds: KindRep]` first) * `KindRep` is a description of a polykind; an interpreter, called `instantiateKindRep` turns it into a kind. So we can add whatever constructors we like to `KindRep`. * One good one would be `UnboxedTupleRep n`, which `instantiateKindRep` can instantiate to the kind of an unboxed tuple. It just moves the work somewhere else, of course, but it will make the generated code dramatically smaller. * We have a few canned kind-reps, via `TcTypeable.builtInKindReps`. It'd be simpler and easier instead to make each of them into a data constructor of `KindRep`. * Once that is done, I suspect that the entire machinery of tyring to share `KindReps` (which makes my head hurt) would be unnecessary None of this is essential, but I think that matters can be improved. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14663: Deriving Typeable for enumerations seems expensive
by GHC 16 Jan '18

16 Jan '18

#14663: Deriving Typeable for enumerations seems expensive -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 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 have a module `A10000` that looks like this: {{{ module A10000 where data A = A | A00001 | A00002 ... | A10000 }}} Currently compiling it with `./inplace/bin/ghc-stage2 A10000.hs +RTS -s` produces: {{{ [1 of 1] Compiling A10000 ( A10000.hs, A10000.o ) 4,133,470,392 bytes allocated in the heap 1,194,866,080 bytes copied during GC 141,604,816 bytes maximum residency (14 sample(s)) 813,104 bytes maximum slop 341 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 329 colls, 0 par 0.551s 0.551s 0.0017s 0.0246s Gen 1 14 colls, 0 par 0.453s 0.453s 0.0323s 0.1031s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.000s ( 0.000s elapsed) MUT time 1.498s ( 1.730s elapsed) GC time 1.004s ( 1.004s elapsed) EXIT time 0.000s ( 0.006s elapsed) Total time 2.502s ( 2.740s elapsed) Alloc rate 2,759,911,143 bytes per MUT second Productivity 59.9% of total user, 63.4% of total elapsed }}} I've noticed a lot of code getting generated (>500k lines of ASM), particularly interesting was code that supported `TyCon`s. I've tried again disabling the generation of `TyCon`s by modifying: {{{ mkTypeRepTodoBinds :: [TypeRepTodo] -> TcM TcGblEnv mkTypeRepTodoBinds _ = getGblEnv }}} This is the result: {{{ [1 of 1] Compiling A10000 ( A10000.hs, A10000.o ) 1,731,693,280 bytes allocated in the heap 280,362,376 bytes copied during GC 41,423,608 bytes maximum residency (10 sample(s)) 746,272 bytes maximum slop 102 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 401 colls, 0 par 0.111s 0.111s 0.0003s 0.0065s Gen 1 10 colls, 0 par 0.124s 0.124s 0.0124s 0.0298s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.000s ( 0.000s elapsed) MUT time 0.773s ( 0.889s elapsed) GC time 0.235s ( 0.235s elapsed) EXIT time 0.000s ( 0.007s elapsed) Total time 1.008s ( 1.130s elapsed) Alloc rate 2,241,052,377 bytes per MUT second Productivity 76.7% of total user, 79.2% of total elapsed }}} It appears that by default I pay >50% of compile time for a feature that I probably won't use. I'm sorry if this is a duplicate, I've looked at https://ghc.haskell.org/trac/ghc/wiki/Typeable, but nothing seemed relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14663> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14569: refutable let bindings produce "irrefutable pattern failed" errors
by GHC 16 Jan '18

16 Jan '18

#14569: refutable let bindings produce "irrefutable pattern failed" errors -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In ghc-8.2.2 (probably since ghc-8.0.1), strict pattern matches in let bindings produce "Irrefutable pattern failed" errors. {{{#!hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Prelude> :set -XBangPatterns Prelude> let ![] = [1] in 1 *** Exception: <interactive>:2:5-13: Irrefutable pattern failed for pattern [] }}} In ghc-7.10.2, normal pattern match failures were produced. {{{#!hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> :set -XBangPatterns Prelude> let ![] = [1] in 1 *** Exception: <interactive>:3:5-13: Non-exhaustive patterns in pattern binding }}} To my mind, the latter error makes much more sense; the effect of the ! is to make the pattern an ordinary, refutable one. Could the old behavior be restored? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14569> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14611: Support LIBRARY_PATH and LD_LIBRARY_PATH in rts
by GHC 16 Jan '18

16 Jan '18

#14611: Support LIBRARY_PATH and LD_LIBRARY_PATH in rts -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.2.2 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To complement the C compiler's usage of these, the Haskell runtime loader should use `LD_LIBRARY_PATH` to load shared libraries and the linker should use `LIBRARY_PATH` to find libraries. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14456: Windows runtime linker failure with icuuc
by GHC 16 Jan '18

16 Jan '18

#14456: Windows runtime linker failure with icuuc -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First, install `mingw-w64-x86_64-icu` (I'm using version 58.2-2): {{{ $ pacman -S mingw-w64-x86_64-icu }}} Now take this file: {{{#!hs module Main where import Data.Int import Foreign foreign import ccall "ucnv_getMaxCharSize_58" c_ucnv_getMaxCharSize :: Ptr () -> IO Int8 main :: IO () main = c_ucnv_getMaxCharSize nullPtr >>= print }}} GHC is able to compile this successfully: {{{ $ ghc -licuuc Bug2.hs [1 of 1] Compiling Main ( Bug2.hs, Bug2.o ) Linking Bug2.exe ... }}} But GHCi is unable to accomplish the same thing: {{{ $ runghc -licuuc Bug2.hs ghc.exe: ^^ Could not load 'ucnv_getMaxCharSize_58', dependency unresolved. See top entry above. Bug2.hs: ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: ucnv_getMaxCharSize_58 This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} Phyx- and I discussed this briefly on IRC. He suspected that the fact that `C:\Windows\System32` now contains its own copy of `icuuc.dll` is contributing to the issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14456> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7206: Implement cheap build
by GHC 16 Jan '18

16 Jan '18

#7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763, #13422 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #8763 => #8763, #13422 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7206#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2)
by GHC 16 Jan '18

16 Jan '18

#14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: | Version: 8.2.1 libraries/base | 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: | prime:Libraries/Proposals/SemigroupMonoid -------------------------------------+------------------------------------- More details in prime:Libraries/Proposals/SemigroupMonoid -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14191> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

Re: [GHC] #5620: Dynamic linking and threading does not work on Windows
by GHC 16 Jan '18

16 Jan '18

#5620: Dynamic linking and threading does not work on Windows -------------------------------------+------------------------------------- Reporter: Lennart | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.2.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #10352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: This won't happen this release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5620#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9285: IO manager startup procedure somewhat odd
by GHC 16 Jan '18

16 Jan '18

#9285: IO manager startup procedure somewhat odd ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: low | Milestone: 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: | ------------------------------------+------------------------------------- Currently the RTS startup procedure for the threaded runtime with a single capability looks something like this: '''1. Capability gets initialized''' {{{ hs_main real_main hs_init_ghc initScheduler initCapabilities }}} '''2. IO Manager is started''' {{{ hs_main real_main hs_init_ghc ioManagerStart }}} '''3. ensureIOManagerIsRunning''' The IO manager of course is mostly written in Haskell, so `ioManagerStart` does {{{ cap = rts_lock(); rts_evalIO(&cap,&base_GHCziConcziIO_ensureIOManagerIsRunning_closure,NULL); rts_unlock(cap); }}} '''4. Bound task is created and we start running Haskell code''' Since this is the first call to `rts_lock`, it creates a bound task to correspond to the current OS thread. '''5. Haskell code does a safe FFI call: create worker task 1''' The first safe FFI call that the IO manager makes (ignoring `labelThread`) is to `c_setIOManagerControlFd`. At this point, the bound task gets suspended and we create a worker task. '''6. Worker task 1 starts executing `GHC.Event.Manager.loop`''' The worker tasks gets suspended due to an explicit call to `yield` in `GHC.Event.Manager.step`, at which point the bound task continues execution. It continues and finishes (`ensureIOManagerRunning` completes). The worker task takes over. '''7. Worker task 1 does a safe FFI call to `I.poll`, create new worker task 2''' (This safe call is from `GHC.Event.Manager.step`) '''8. Worker task 2 executes `GHC.Event.TimerManager.loop`, and does safe FFI call to `I.poll`; create worker task 3''' This worker task will remain spare for now. '''9. Start executing the actual main function''' The IO manager calls `rts_unlock`, which verifies if there are any spare workers available; it finds that there are and doesn't start a new one. Then when we start `main` itself of course we go through this `rts_lock, rts_evalIO, rts_unlock` sequence ''again''. This is somewhat confusing, and makes tracing the startup of the code more difficult to interpret. It seems that this could be simpler: only a single `rts_lock` should be necessary, in which we first call `ensureIOManagerIsRunning` and then `main`, followed by a single `rts_unlock`. A similar simplification should be possible in `forkProcess`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9285> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7