November 2017 - ghc-tickets

[GHC] #12825: ghc panic on ppc64el, ghc 8.0.1, agda 2.5.1.1 patched for newer EdisonAPI
by GHC 21 Jan '18

21 Jan '18

#12825: ghc panic on ppc64el, ghc 8.0.1, agda 2.5.1.1 patched for newer EdisonAPI ---------------------------------+--------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+--------------------------------- {{{ [331 of 332] Compiling Agda.Interaction.EmacsTop ( src/full/Agda/Interaction/EmacsTop.hs, dist- ghc/build/Agda/Interaction/EmacsTop.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for powerpc64le-unknown-linux): applyTypeToArgs Expression: $w$cgmapQl2 stdin LineBuffering s_aJ4 Type: forall r_a2gyr r'_a2gys. (r_a2gyr -> r'_a2gys -> r_a2gyr) -> r_a2gyr -> (forall d_a2gyt. Data d_a2gyt => d_a2gyt -> r'_a2gys) -> [ModulePragma] -> ModuleName -> r_a2gyr Args: [stdin, LineBuffering, s_aJ4] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12825> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11359: Consider removing RelaxedLayout and friends
by GHC 21 Jan '18

21 Jan '18

#11359: Consider removing RelaxedLayout and friends -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- These three parsing-related language extensions were [[https://ghc.haskell.org/trac/ghc/wiki/LanguagePragmaHistory|introduced]] some time ago yet are likely not used in the wild as they still are not registered in Cabal's language extension list (which Hackage uploads are checked against, see #8176), * `RelaxedLayout` (introduced in 7.2, prompted by #1060) * `AlternativeLayoutRule` (introduced in 7.0, reason unknown) * `AlternativeLayoutRuleTransitional` (introduced in 7.0, reason unknown) As far as [[https://mail.haskell.org/pipermail/ghc- devs/2013-September/002267.html|I can]] [[https://ghc.haskell.org/trac/ghc/ticket/8176#comment:10|tell]] no one knows the status of these, nor are they listed in the users guide. We should ask the community whether they would mind seeing these extensions vanish and remove them if not. If so then we should see to it that they are registered properly with Cabal so they can be used on Hackage. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11359> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11091: Fix MonadFail warnings
by GHC 21 Jan '18

21 Jan '18

#11091: Fix MonadFail warnings -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: task | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- #10751 implements the MonadFail warning mechanism. Using `-fwarn-missing-monadfail-instance`, GHC's internal warnings created by the patch can be shown and fixed. A second pass with `-XMonadFailDesugaring` then provides a hard check on whether any issues remain, by switching on the new desugaring mechanism properly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11091> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14273: Typed holes are oblivious to type class constraints
by GHC 20 Jan '18

20 Jan '18

#14273: Typed holes are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 (Type checker) | 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: -------------------------------------+------------------------------------- This example is taken from Chris Allen's blog post [http://bitemyapp.com//posts/2017-09-23-please-stop-using-typed-holes.html here]: {{{#!hs pleaseShow :: Show a => Bool -> a -> Maybe String pleaseShow False _ = Nothing pleaseShow True a = Just (show _a) }}} On a recent GHC HEAD build, compiling this outputs: {{{ Bug.hs:3:32: error: • Found hole: _a :: a0 Where: ‘a0’ is an ambiguous type variable Or perhaps ‘_a’ is mis-spelled, or not in scope • In the first argument of ‘show’, namely ‘_a’ In the first argument of ‘Just’, namely ‘(show _a)’ In the expression: Just (show _a) • Relevant bindings include a :: a (bound at Bug.hs:3:17) pleaseShow :: Bool -> a -> Maybe String (bound at Bug.hs:2:1) Valid substitutions include (++) :: forall a. [a] -> [a] -> [a] (imported from ‘Prelude’ at Bug.hs:1:1 (and originally defined in ‘GHC.Base’)) fail :: forall (m :: * -> *). Monad m => forall a. String -> m a (imported from ‘Prelude’ at Bug.hs:1:1 (and originally defined in ‘GHC.Base’)) return :: forall (m :: * -> *). Monad m => forall a. a -> m a (imported from ‘Prelude’ at Bug.hs:1:1 (and originally defined in ‘GHC.Base’)) errorWithoutStackTrace :: forall (a :: TYPE r). [Char] -> a (imported from ‘Prelude’ at Bug.hs:1:1 (and originally defined in ‘GHC.Err’)) seq :: forall a b. a -> b -> b (imported from ‘Prelude’ at Bug.hs:1:1 (and originally defined in ‘GHC.Prim’)) (<>) :: forall a. Semigroup a => a -> a -> a (imported from ‘Prelude’ at Bug.hs:1:1 (and originally defined in ‘GHC.Base’)) (Some substitutions suppressed; use -fmax-valid-substitutions=N or -fno-max-valid-substitutions) | 3 | pleaseShow True a = Just (show _a) | ^^ }}} There are a couple very unsavory things about this error: 1. GHC makes no attempt to inform me that `a0` is a `Show` instance! This is the primary gripe in the blog post, and it's worth emphasizing, since without the `Show` constraint, `a0` just looks like any other random type variable. Speaking of which... 2. The list of valid substitutions is incorrect! It suggests several things which have function types, such as `(++)` and `fail`, but `(->)` does not have a `Show` instance! This list ought to be pruned based on the current type class constraints in scope. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14273> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #14497: internal error: scavenge_one: strange object 19828
by GHC 18 Jan '18

18 Jan '18

