January 2016 - ghc-tickets

[GHC] #11428: ImpredicativeTypes causes GHC panic with 8.0.1-rc1
by GHC 02 Feb '16

02 Feb '16

#11428: ImpredicativeTypes causes GHC panic with 8.0.1-rc1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Type checker) | Keywords: | Operating System: Unknown/Multiple ImpredicativeTypes | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed this issue when attempting to compile `conduit` with GHC 8.0.1-rc1 (specifically, the [https://github.com/snoyberg/conduit/blob/master/conduit/Data/Conduit/Intern… Data.Conduit.Internal.Pipe] module). This (greatly simplified) code, which compiles without issue on GHC 7.10.3: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} module Data.Conduit.Internal.Pipe where data Pipe o r = HaveOutput (Pipe o r) o mapOutputMaybe :: (o1 -> Maybe o2) -> Pipe o1 r -> Pipe o2 r mapOutputMaybe f (HaveOutput p o) = maybe id (\o' p' -> HaveOutput p' o') (f o) (mapOutputMaybe f p) }}} emits a GHC panic with GHC 8.0.1-rc1: {{{ [1 of 1] Compiling Data.Conduit.Internal.Pipe ( Wat.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160111 for x86_64-unknown-linux): matchExpectedFunTys <> a_a15Z[tau:5] -> b_a15Y[tau:5] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Note that this code does not require `-XImpredicativeTypes`, and removing the pragma makes the code compile again. Marking as high since it's a regression, but not highest because `-XImpredicativeTypes` has long been broken (see also #11319). Still, this currently happens on code in the wild, and perhaps it would be worth turning this into a more sensible error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11428> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11247: Weird error from running runghc on an invalid input filename
by GHC 02 Feb '16

02 Feb '16

#11247: Weird error from running runghc on an invalid input filename -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #7765 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I had files `random.hs` and `random.hi` and `random.o`, so I accidentally entered the following command with tab completion. {{{ rwbarton@morphism:/tmp$ runghc random. Warning: ignoring unrecognised input `random.' random.:1:33: Not in scope: ‘main’ Perhaps you meant ‘min’ (imported from Prelude) }}} #7765 is surely related, but with HEAD (well, rather old, but at least new enough to contain the fix for #7765), the error is not really any better: {{{ rwbarton@morphism:/tmp$ ~/ghc/inplace/bin/runghc random. Warning: ignoring unrecognised input `random.' random.:0:53: error: Variable not in scope: main :: IO a0 Perhaps you meant ‘min’ (imported from Prelude) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11247> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case
by GHC 02 Feb '16

02 Feb '16

#11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case --------------------------------------+---------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- The body of `stg_ap_pp_fast` looks like {{{ arity = TO_W_(StgFunInfoExtra_arity(%GET_FUN_INFO(R1))); ASSERT(arity > 0); if (arity == 1) { Sp_adj(-2); W_[Sp+WDS(1)] = R3; W_[Sp+WDS(0)] = stg_ap_p_info; R1 = R1 + 1; jump_SAVE_CCCS(%GET_ENTRY(UNTAG(R1))); } if (arity == 2) { Sp_adj(0); R1 = R1 + 2; jump %GET_ENTRY(UNTAG(R1)) [R1,R2,R3]; } else { Sp_adj(-3); W_[Sp+WDS(2)] = R3; W_[Sp+WDS(1)] = R2; if (arity < 4) { R1 = R1 + arity; } BUILD_PAP(2,2,stg_ap_pp_info,FUN); } }}} where {{{ // Jump to target, saving CCCS and restoring it on return #if defined(PROFILING) #define jump_SAVE_CCCS(target) \ Sp(-1) = CCCS; \ Sp(-2) = stg_restore_cccs_info; \ Sp_adj(-2); \ jump (target) [R1] #else #define jump_SAVE_CCCS(target) jump (target) [R1] #endif }}} So in the arity=1 case the jump amounts to {{{ jump (%GET_ENTRY(UNTAG(R1))) [R1] }}} R1 is the function to apply, but we don't pass its argument, R2! Now, possibly by design, the calling convention of `stg_ap_pp_fast` is such that the first argument to apply is in R2, which is the same register that the function R1 will expect to find its argument in. So if nothing happens to disturb R2 (and possibly this is always the case with the NCG), then everything is fine. However, it's definitely not fine for the LLVM backend, which quite reasonably passes `undef` for the R2, R3, and R4 arguments when doing the jump. On arm/Android, LLVM decided to clobber `r8` (the physical register for R2) in the body of `stg_ap_pp_fast`. This caused a crash for the following program: {{{ main = print (read "3"::Int) }}} This appears to have been broken by commit f9265dd369b9e269349930012c25e670248f2a09 which changed the argument list for `jump_SAVE_CCCS` from `[*]` to `[R1]`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11487> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #11100: Remote GHCi
by GHC 02 Feb '16

02 Feb '16

#11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 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: -------------------------------------+------------------------------------- This task is to implement Remote GHCi, i.e. running interpreted code in a separate process. For more details see [wiki:RemoteGHCi]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances
by GHC 01 Feb '16

01 Feb '16

