- ghc-tickets - Haskell.org

[GHC] #16350: Nondeterministic T5559 failures on CI
by GHC 04 Mar '19

04 Mar '19

#16350: Nondeterministic T5559 failures on CI -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.9 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 `T5559` test case occasionally fails on CI, forcing me to restart builds to get a green build status. Here is [https://ghc- gitlab.s3.amazonaws.com/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1… ?response-content-type=text/plain%3B%20charset%3Dutf-8&response-content- disposition=inline&X-Amz-Expires=600&X-Amz-Date=20190221T104600Z&X-Amz- Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NPPHETCY4XXTOA/20190221 /us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz- Signature=4cda8d47d000a69a39765a5c141f1e33a610992f1f8ea60da83c4ec6eaca42d8 one example] from a `validate-x86_64-linux-fedora27` run: {{{ "gs" -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE "profiling/should_run/T5559.run/T5559.ps" hp2ps output for T5559is not valid PostScript *** unexpected failure for T5559(profasm) <elided> SUMMARY for test run started at Thu Feb 21 00:32:08 2019 UTC 0:44:16 spent to go through 6839 total tests, which gave rise to 26523 test cases, of which 19210 were skipped 42 had missing libraries 7178 expected passes 92 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 0 unexpected stat failures Unexpected failures: profiling/should_run/T5559.run T5559 [bad heap profile] (profasm) }}} Aside from the nondeterministic test failure, this also reveals a minor bug: it prints `T5559is not valid PostScript`, which should probably be `T5559 is not valid PostScript` instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16350> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16315: Pattern synonym implicit existential quantification
by GHC 04 Mar '19

04 Mar '19

#16315: Pattern synonym implicit existential quantification -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- This code typechecks when `k` is brought into scope explicitly, but not implicitly (code example courtesy of RyanGlScott): {{{#!hs {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} module Bug where import Data.Kind import Data.Proxy data T = forall k (a :: k). MkT (Proxy a) -- Uncomment `k` and it typechecks pattern P :: forall. () => forall {-k-} (a :: k). Proxy a -> T pattern P x = MkT (x :: Proxy (a :: k)) }}} I discovered this because I was implementing https://github.com/ghc- proposals/ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst and had to explicitly quantify some definitions in the test suite. Then the test case for #14498 stopped producing the error that it should. It seems indicative of an issue in typechecking pattern synonyms: I would expect equal treatment for implicit and explicit type/kind variables. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16315> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #16112: T11334b fails in the devel2 way
by GHC 04 Mar '19

04 Mar '19

#16112: T11334b fails in the devel2 way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{patch --- dependent/should_fail/T11334b.run/T11334b.stderr.normalised 2018-12-30 16:00:25.377677569 +0000 +++ dependent/should_fail/T11334b.run/T11334b.comp.stderr.normalised 2018-12-30 16:00:25.377677569 +0000 @@ -1,24 +1,13 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.7.20181230 for x86_64-unknown-linux): + ASSERT failed! + f_aBF[tau:2] + 2 + 1 + Call stack: + CallStack (from HasCallStack): + callStackDoc, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + pprPanic, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + assertPprPanic, called at compiler/typecheck/TcType.hs:<line>:<column> in <package-id>:TcType -T11334b.hs:8:14: - Cannot default kind variable ‘f0’ - of kind: k0 -> * - Perhaps enable PolyKinds or add a kind signature - In an expression type signature: Proxy 'Compose - In the expression: Proxy :: Proxy 'Compose - In an equation for ‘p’: p = Proxy :: Proxy 'Compose - -T11334b.hs:8:14: - Cannot default kind variable ‘g0’ - of kind: k10 -> k0 - Perhaps enable PolyKinds or add a kind signature - In an expression type signature: Proxy 'Compose - In the expression: Proxy :: Proxy 'Compose - In an equation for ‘p’: p = Proxy :: Proxy 'Compose - -T11334b.hs:8:14: - Cannot default kind variable ‘a0’ - of kind: k10 - Perhaps enable PolyKinds or add a kind signature - In an expression type signature: Proxy 'Compose - In the expression: Proxy :: Proxy 'Compose - In an equation for ‘p’: p = Proxy :: Proxy 'Compose +Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16331: REGRESSION: --supported-languages lies about supported languages, again
by GHC 04 Mar '19

04 Mar '19