#14497: internal error: scavenge_one: strange object 19828 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'll attach the test program. Reproduces each time. {{{ $ ./test Nothing test: internal error: scavenge_one: strange object 19828 Stack trace: 0x4b27df set_initial_registers (rts/Libdw.c:288.0) 0x7fe51b3fcd48 dwfl_thread_getframes (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x7fe51b3fd22c dwfl_getthread_frames (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x4b2ddd libdwGetBacktrace (rts/Libdw.c:259.0) 0x49883b rtsFatalInternalErrorFn (rts/RtsMessages.c:169.0) 0x4989ed barf (rts/RtsMessages.c:47.0) 0x4b3f8c scavenge_one (rts/sm/Scav.c:1615.0) 0x4b4e91 scavenge_loop1 (rts/sm/Scav.c:2066.0) 0x49d517 scavenge_until_all_done (rts/sm/GC.c:1017.0) 0x49dde4 GarbageCollect (rts/sm/GC.c:412.0) 0x4969a3 scheduleDoGC (rts/Schedule.c:1827.0) 0x49776c schedule (rts/Schedule.c:558.0) 0x49811c scheduleWorker (rts/Schedule.c:2582.0) 0x7fe51b835494 start_thread (/build/glibc- tnXPha/glibc-2.24/nptl/pthread_create.c:333.0) 0x7fe51b113abf __clone (../sysdeps/unix/sysv/linux/x86_64/clone.S:99.0) (GHC version 8.2.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14497> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function
by GHC 17 Jan '18

17 Jan '18

#13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #13014 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… #specialize-inline The user's guide] for `SPECIALIZE INLINE` states it will do a "type-based unrolling" of a recursive function over GADTs. It gives an example, which I've munged a bit to simplify and listed here. {{{#!hs {-# Language GADTs #-} module C where data Arr e where ArrInt :: !Int -> Arr Int ArrPair :: Arr e1 -> Arr e2 -> Arr (e1, e2) (!:) :: Arr e -> Int -> e {-# SPECIALISE INLINE (!:) :: Arr Int -> Int -> Int #-} {-# SPECIALISE INLINE (!:) :: Arr (a, b) -> Int -> (a, b) #-} (ArrInt ba) !: i = ba * i (ArrPair a1 a2) !: i = (a1 !: i, a2 !: i) }}} {{{#!hs module D where import C example = ArrPair (ArrInt 2) (ArrInt 3) !: 5 }}} The specialize rule for pairs fires, but it does not get inlined. This is because the specialization for pairs is marked as a loopbreaker. This behavior contradicts the text from the users guide, emphasis mine: Here, `(!:)` is a recursive function that indexes arrays of type `Arr e`. Consider a call to `(!:)` at type `(Int,Int)`. The second specialisation will fire, ''and the specialised function will be inlined''. It has two calls to `(!:)`, both at type `Int`. Both these calls fire the first specialisation, whose body is also inlined. The result is a type-based unrolling of the indexing function. If I move the `SPECIALIZE INLINE` pragma to the downstream module, then it is not marked as a loopbreaker and we see the expected type-based unrolling. Two possible ways to resolve this ticket: * `SPECIALIZE INLINE` should always achieve supercompilation even if declared in the defining module; the specialization should not be marked as a loopbreaker. * The docs should be updated to say the pragma must be declared in a separate module. I suggest the former. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13016> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13683: Use epoll rather than poll where appropriate
by GHC 16 Jan '18

16 Jan '18

#13683: Use epoll rather than poll where appropriate ----------------------------------------+--------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Linux supports an `epoll` system call that's supposed to scale better to large numbers of watched file descriptors than `poll`. We should probably use it when available and appropriate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13683> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14338: Simplifier fails with "Simplifier ticks exhausted"
by GHC 16 Jan '18

16 Jan '18

#14338: Simplifier fails with "Simplifier ticks exhausted" -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While upgrading a codebase to GHC 8.2.1(it compiles reliably with 7.10.3) we encountered an issue with core simplifier(and rewrite rules if I correctly understood the meaning of RuleFired): {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): Simplifier ticks exhausted When trying RuleFired Class op $p2HModify To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed Total ticks: 10450410 1494659 PreInlineUnconditionally 149100 w_ipsJ 149095 w_ipps 149084 w_iplQ 149084 w1_iplR 149084 w2_iplS 149084 w3_iplT 149078 w_ipm7 149078 w1_ipm8 149078 w2_ipm9 149078 w3_ipma 120 $d~_iplr 120 $d~1_ipls 120 irred_iplu 120 eta_iplv 39 v_spsR 38 v_sp9c 38 v1_sp9d 38 v_spii 38 v1_spij 38 v2_spik 38 v3_spil 37 v_sp99 37 v1_sp9a 37 v_spin 37 v1_spio 37 v2_spip 37 v3_spiq 36 v_sp9f 36 v1_sp9g 36 v_spis ...skipping... 1 cobox1_apuk 1 cobox_apuq 1 cobox1_apur 1 cobox_apux 1 cobox1_apuy 2 CaseIdentity 2 ds1_iqAB 4 FillInCaseDefault 1 nt_sqyY 1 nt_sqz9 1 nt_sqze 1 nt_sqzj Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} We tried to shrink reproducible example to something reasonable and this is what we got: https://github.com/4e6/webapp-template-hs/tree/simpl-tick- factor Compiling it with stack build --ghc-options='-fsimpl-tick-factor=1000'(ten times the default) will demonstrate the issue. It fails reliably with a combination of servant and hset libraries. Removing one route from a servant API or moving the PayloadX to the head of type-level list makes it compilable again. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14338> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

[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 15 Jan '18

15 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