#11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: PolyKinds, | Operating System: Unknown/Multiple UndecidableSuperClasses | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #10318 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Looks like I spoke too soon when I said all my examples worked in #10318 -- it doesn't seem to work when the superclass cycle gets sufficiently interesting, possibly caused by the use of `PolyKinds` in the style mentioned in #9201. I took my `hask` code, and removed the shimming hacks above, and the following stripped down example sends the compiler into an infinite loop, which I believe should be able to work: {{{#!hs {-# language KindSignatures, PolyKinds, TypeFamilies, NoImplicitPrelude, FlexibleContexts, MultiParamTypeClasses, GADTs, ConstraintKinds, FlexibleInstances, FunctionalDependencies, UndecidableSuperClasses #-} import GHC.Types (Constraint) import qualified Prelude data Nat (c :: i -> i -> *) (d :: j -> j -> *) (f :: i -> j) (g :: i -> j) class Functor p (Nat p (->)) p => Category (p :: i -> i -> *) class (Category dom, Category cod) => Functor (dom :: i -> i -> *) (cod :: j -> j -> *) (f :: i -> j) | f -> dom cod instance (Category c, Category d) => Category (Nat c d) instance (Category c, Category d) => Functor (Nat c d) (Nat (Nat c d) (->)) (Nat c d) instance (Category c, Category d) => Functor (Nat c d) (->) (Nat c d f) instance Category (->) instance Functor (->) (->) ((->) e) instance Functor (->) (Nat (->) (->)) (->) }}} Sorry for the largish example, but I don't know how to strip it down smaller than the 6 instances that remain. One potentially telling observation is that without the instances it compiles, and produces what I expect, so the `UndecidableSuperClasses` part seems to be letting the classes compile, but there seems to be a bad interaction with the way the instances work. Also, in this stripped down form, I can remove the use of `UndecidableInstances` and that avoids the spinning problem, but once I flesh it out further I need `UndecidableInstances` in the "real" version of the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11480> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled
by GHC 30 Jan '16

30 Jan '16

#11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 11371 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * owner: => niteria Comment: I'm going to dig more, but I expect I might not know how to best fix this. In general how does the typechecker deal with types that can get exponential? The part of the code that generates such types is: {{{ newtype VoidBad a = VoidBad (VoidBad (a,a)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11518#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3693: Show stack traces
by GHC 30 Jan '16

30 Jan '16

#3693: Show stack traces -------------------------------------+------------------------------------- Reporter: jpet | Owner: Tarrasch Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10656 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by Slavon8): * Attachment "93098974.png" added. [http://smartmiltoys.com/kidkraft-train-table/ http://smartmiltoys.com /kidkraft-train-table/] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11517: ghc -haddock fails to parse doc comments in closed type families
by GHC 30 Jan '16

30 Jan '16

#11517: ghc -haddock fails to parse doc comments in closed type families -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Keywords: Haddock | 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 with -haddock fails to parse the following program: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where type family Closed a where -- |This comment fails to parse Closed Int = Bool }}} {{{ ghc -haddock Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:3: parse error on input ‘-- |This comment fails to parse’ }}} (tested with 7.10.3 and an slightly out-of-date HEAD) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11517> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11082: Tweak workflow around overlong lines
by GHC 29 Jan '16

29 Jan '16

#11082: Tweak workflow around overlong lines -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.2 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: -------------------------------------+------------------------------------- [https://mail.haskell.org/pipermail/ghc-devs/2015-November/010373.html This thread] discussed potential changes to the way the GHC dev workflow deals with overlong lines. This ticket summarizes the discussion. '''Initial complaint:''' arc/Phab is too heavy-handed about overlong lines. Almost all patchers have to write a vacuous "explanation" for them, and the overlong line warnings clutter code reviews. '''Initial suggestion:''' After `arc diff` is run, it will count the number of overlong lines before and after the patch. If there are more after, have the last thing `arc diff` outputs be a stern telling-off of the dev, along the lines of {{{ Before your patch, 15 of the edited lines were over 80 characters. Now, a whopping 28 of them are. Can't you do better? Please? }}} '''Reactions:''' * +1 * Even the delta in overlong lines is bad, because perhaps a small refactor added to the length of an identifier. * We might just want to reject code with overlong lines. Then the problem would really go away. It favors one-time work over many-time maintenance burden. (Austin's point, +1 by Alexander Berntsen) * This would cause more work and would increase the barrier to contribution. And sometimes it's appropriate/more readable to have overlong lines. * 80 is too small. 120 (SPJ)? 132 (Ed Kmett)? * And a small limit discourages informative identifiers. * Just drop the column limit entirely. * Why 80? Because two 80-column buffers fit nicely side-by-side on small laptop screens. Three such columns fit nicely on monitors. Several (4 emails) echoed this point. Bottom line: no one expressed liking the status quo (though Simon M called it "not terrible"). If we're to choose a limit, a choice of 80 seemed to appease the plurality of respondents. Two respondents advocate enforcing the limit. I count four respondents rejecting hard enforcement. In my (surely biased) view, this means that we should implement my original proposal. :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10310: MakingReleases outdated or build system problems
by GHC 29 Jan '16

29 Jan '16

#10310: MakingReleases outdated or build system problems -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hey, I have some problems following https://ghc.haskell.org/trac/ghc/wiki/MakingReleases with HEAD. I'll collect them here, maybe we can update the Wiki page together, or fix the corresponding problems in the build system if they are problems. 1) `make sdist` fails with the problem that `ghc-tarballs` doesn't exist. I've heard that's only needed on Windows, and that some people seem to get it by cloning a submodule when they are on Windows. A `mkdir ghc-tarballs` fixed it. Maybe that directory should be created by the build system? 2) When I `make` in the unpacked sdist tarball, I get {{{ "" -P 'filename.as.url=0' utils/haddock/doc/haddock.xml --ps -o utils/haddock/doc/haddock.ps "" -P 'filename.as.url=0' utils/haddock/doc/haddock.xml --pdf -o utils/haddock/doc/haddock.pdf /bin/bash: : command not found /bin/bash: : command not found make[1]: *** [utils/haddock/doc/haddock.ps] Error 127 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [utils/haddock/doc/haddock.pdf] Error 127 }}} Looks like some program was set to the empty string here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10310> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2