- ghc-tickets - Haskell.org

[GHC] #16326: Implement visible dependent quantification
by GHC 04 Mar '19

04 Mar '19

#16326: Implement visible dependent quantification -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Keywords: GHCProposal | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15658 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC proposal 35 ([https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0035-forall-arrow.rst A syntax for visible dependent quantification]) has been accepted. This ticket tracks its implementation. Along with implementing it, we should also document it in the users' guide (the subject of #15658). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16326> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #16384: GHC infers ill-kinded type for typed TH splice with unlifted values
by GHC 04 Mar '19

04 Mar '19

#16384: GHC infers ill-kinded type for typed TH splice with unlifted values -------------------------------------+------------------------------------- Reporter: gridaphobe | 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: -------------------------------------+------------------------------------- As noted in the [https://github.com/ghc-proposals/ghc-proposals/pull/209 Levity Polymorphic Lift proposal], GHC infers an ill-kinded type for typed splices with unlifted values. For example, in GHC 8.6.3 {{{ ghci> :t [|| 1# ||] [|| 1# ||] :: Q (TExp Int#) }}} `TExp Int#` is ill-kinded, so this type makes no sense. And GHC knows it's ill-kinded, because it will actually reject the program if you supply the type yourself. {{{ ghci> [|| 1# ||] :: Q (TExp Int#) <interactive>:12:23: error: • Expecting a lifted type, but ‘Int#’ is unlifted • In the first argument of ‘TExp’, namely ‘Int#’ In the first argument of ‘Q’, namely ‘(TExp Int#)’ In an expression type signature: Q (TExp Int#) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16384> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13633: testwsdeque failure on POWER8
by GHC 04 Mar '19

04 Mar '19

#13633: testwsdeque failure on POWER8 ---------------------------------------+---------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Keywords: SMP | Operating System: Linux Architecture: powerpc64 | Type of failure: Runtime crash Test Case: rts/testwsdeque | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+---------------------------------- On a POWER8 `testwsdeque` fails occasionally under load: {{{ Wrong exit code for testwsdeque(threaded1)(expected 0 , actual 134 ) Stderr ( testwsdeque ): internal error: FAIL: 277808608 3 13 (GHC version 8.3.20170430 for powerpc64le_unknown_linux) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13633> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15658: strange inferred kind with TypeInType
by GHC 04 Mar '19

04 Mar '19

#15658: strange inferred kind with TypeInType -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 type family has a strange kind to begin with: {{{ {-# Language TypeFamilies , TypeInType #-} type family F f a :: a }}} But it gets even stranger when you ask ghci what it thinks about F: {{{ > :k F F :: * -> forall a -> a }}} There is a forall which doesn't seem to bind any variables and hasn't got the customary delimiting dot. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15658> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #16334: Named wildcards in kinds
by GHC 04 Mar '19

04 Mar '19

#16334: Named wildcards in kinds -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This works: {{{ Prelude> :set -XNamedWildCards -XPartialTypeSignatures -XPolyKinds Prelude> k :: (Int :: _); k = 42 <interactive>:2:14: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘*’ • In the type signature: k :: (Int :: _) }}} And this doesn't: {{{ Prelude> k :: (Int :: _t); k = 42 <interactive>:3:7: error: • Expected kind ‘_t’, but ‘Int’ has kind ‘*’ • In the type signature: k :: (Int :: _t) }}} The issue, I suspect, is in `partition_nwcs`, which ignores kind variables for some reason. I plan to fix it as part of https://gitlab.haskell.org/ghc/ghc/merge_requests/361 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16334> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

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

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

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

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

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

04 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