#16331: REGRESSION: --supported-languages lies about supported languages, again -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- To make it short, recent version of GHC broke the very thing we fixed in #11102 for GHC 8.0. This is utterly frustrating to me. ;-( Basically, if GHC advertises an extension, it's supposed to work without jumping through hoops if you enable it via `{-# LANGUAGE ... #-}` or `-X`-flags. Otherwise this breaks the whole idea of `other-extensions` and related cabal spec features which use `--supported-languages` to infer whether e.g. GHC when invoked with `-XTemplateHaskell` will succeed. However, consider the `Main.hs` below {{{#!hs {-# LANGUAGE TemplateHaskell #-} main = $undefined }}} Unfortuantely now GHC lies unconditionally about supporting TH, thereby undermining the infrastructure we setup in and for #11102: {{{ $ ghc --supported-languages | grep ^TemplateHaskell$ TemplateHaskell $ ghc --make Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) ghc-stage2: this operation requires -fexternal-interpreter }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16331> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #24: dlopen() errors reported badly
by GHC 04 Mar '19

04 Mar '19

#24: dlopen() errors reported badly --------------------------------+-------------------- Reporter: cwitty | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 5.02 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Changes (by Marge Bot <ben+marge-bot@…>): * failure: => None/Unknown Comment: In [changeset:"5bc195b1fe788e9a900a15fbe473967850517c3e/ghc" 5bc195b1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5bc195b1fe788e9a900a15fbe473967850517c3e" Treat kind/type variables identically, demolish FKTV Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024 -no-kind-vars.rst Fixes Trac #16334, Trac #16315 With this patch, scoping rules for type and kind variables have been unified: kind variables no longer receieve special treatment. This simplifies both the language and the implementation. User-facing changes ------------------- * Kind variables are no longer implicitly quantified when an explicit forall is used: p :: Proxy (a :: k) -- still accepted p :: forall k a. Proxy (a :: k) -- still accepted p :: forall a. Proxy (a :: k) -- no longer accepted In other words, now we adhere to the "forall-or-nothing" rule more strictly. Related function: RnTypes.rnImplicitBndrs * The -Wimplicit-kind-vars warning has been deprecated. * Kind variables are no longer implicitly quantified in constructor declarations: data T a = T1 (S (a :: k) | forall (b::k). T2 (S b) -- no longer accepted data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b) -- still accepted Related function: RnTypes.extractRdrKindSigVars * Implicitly quantified kind variables are no longer put in front of other variables: f :: Proxy (a :: k) -> Proxy (b :: j) f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b -- old order f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b -- new order This is a breaking change for users of TypeApplications. Note that we still respect the dpendency order: 'k' before 'a', 'j' before 'b'. See "Ordering of specified variables" in the User's Guide. Related function: RnTypes.rnImplicitBndrs * In type synonyms and type family equations, free variables on the RHS are no longer implicitly quantified unless used in an outermost kind annotation: type T = Just (Nothing :: Maybe a) -- no longer accepted type T = Just Nothing :: Maybe (Maybe a) -- still accepted The latter form is a workaround due to temporary lack of an explicit quantification method. Ideally, we would write something along these lines: type T @a = Just (Nothing :: Maybe a) Related function: RnTypes.extractHsTyRdrTyVarsKindVars * Named wildcards in kinds are fixed (Trac #16334): x :: (Int :: _t) -- this compiles, infers (_t ~ Type) Related function: RnTypes.partition_nwcs Implementation notes -------------------- * One of the key changes is the removal of FKTV in RnTypes: - data FreeKiTyVars = FKTV { fktv_kis :: [Located RdrName] - , fktv_tys :: [Located RdrName] } + type FreeKiTyVars = [Located RdrName] We used to keep track of type and kind variables separately, but now that they are on equal footing when it comes to scoping, we can put them in the same list. * extract_lty and family are no longer parametrized by TypeOrKind, as we now do not distinguish kind variables from type variables. * PatSynExPE and the related Note [Pattern synonym existentials do not scope] have been removed (Trac #16315). With no implicit kind quantification, we can no longer trigger the error. * reportFloatingKvs and the related Note [Free-floating kind vars] have been removed. With no implicit kind quantification, we can no longer trigger the error. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/24#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15508: concprog001 fails with various errors when compiled with -prof
by GHC 04 Mar '19

04 Mar '19

#15508: concprog001 fails with various errors when compiled with -prof -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D5051 | Wiki Page: -------------------------------------+------------------------------------- I'm observing a few different runtime errors. I'm not sure if they're because of different bugs so I'm filing one ticket for now. Reproduce with GHC HEAD: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -DS Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}} I tried to fix this in Phab:D5051 but it's causing a segfault in test `T11108` when run with profiling. Not sure what the problem is yet. It's very easy to trigger other kind of panics in `concprog001`, just try different compile and runtime flag combinations: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}} Yet another way: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: invalid closure, info=0x947edc (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 }}} It seems to work fine when not compiled for profiling so marking this bug as a profiler bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 49

[GHC] #14671: Make the Template Haskell class Lift work over typed expressions
by GHC 04 Mar '19

04 Mar '19

