May 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] #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] #10972: Add a :binfo (beginner info) GHCi command
by GHC 15 Jan '18

15 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

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

15 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

[GHC] #13752: Odd pattern synonym type errors
by GHC 14 Jan '18

14 Jan '18

#13752: Odd pattern synonym type errors -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose we have {{{#!hs newtype Arrange = Arrange {getArrange :: [Int] -> [Int]} }}} If I write {{{#!hs pattern Heh :: (c ~ ((~) Int)) => (forall a. c a => [a] -> [a]) -> Arrange pattern Heh f <- Arrange f }}} I get {{{ • Couldn't match type ‘[Int] -> [Int]’ with ‘forall a. Int ~ a => [a] -> [a]’ Expected type: forall a. c a => [a] -> [a] Actual type: [Int] -> [Int] • In the declaration for pattern synonym ‘Heh’ }}} It surprises me that these don't match. I can hack around that a bit: {{{#!hs newtype Help = Help {getHelp :: forall a. Int ~ a => [a] -> [a]} pattern Heh :: (c ~ ((~) Int)) => (forall a. c a => [a] -> [a]) -> Arrange pattern Heh f <- ((\x -> Help (getArrange x)) -> Help f) }}} Now this compiles, and I can use it in a variety of ways, but not quite all. If I write {{{#!hs pattern Heh' :: ([Int] -> [Int]) -> Arrange pattern Heh' f <- Heh f }}} I get {{{ Haha.hs:78:23: error: • Couldn't match expected type ‘[Int] -> [Int]’ with actual type ‘forall a. Int ~ a => [a] -> [a]’ • In the declaration for pattern synonym ‘Heh'’ | 78 | pattern Heh' f <- Heh f | ^ }}} This strikes me as perhaps even more surprising. I can hack around that too, of course, but yuck! {{{#!hs pattern Heh' :: ([Int] -> [Int]) -> Arrange pattern Heh' f <- ((\(Heh g) -> g @ Int) -> f) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13752> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10634: Type class with bijective type functions
by GHC 14 Jan '18

14 Jan '18

#10634: Type class with bijective type functions -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- See the attached module. {{{ $ cat TypeFunctionBijection.hs {-# LANGUAGE TypeFamilies #-} module TypeFunctionBijection where import Data.Int (Int8, Int16, Int32) type family Up a type instance Up Int8 = Int16 type instance Up Int16 = Int32 class (Up (Down a) ~ a) => Convert a where type Down a down :: a -> Down a instance Convert Int16 where type Down Int16 = Int8 down = fromIntegral instance Convert Int32 where type Down Int32 = Int16 down = fromIntegral x :: Int8 x = down 8 }}} {{{ $ ghci-7.8.4 -Wall TypeFunctionBijection.hs GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling TypeFunctionBijection ( TypeFunctionBijection.hs, interpreted ) Ok, modules loaded: TypeFunctionBijection. *TypeFunctionBijection> :q Leaving GHCi. }}} {{{ $ ghci-7.10.1 -Wall TypeFunctionBijection.hs GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling TypeFunctionBijection ( TypeFunctionBijection.hs, interpreted ) TypeFunctionBijection.hs:24:5: Couldn't match expected type ‘Int8’ with actual type ‘Down a0’ The type variable ‘a0’ is ambiguous In the expression: down 8 In an equation for ‘x’: x = down 8 Failed, modules loaded: none. Prelude> :q Leaving GHCi. }}} Up to GHC-7.8.4 I could make a type function like `Down` a bijection by adding equality constraints to the `Convert` class. In GHC-7.10.1 this fails. Is this a bug or a feature? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10634> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4