February 2019 - ghc-tickets

[GHC] #16270: Report multiple errors during parsing
by GHC 05 Mar '19

05 Mar '19

#16270: Report multiple errors during parsing -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Parser) | 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: -------------------------------------+------------------------------------- Parsing failures currently abort the parsing process (with `parseErrorSDoc`) even if it can continue and report multiple errors at once. This is easy to fix by creating a new combinator, `addError`, similar to `addWarning`, which would add the error message to the accumulator but continue parsing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16270> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14037: Fix fusion for GHC's utility functions
by GHC 05 Mar '19

05 Mar '19

#14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In a patchset I'm working on, I encountered a smallish "bytes allocated" regression in `perf/compiler/T5631`. After some sleuthing, I discovered that the regression is caused by using a `zipWith3M` where previously there was a `zipWithM`. Interestingly, it was not the zipped function that caused the problem, but the `zipWith3M` itself. Further sleuthing found that `zipWithM` is inlined into a combination of `sequenceA` and `zipWith`, both of which have been taught to work nicely with fusion. I thought of doing the same to GHC's `zipWith3M`, but I discovered that `base`'s `zipWith3` has no rules or inlining pragmas, suggesting that it does not fuse. I was quite surprised to find this, thinking that all functions as basic as `zipWith3` in `base` would play nicely with fusion. (Perhaps it does fuse -- I didn't actually check.) I then checked out GHC's `MonadUtils`, which defines a bunch of functions, some of which must be hammered on, and only one of which has any kind of performance- enhancing pragma. (The one is `zipWithAndUnzipM`, whose `INLINABLE` pragma was added only after much pain suffered by your dear author.) So: this ticket is a request to sweep through `MonadUtils` and `Util` and perhaps `ListSetOps`, looking for performance enhancements via fusion, tighter definitions, and such. Also, get `zipWith3` (and the other `zipWith`s) to fuse in `base`. I figure this is all some fairly low-hanging fruit for performance improvements in GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #15072: Teach the testsuite driver about response files
by GHC 05 Mar '19

05 Mar '19

#15072: Teach the testsuite driver about response files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Currently `T14697` is disabled on Windows as that test produces a long enough command-line (mostly `-D` flags) that it runs amok of the Windows command-line length limit. It seems like the solution here will be to teach the testsuite driver to invoke GHC with a response file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15072> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #16349: Nondeterministic T3424 timeouts on CI
by GHC 05 Mar '19

05 Mar '19

#16349: Nondeterministic T3424 timeouts 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 `T3424` test suite occasionally times out 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=20190221T105115Z&X-Amz- Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NPPHETCY4XXTOA/20190221 /us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz- Signature=521f4993a8af6215a34603cb8dfb26f10e3f2a335229227e65b92aa4ced557e9 one example] from a `validate-x86_64-linux-deb9-unreg` run: {{{ Timeout happened...killed process "cd "rts/T3424.run" && "/builds/ghc/ghc/inplace/bin/ghc-stage2" -o T3424 T3424.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -optc-fno-builtin -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output "... Compile failed (exit code 99) errors were: [1 of 1] Compiling Main ( T3424.hs, T3424.o ) *** unexpected failure for T3424(normal) <elided> Unexpected results from: TEST="T3424" SUMMARY for test run started at Thu Feb 21 05:18:04 2019 UTC 1:15:50 spent to go through 6839 total tests, which gave rise to 21103 test cases, of which 13986 were skipped 38 had missing libraries 6977 expected passes 101 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 0 unexpected stat failures Unexpected failures: rts/T3424.run T3424 [exit code non-0] (normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16349> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16201: ghci063 failing on Darwin
by GHC 05 Mar '19

05 Mar '19

#16201: ghci063 failing on Darwin ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- {{{#!diff --- /dev/null 2019-01-16 12:17:41.000000000 -0800 +++ ghci/scripts/ghci063.run/ghci063.run.stderr.normalised 2019-01-16 12:17:42.000000000 -0800 @@ -0,0 +1,2 @@ + +B.hs:1:1: parse error on input ‘***’ }}} The test in question is just a normal `ghci_script` test: {{{ :! echo module A where {} >A.hs :! echo module B where { import A } >B.hs :load B -- We're going to replace B.hs with an invalid module but without -- changing its timestamp. A :reload should *not* look at the -- contents of the file, because the timestamp hasn't changed. :! cp B.hs B.hs-copy :! touch -r B.hs B.hs-copy :! echo "*** INVALID ***" >B.hs :! touch -r B.hs-copy B.hs :reload -- Put the original file back, now it should work :! cp B.hs-copy B.hs :reload }}} I have no idea why GHCi would be trying to parse the `!echo`, much less only on Darwin. This is currently the last issue Darwin issue keeping us from setting `allow_failure` to false so I'm going to mark this as broken. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16201> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

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

05 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 05 Mar '19

05 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 05 Mar '19

05 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 05 Mar '19

05 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

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

05 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