#14671: Make the Template Haskell class Lift work over typed expressions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.2.2 Haskell | Keywords: | Operating System: Unknown/Multiple TemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment we have the `Lift` class in TH: {{{ class Lift t where lift :: t -> Q Exp }}} But that loses type information. What we want is this: {{{ Lift t where typedLift :: t -> Q (TExp t) lift :: Lift t => t -> Q Exp lift = fmap unType . typedLift }}} Otherwise, when you want the typed version, people resort to unsafe-coerce operations, which are entirely unnecessary. See [https://mail.haskell.org/pipermail/libraries/2018-January/028409.html this thread on the libraries list]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15840: Inline data constructor wrappers very late
by GHC 04 Mar '19

04 Mar '19

#15840: Inline data constructor wrappers very late -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.7 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 came up in the context of the implementation of linear types, where more data constructors have wrapper. But this should be of more general use. I want to share this in case someone can find an objection to this approach. Currently, writing a RULE involving a data constructor with a wrapper is perilous: the wrapper will be inlined in phase 2, probably before the RULE is even triggered (necessarily if the RULE only runs in phase 1). I want to remedy this situation. This proposal is mainly from Simon Peyton Jones, any misrepresentation is, of course, my own. The proposal is to inline all data constructor wrappers in phase 0. After all the RULE business has been dealt with. If we do that, we need to be quite careful about case-of-know-constructor: In {{{#!hs case $WK u of { K x -> e; … } }}} `$WK` wouldn't unfold until very late. But we don't want the `case` expression to be blocked! Otherwise we may, for instance, prevent the function's size to be small enough to be inlined. Hence a maybe some rules will not trigger. That would not be acceptable. Fortunately, in order to decide whether case-of-known-constructor can perform, the simplifier calls `exprIsConApp_maybe`. Also fortunate is that in the situation above, we really don't care about any RULE stuff (at least not in relation with `K`). So what we can do is make `exprIsConApp_maybe` a bit smarter and teach it to see through data constructor wrappers. Let's take an unpacking wrapper as an example: {{{#!hs data T = MkT {-# UNPACK #-} !(Int, Bool) $WMkT p = case p of (i,b) -> MkT i b }}} We have to see that `$WMkT u` is a constructor application. Hence we need to be able to peek through cases. We also need to be able to witness that we have done so. So the type of `exprIsConApp_maybe` would change from {{{#!hs exprIsConApp_maybe :: InScopeEnv -> CoreExpr -> Maybe (DataCon, [Type], [CoreExpr]) }}} to {{{#!hs exprIsConApp_maybe :: InScopeEnv -> CoreExpr -> Maybe ([Float],DataCon, [Type], [CoreExpr]) }}} Where `Float`-s are lets or cases with a single alternative (much like in the FloatOut pass). We then need to change case-of-known-constructor to also perform case-of- lets and case-of-cases when such floats are found. In summary: data constructor wrappers would be inlined in phase 0, except when they can trigger a case-of-known constructor, in which case they would be inlined immediately. Does anyone sees something which could go wrong with this plan? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15840> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #16303: checkStack sanity check fails
by GHC 04 Mar '19

04 Mar '19

#16303: checkStack sanity check fails -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- checkStackChunk() currently has a commented-out assertion: {{{ void checkStackChunk( StgPtr sp, StgPtr stack_end ) { StgPtr p; p = sp; while (p < stack_end) { p += checkStackFrame( p ); } // ASSERT( p == stack_end ); -- HWL } }}} I realized a while ago that if I enable it, it fails in some cases, so I asked Simon Marlow about this. Quoting: > I don't know, but blame says it was disabled by Hans-Wolfgang Loidl as part of > the GUM merge 18 years ago. I suggest just enabling it and debug whatever goes > wrong. This ticket is to enable the assertion and fix bugs. To reproduce, run the test suite: {{{ $ make EXTRA_HC_OPTS='-debug -rtsopts' WAY=sanity }}} Tests that trigger the assertion: - annrun01 - T10508_api - dynCompileExpr Tried with GHC HEAD -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16303> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16190: Speed up handling of large String literals
by GHC 04 Mar '19

04 Mar '19

#16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- The idea would to try the following optimization for literal strings by adding a pass in the simplifier that does: 1. detect large string literals (> 2KB maybe? we would need to find a threshold) 2. append large strings into a temporary binary file, remember their offset and size 3. include the binary file into the compilation chain using ".incbin" in an assembler file (see the details here: https://hsyl20.fr/home/posts/2019-01-15-fast-file-embedding-with- ghc.html); add a fresh global module-specific symbol for the file, say "largestrings" 4. replace `Lit (Literal (LitString LARGE_BYTESTRING))` expressions with `unpackNBytes# (plusAddr (CLabel "largestrings") offset) size` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16190> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13