GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:13:43Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15225`-fno-state-hack` produces incorrect results in nofib2019-07-07T18:13:43ZTobias Dammerstdammers@gmail.com`-fno-state-hack` produces incorrect results in nofibWhile investigating #7411, I found that nofib fails with incorrect output from the `fasta` test.
A vanilla `prof` build behaves normally; however, with the following modifications, `nofib` fails:
- Compile GHC from scratch with:
> `
>...While investigating #7411, I found that nofib fails with incorrect output from the `fasta` test.
A vanilla `prof` build behaves normally; however, with the following modifications, `nofib` fails:
- Compile GHC from scratch with:
> `
> GhcStage2HcOpts = -O -fno-state-hack
> GhcLibHcOpts = -O -fno-state-hack
> `
- Run nofib with `EXTRA_HC_OPTS=-fno-state-hack`
Doing this, the nofib test output is:
```
------------------------------------------------------------------------
== make all --no-print-directory;
in /home/tobias/well-typed/devel/ghc/HEAD/nofib/shootout/fasta
------------------------------------------------------------------------
HC = /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2
HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring
RUNTEST_OPTS = -ghc-timing
==nofib== fasta: time to compile Main follows...
/home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring -c Main.hs -o Main.o
Main.hs:30:1: warning: [-Wtabs]
Tab character found here, and in 13 further locations.
Please use spaces instead.
|
30 | let !k = min modulus (floor (fromIntegral modulus * (p::Float) + 1))
| ^^^^^^^^
<<ghc: 401958512 bytes, 72 GCs, 10720054/28796976 avg/max bytes residency (6 samples), 61M in use, 0.001 INIT (0.001 elapsed), 0.342 MUT (0.420 elapsed), 0.240 GC (0.238 elapsed) :ghc>>
==nofib== fasta: size of Main.o follows...
text data bss dec hex filename
7245 2624 0 9869 268d Main.o
==nofib== fasta: time to link fasta follows...
<<ghc: 49626024 bytes, 45 GCs, 1356153/2672728 avg/max bytes residency (5 samples), 8M in use, 0.001 INIT (0.001 elapsed), 0.025 MUT (0.468 elapsed), 0.060 GC (0.060 elapsed) :ghc>>
==nofib== fasta: size of fasta follows...
text data bss dec hex filename
708996 127712 16232 852940 d03cc fasta
==nofib== fasta: time to run fasta follows...
../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000;
0.43user 0.02system 0:00.45elapsed 99%CPU (0avgtext+0avgdata 4824maxresident)k
0inputs+49656outputs (0major+608minor)pagefaults 0swaps
././fasta 2500000 < /dev/null
expected stdout not matched by reality
--- fasta.stdout 2018-06-02 03:00:43.887025433 +0200
+++ /tmp/runtest4673.1 2018-06-02 03:09:19.651755697 +0200
@@ -83337,333335 +83337,333335 @@
cttBtatcatatgctaKggNcataaaSatgtaaaDcDRtBggDtctttataattcBgtcg
-tactDtDagcctatttSVHtHttKtgtHMaSattgWaHKHttttagacatWatgtRgaaa
-NtactMcSMtYtcMgRtacttctWBacgaaatatagScDtttgaagacacatagtVgYgt
-cattHWtMMWcStgttaggKtSgaYaaccWStcgBttgcgaMttBYatcWtgacaYcaga
-gtaBDtRacttttcWatMttDBcatWtatcttactaBgaYtcttgttttttttYaaScYa
-HgtgttNtSatcMtcVaaaStccRcctDaataataStcYtRDSaMtDttgttSagtRRca
#### ~3.1 million similar lines follow ####
-taatataagctgcgccaggggatttttccagatcatctggcctgtgtatatgttcaaatc
+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt
+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt
+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt
#### ~208k identical lines follow
+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt
taatagccgagagaaattac
../../mk/target.mk:101: recipe for target 'runtests' failed
make[2]: *** [runtests] Error 1
Failed making all in fasta: 1
../mk/ghc-recurse.mk:65: recipe for target 'all' failed
make[1]: *** [all] Error 1
Failed making all in shootout: 1
mk/ghc-recurse.mk:65: recipe for target 'all' failed
make: *** [all] Error 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"`-fno-state-hack` produces incorrect results in nofib","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While investigating #7411, I found that nofib fails with incorrect output from the `fasta` test.\r\n\r\nA vanilla `prof` build behaves normally; however, with the following modifications, `nofib` fails:\r\n\r\n- Compile GHC from scratch with:\r\n {{{\r\n GhcStage2HcOpts = -O -fno-state-hack\r\n GhcLibHcOpts = -O -fno-state-hack\r\n }}}\r\n- Run nofib with `EXTRA_HC_OPTS=-fno-state-hack`\r\n\r\nDoing this, the nofib test output is:\r\n{{{\r\n------------------------------------------------------------------------\r\n== make all --no-print-directory;\r\n in /home/tobias/well-typed/devel/ghc/HEAD/nofib/shootout/fasta\r\n------------------------------------------------------------------------\r\nHC = /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2\r\nHC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring\r\nRUNTEST_OPTS = -ghc-timing\r\n==nofib== fasta: time to compile Main follows...\r\n/home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring -c Main.hs -o Main.o\r\n\r\nMain.hs:30:1: warning: [-Wtabs]\r\n Tab character found here, and in 13 further locations.\r\n Please use spaces instead.\r\n |\r\n30 | let !k = min modulus (floor (fromIntegral modulus * (p::Float) + 1))\r\n | ^^^^^^^^\r\n<<ghc: 401958512 bytes, 72 GCs, 10720054/28796976 avg/max bytes residency (6 samples), 61M in use, 0.001 INIT (0.001 elapsed), 0.342 MUT (0.420 elapsed), 0.240 GC (0.238 elapsed) :ghc>>\r\n==nofib== fasta: size of Main.o follows...\r\n text\t data\t bss\t dec\t hex\tfilename\r\n 7245\t 2624\t 0\t 9869\t 268d\tMain.o\r\n==nofib== fasta: time to link fasta follows...\r\n<<ghc: 49626024 bytes, 45 GCs, 1356153/2672728 avg/max bytes residency (5 samples), 8M in use, 0.001 INIT (0.001 elapsed), 0.025 MUT (0.468 elapsed), 0.060 GC (0.060 elapsed) :ghc>>\r\n==nofib== fasta: size of fasta follows...\r\n text\t data\t bss\t dec\t hex\tfilename\r\n 708996\t 127712\t 16232\t 852940\t d03cc\tfasta\r\n==nofib== fasta: time to run fasta follows...\r\n../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000;\r\n0.43user 0.02system 0:00.45elapsed 99%CPU (0avgtext+0avgdata 4824maxresident)k\r\n0inputs+49656outputs (0major+608minor)pagefaults 0swaps\r\n././fasta 2500000 < /dev/null\r\nexpected stdout not matched by reality\r\n--- fasta.stdout\t2018-06-02 03:00:43.887025433 +0200\r\n+++ /tmp/runtest4673.1\t2018-06-02 03:09:19.651755697 +0200\r\n@@ -83337,333335 +83337,333335 @@\r\n cttBtatcatatgctaKggNcataaaSatgtaaaDcDRtBggDtctttataattcBgtcg\r\n-tactDtDagcctatttSVHtHttKtgtHMaSattgWaHKHttttagacatWatgtRgaaa\r\n-NtactMcSMtYtcMgRtacttctWBacgaaatatagScDtttgaagacacatagtVgYgt\r\n-cattHWtMMWcStgttaggKtSgaYaaccWStcgBttgcgaMttBYatcWtgacaYcaga\r\n-gtaBDtRacttttcWatMttDBcatWtatcttactaBgaYtcttgttttttttYaaScYa\r\n-HgtgttNtSatcMtcVaaaStccRcctDaataataStcYtRDSaMtDttgttSagtRRca\r\n#### ~3.1 million similar lines follow ####\r\n-taatataagctgcgccaggggatttttccagatcatctggcctgtgtatatgttcaaatc\r\n+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt\r\n+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt\r\n+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt\r\n#### ~208k identical lines follow\r\n+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt\r\n taatagccgagagaaattac\r\n../../mk/target.mk:101: recipe for target 'runtests' failed\r\nmake[2]: *** [runtests] Error 1\r\nFailed making all in fasta: 1\r\n../mk/ghc-recurse.mk:65: recipe for target 'all' failed\r\nmake[1]: *** [all] Error 1\r\nFailed making all in shootout: 1\r\nmk/ghc-recurse.mk:65: recipe for target 'all' failed\r\nmake: *** [all] Error 1\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Tobias Dammerstdammers@gmail.comTobias Dammerstdammers@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/15226GHC doesn't know that seq# produces something in WHNF2023-12-18T14:30:21ZDavid FeuerGHC doesn't know that seq# produces something in WHNF```hs
data Str a = Str !a
bar :: Maybe a -> IO (Str (Maybe a))
bar x = do
x' <- evaluate x
pure (Str x')
```
This compiles to
```hs
Test.bar1
= \ (@ a_a3Ld)
(x_a3Ah :: Maybe a_a3Ld)
(s_i3Nz :: GHC.Prim.State# GHC.Prim...```hs
data Str a = Str !a
bar :: Maybe a -> IO (Str (Maybe a))
bar x = do
x' <- evaluate x
pure (Str x')
```
This compiles to
```hs
Test.bar1
= \ (@ a_a3Ld)
(x_a3Ah :: Maybe a_a3Ld)
(s_i3Nz :: GHC.Prim.State# GHC.Prim.RealWorld) ->
case GHC.Prim.seq#
@ (Maybe a_a3Ld) @ GHC.Prim.RealWorld x_a3Ah s_i3Nz
of
{ (# ipv_i3NC, ipv1_i3ND #) ->
(# ipv_i3NC, Test.$WStr @ (Maybe a_a3Ld) ipv1_i3ND #)
}
```
We suspend the application of `$WStr` to `ipv1_i3ND`, when all we actually need to do is apply `Str` directly. We could work around this in `base` by defining
```hs
evaluate x = IO $ \s ->
case seq# x s of
(# s', !x' #) -> (# s', x' #)
```
but that seems more than a little bit silly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC doesn't know that seq# produces something in WHNF","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"{{{#!hs\r\ndata Str a = Str !a\r\nbar :: Maybe a -> IO (Str (Maybe a))\r\nbar x = do\r\n x' <- evaluate x\r\n pure (Str x')\r\n}}}\r\n\r\nThis compiles to\r\n\r\n{{{#!hs\r\nTest.bar1\r\n = \\ (@ a_a3Ld)\r\n (x_a3Ah :: Maybe a_a3Ld)\r\n (s_i3Nz :: GHC.Prim.State# GHC.Prim.RealWorld) ->\r\n case GHC.Prim.seq#\r\n @ (Maybe a_a3Ld) @ GHC.Prim.RealWorld x_a3Ah s_i3Nz\r\n of\r\n { (# ipv_i3NC, ipv1_i3ND #) ->\r\n (# ipv_i3NC, Test.$WStr @ (Maybe a_a3Ld) ipv1_i3ND #)\r\n }\r\n}}}\r\n\r\nWe suspend the application of `$WStr` to `ipv1_i3ND`, when all we actually need to do is apply `Str` directly. We could work around this in `base` by defining\r\n\r\n{{{#!hs\r\nevaluate x = IO $ \\s ->\r\n case seq# x s of\r\n (# s', !x' #) -> (# s', x' #)\r\n}}}\r\n\r\nbut that seems more than a little bit silly.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15227Add PrelRules for par#2021-04-28T23:31:44ZDavid FeuerAdd PrelRules for par#`seq#` and `spark#` are elided when their arguments are known to be evaluated. `par#`, however, is not. Presumably this leads to sparks being created and then immediately going away.
<details><summary>Trac metadata</summary>
| Trac fie...`seq#` and `spark#` are elided when their arguments are known to be evaluated. `par#`, however, is not. Presumably this leads to sparks being created and then immediately going away.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add PrelRules for par#","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["Newcomer"],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"`seq#` and `spark#` are elided when their arguments are known to be evaluated. `par#`, however, is not. Presumably this leads to sparks being created and then immediately going away.","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/15228Remove use of showSDocUnsafe in extending_ghc.rst2019-07-07T18:13:42ZMatthew PickeringRemove use of showSDocUnsafe in extending_ghc.rstThere are lots of usages of `showSDocUnsafe` in `extending_ghc.rst`. However, they are all unnecessary as far as I could see because the `Hsc` or `TcM` context has a copy of `DynFlags` in it. It should be possible to replace them all wit...There are lots of usages of `showSDocUnsafe` in `extending_ghc.rst`. However, they are all unnecessary as far as I could see because the `Hsc` or `TcM` context has a copy of `DynFlags` in it. It should be possible to replace them all with `showSDoc`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove use of showSDocUnsafe in extending_ghc.rst","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"There are lots of usages of `showSDocUnsafe` in `extending_ghc.rst`. However, they are all unnecessary as far as I could see because the `Hsc` or `TcM` context has a copy of `DynFlags` in it. It should be possible to replace them all with `showSDoc`. ","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15229Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc2019-07-07T18:13:42ZMatthew PickeringRun typeCheckResultAction and renamedResultAction in TcM rather than HscThe primary motivation for this is that this allows users to access
the warnings and error machinery present in TcM. However, it also allows
users to use TcM actions which means they can typecheck GhcPs which
could be significantly easie...The primary motivation for this is that this allows users to access
the warnings and error machinery present in TcM. However, it also allows
users to use TcM actions which means they can typecheck GhcPs which
could be significantly easier than constructing GhcTc.
See https://phabricator.haskell.org/D4792
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["plugins"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The primary motivation for this is that this allows users to access\r\nthe warnings and error machinery present in TcM. However, it also allows\r\nusers to use TcM actions which means they can typecheck GhcPs which\r\ncould be significantly easier than constructing GhcTc.\r\n\r\nSee https://phabricator.haskell.org/D4792","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/15230unix tests fail under CircleCI's fedora environment2021-03-12T00:39:41ZBen Gamariunix tests fail under CircleCI's fedora environmentIt's a bit unclear what is going on here:
```
=====> getGroupEntryForName(normal) 6377 of 6403 [0, 0, 0]
Actual stdout output differs from expected:
--- ../../libraries/unix/tests/user001.run/user001.stdout.normalised 2018-06-05 15:18:3...It's a bit unclear what is going on here:
```
=====> getGroupEntryForName(normal) 6377 of 6403 [0, 0, 0]
Actual stdout output differs from expected:
--- ../../libraries/unix/tests/user001.run/user001.stdout.normalised 2018-06-05 15:18:37.243934191 +0000
+++ ../../libraries/unix/tests/user001.run/user001.run.stdout.normalised 2018-06-05 15:18:37.243934191 +0000
@@ -6,6 +6,6 @@
getEffectiveUserName: OK
getGroupEntryForID: OK
getGroupEntryForName: OK
-getAllGroupEntries: OK
+getAllGroupEntries: ERROR: getAllGroupEntries: does not exist (No such file or directory)
getUserEntryForID: OK
getAllUserEntries: OK
*** unexpected failure for user001(normal)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Continuous Integration |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"unix tests fail under CircleCI's fedora environment","status":"New","operating_system":"","component":"Continuous Integration","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It's a bit unclear what is going on here:\r\n\r\n{{{\r\n=====> getGroupEntryForName(normal) 6377 of 6403 [0, 0, 0]\r\nActual stdout output differs from expected:\r\n--- ../../libraries/unix/tests/user001.run/user001.stdout.normalised\t2018-06-05 15:18:37.243934191 +0000\r\n+++ ../../libraries/unix/tests/user001.run/user001.run.stdout.normalised\t2018-06-05 15:18:37.243934191 +0000\r\n@@ -6,6 +6,6 @@\r\n getEffectiveUserName: OK\r\n getGroupEntryForID: OK\r\n getGroupEntryForName: OK\r\n-getAllGroupEntries: OK\r\n+getAllGroupEntries: ERROR: getAllGroupEntries: does not exist (No such file or directory)\r\n getUserEntryForID: OK\r\n getAllUserEntries: OK\r\n*** unexpected failure for user001(normal)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15231UndecidableInstances validity checking is wrong in the presence of Quantified...2019-07-07T18:13:42ZRyan ScottUndecidableInstances validity checking is wrong in the presence of QuantifiedConstraintsConsider this program:
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE QuantifiedConstraints #-}
module Bug where
import Data.Kind
data ECC :: Constraint -> Type -> Type
clas...Consider this program:
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE QuantifiedConstraints #-}
module Bug where
import Data.Kind
data ECC :: Constraint -> Type -> Type
class Y a
class Z a
instance c => Y (ECC c a)
instance (c => Z a) => Z (ECC c a)
```
I would expect both of these instances to work. But while GHC accepts the `Y` instance, it rejects the `Z` instance:
```
$ ~/Software/ghc5/inplace/bin/ghc-stage2 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:15:10: error:
• Variable ‘c’ occurs more often
in the constraint ‘c’ than in the instance head
(Use UndecidableInstances to permit this)
• In the instance declaration for ‘Z (ECC c a)’
|
15 | instance (c => Z a) => Z (ECC c a)
| ^^^^^^^^^^^^^^^^^^^^^^^^^
```
That error message seems completely bogus to me, since `c` appears once in both the context and instance head in both instances.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"UndecidableInstances validity checking is wrong in the presence of QuantifiedConstraints","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["QuantifiedConstraints"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider this program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ConstraintKinds #-}\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE KindSignatures #-}\r\n{-# LANGUAGE QuantifiedConstraints #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\n\r\ndata ECC :: Constraint -> Type -> Type\r\n\r\nclass Y a\r\nclass Z a\r\n\r\ninstance c => Y (ECC c a)\r\ninstance (c => Z a) => Z (ECC c a)\r\n}}}\r\n\r\nI would expect both of these instances to work. But while GHC accepts the `Y` instance, it rejects the `Z` instance:\r\n\r\n{{{\r\n$ ~/Software/ghc5/inplace/bin/ghc-stage2 Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:15:10: error:\r\n • Variable ‘c’ occurs more often\r\n in the constraint ‘c’ than in the instance head\r\n (Use UndecidableInstances to permit this)\r\n • In the instance declaration for ‘Z (ECC c a)’\r\n |\r\n15 | instance (c => Z a) => Z (ECC c a)\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^\r\n}}}\r\n\r\nThat error message seems completely bogus to me, since `c` appears once in both the context and instance head in both instances.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15232TypeError is reported as "redundant constraint" starting with GHC 8.22019-07-07T18:13:41ZfsoikinTypeError is reported as "redundant constraint" starting with GHC 8.2The following program compiles fine on GHC 8.0.2, but GHC 8.2.2 issues a warning, complaining that `TypeError` is a redundant constraint. This makes it very inconvenient to use `TypeError` with type classes.
```hs
{-# OPTIONS_GHC -Wredu...The following program compiles fine on GHC 8.0.2, but GHC 8.2.2 issues a warning, complaining that `TypeError` is a redundant constraint. This makes it very inconvenient to use `TypeError` with type classes.
```hs
{-# OPTIONS_GHC -Wredundant-constraints -Wall -Werror #-}
import GHC.TypeLits (TypeError, ErrorMessage(..))
class C a where f :: a -> a
instance {-# OVERLAPPING #-} C Int where f _ = 42
instance {-# OVERLAPPABLE #-} TypeError ( 'Text "Only Int is supported" ) => C a where f = undefined
main :: IO ()
main = print $ f (42::Int)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TypeError is reported as \"redundant constraint\" starting with GHC 8.2","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["CustomTypeErrors"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program compiles fine on GHC 8.0.2, but GHC 8.2.2 issues a warning, complaining that `TypeError` is a redundant constraint. This makes it very inconvenient to use `TypeError` with type classes.\r\n\r\n{{{#!hs\r\n{-# OPTIONS_GHC -Wredundant-constraints -Wall -Werror #-}\r\nimport GHC.TypeLits (TypeError, ErrorMessage(..))\r\n\r\nclass C a where f :: a -> a\r\ninstance {-# OVERLAPPING #-} C Int where f _ = 42\r\ninstance {-# OVERLAPPABLE #-} TypeError ( 'Text \"Only Int is supported\" ) => C a where f = undefined\r\n\r\nmain :: IO ()\r\nmain = print $ f (42::Int)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15233You can always set fixity of (:), with no effect2019-07-07T18:13:41ZIcelandjackYou can always set fixity of (:), with no effectThis works in a normal file
```hs
infixl 5 :
```
or in ghci
```
$ ghci
GHCi, version 8.5.20180314: http://www.haskell.org/ghc/ :? for help
Prelude> infixr 5 :
Prelude>
```
and has no effect
<details><summary>Trac metadata</summary...This works in a normal file
```hs
infixl 5 :
```
or in ghci
```
$ ghci
GHCi, version 8.5.20180314: http://www.haskell.org/ghc/ :? for help
Prelude> infixr 5 :
Prelude>
```
and has no effect
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"You can always set fixity of (:), with no effect","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This works in a normal file\r\n\r\n{{{#!hs\r\ninfixl 5 :\r\n}}}\r\n\r\nor in ghci\r\n\r\n{{{\r\n$ ghci\r\nGHCi, version 8.5.20180314: http://www.haskell.org/ghc/ :? for help\r\nPrelude> infixr 5 :\r\nPrelude> \r\n}}}\r\n\r\nand has no effect","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15234WARNING in hptSomeThingsBelowUs when using a source plugin2019-07-07T18:13:41ZMatthew PickeringWARNING in hptSomeThingsBelowUs when using a source pluginWhen using a source plugin with a stage2 compiler built with the devel2 flavour, there are a fair few warnings about hptSomeThingsBelowUs.
```
WARNING in hptSomeThingsBelowUs
missing module CoercePlugin
Probable cause: out-of-date i...When using a source plugin with a stage2 compiler built with the devel2 flavour, there are a fair few warnings about hptSomeThingsBelowUs.
```
WARNING in hptSomeThingsBelowUs
missing module CoercePlugin
Probable cause: out-of-date interface files
```
I don't know if this just started happening or has been going on for a while. Is this warning cause for concern? Everything appears to work as expected despite this hiccup.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"WARNING in hptSomeThingsBelowUs when using a source plugin","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["SourcePlugins,","plugins"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When using a source plugin with a stage2 compiler built with the devel2 flavour, there are a fair few warnings about hptSomeThingsBelowUs.\r\n\r\n{{{\r\nWARNING in hptSomeThingsBelowUs\r\n missing module CoercePlugin\r\n Probable cause: out-of-date interface files\r\n}}}\r\n\r\nI don't know if this just started happening or has been going on for a while. Is this warning cause for concern? Everything appears to work as expected despite this hiccup. ","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15235GHCi's claim of infixr 0 (->) is a lie2019-12-05T07:35:14ZRyan ScottGHCi's claim of infixr 0 (->) is a lieCurrently, if you query the `:info` for `(->)` in GHCi, it will give you:
```
$ ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/ryanglscott/.ghci
λ> :i (->)
data (->) (a :: TYPE q)...Currently, if you query the `:info` for `(->)` in GHCi, it will give you:
```
$ ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/ryanglscott/.ghci
λ> :i (->)
data (->) (a :: TYPE q) (b :: TYPE r) -- Defined in ‘GHC.Prim’
infixr 0 `(->)`
<instances elided>
```
This fixity information appears to be plain wrong, as the following program demonstrates:
```hs
{-# LANGUAGE TypeOperators #-}
module Bug where
import Data.Type.Equality
type (~>) = (->)
infixr 0 ~>
f :: (a ~> b -> c) :~: (a ~> (b -> c))
f = Refl
```
Since `(~>)` and `(->)` are both `infixr 0`, I would expect `a ~> b -> c` to associate as `a ~> (b -> c)`, like the type signature for `f` wants to prove. However, GHC believes otherwise:
```
$ ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:10:5: error:
• Occurs check: cannot construct the infinite type: a ~ a ~> b
Expected type: ((a ~> b) -> c) :~: (a ~> (b -> c))
Actual type: ((a ~> b) -> c) :~: ((a ~> b) -> c)
• In the expression: Refl
In an equation for ‘f’: f = Refl
• Relevant bindings include
f :: ((a ~> b) -> c) :~: (a ~> (b -> c)) (bound at Bug.hs:10:1)
|
10 | f = Refl
| ^^^^
```
Reading the error message above, it appears that GHC gives `(->)` an even //lower// precedence than 0, since it associates `a ~> b -> c` as `(a ~> b) -> c`.
I'm not sure how to reconcile these two facts. There are at least a couple of options I can think of:
1. Claim `(->)` has a negative fixity.
1. Try to change GHC so that `(->)` really is `infixr 0`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi's claim of infixr 0 (->) is a lie","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently, if you query the `:info` for `(->)` in GHCi, it will give you:\r\n\r\n{{{\r\n$ ghci\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/ryanglscott/.ghci\r\nλ> :i (->)\r\ndata (->) (a :: TYPE q) (b :: TYPE r) -- Defined in ‘GHC.Prim’\r\ninfixr 0 `(->)`\r\n<instances elided>\r\n}}}\r\n\r\nThis fixity information appears to be plain wrong, as the following program demonstrates:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TypeOperators #-}\r\nmodule Bug where\r\n\r\nimport Data.Type.Equality\r\n\r\ntype (~>) = (->)\r\ninfixr 0 ~>\r\n\r\nf :: (a ~> b -> c) :~: (a ~> (b -> c))\r\nf = Refl\r\n}}}\r\n\r\nSince `(~>)` and `(->)` are both `infixr 0`, I would expect `a ~> b -> c` to associate as `a ~> (b -> c)`, like the type signature for `f` wants to prove. However, GHC believes otherwise:\r\n\r\n{{{\r\n$ ghc Bug.hs \r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o ) \r\n \r\nBug.hs:10:5: error: \r\n • Occurs check: cannot construct the infinite type: a ~ a ~> b \r\n Expected type: ((a ~> b) -> c) :~: (a ~> (b -> c))\r\n Actual type: ((a ~> b) -> c) :~: ((a ~> b) -> c)\r\n • In the expression: Refl\r\n In an equation for ‘f’: f = Refl\r\n • Relevant bindings include\r\n f :: ((a ~> b) -> c) :~: (a ~> (b -> c)) (bound at Bug.hs:10:1)\r\n |\r\n10 | f = Refl\r\n | ^^^^\r\n}}}\r\n\r\nReading the error message above, it appears that GHC gives `(->)` an even //lower// precedence than 0, since it associates `a ~> b -> c` as `(a ~> b) -> c`.\r\n\r\nI'm not sure how to reconcile these two facts. There are at least a couple of options I can think of:\r\n\r\n1. Claim `(->)` has a negative fixity.\r\n2. Try to change GHC so that `(->)` really is `infixr 0`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15236GHCi pretty-prints (->)'s fixity poorly2019-07-07T18:13:40ZRyan ScottGHCi pretty-prints (->)'s fixity poorlyConsider the following GHCi session:
```
$ ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> :i (->)
data (->) (a :: TYPE q) (b :: TYPE r) -- Defined in ‘GHC.Prim’...Consider the following GHCi session:
```
$ ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> :i (->)
data (->) (a :: TYPE q) (b :: TYPE r) -- Defined in ‘GHC.Prim’
infixr 0 `(->)`
<instances elided>
```
Notice that it prints:
```
`(->)`
```
Which is totally wrong. This should simply be `->`. Patch incoming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi pretty-prints (->)'s fixity poorly","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following GHCi session:\r\n\r\n{{{\r\n$ ghci\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\nλ> :i (->)\r\ndata (->) (a :: TYPE q) (b :: TYPE r) -- Defined in ‘GHC.Prim’\r\ninfixr 0 `(->)`\r\n<instances elided>\r\n}}}\r\n\r\nNotice that it prints:\r\n\r\n{{{\r\n`(->)`\r\n}}}\r\n\r\nWhich is totally wrong. This should simply be `->`. Patch incoming.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15237New SRT scheme breaks -fvia-C2019-07-07T18:13:40ZBen GamariNew SRT scheme breaks -fvia-CThe SRT rework implemented in 2b0918c9834be1873728176e4944bec26271234a introduces a sub-word-size field into `StgSRT`. Unfortunately `-fvia-C` doesn't support such fields. This breaks CircleCI's unregisterised target.
<details><summary>...The SRT rework implemented in 2b0918c9834be1873728176e4944bec26271234a introduces a sub-word-size field into `StgSRT`. Unfortunately `-fvia-C` doesn't support such fields. This breaks CircleCI's unregisterised target.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"New SRT scheme breaks -fvia-C","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The SRT rework implemented in 2b0918c9834be1873728176e4944bec26271234a introduces a sub-word-size field into `StgSRT`. Unfortunately `-fvia-C` doesn't support such fields. This breaks CircleCI's unregisterised target.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15238T13838 fails in ghci way2019-07-07T18:13:39ZBen GamariT13838 fails in ghci way```
Wrong exit code for T13838(ghci) (expected 1 , actual 0 )
Stderr ( T13838 ):
T13838:6:30: error:
• Couldn't match expected type ‘IO a0’ with actual type ‘() -> ()’
• Probable cause: ‘main’ is applied to too few arguments
...```
Wrong exit code for T13838(ghci) (expected 1 , actual 0 )
Stderr ( T13838 ):
T13838:6:30: error:
• Couldn't match expected type ‘IO a0’ with actual type ‘() -> ()’
• Probable cause: ‘main’ is applied to too few arguments
In the first argument of ‘GHC.TopHandler.runIOFastExit’, namely
‘main’
In the first argument of ‘(>>)’, namely
‘GHC.TopHandler.runIOFastExit main’
In the expression: GHC.TopHandler.runIOFastExit main >> return ()
*** unexpected failure for T13838(ghci)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"T13838 fails in ghci way","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nWrong exit code for T13838(ghci) (expected 1 , actual 0 )\r\nStderr ( T13838 ):\r\nT13838:6:30: error:\r\n • Couldn't match expected type ‘IO a0’ with actual type ‘() -> ()’\r\n • Probable cause: ‘main’ is applied to too few arguments\r\n In the first argument of ‘GHC.TopHandler.runIOFastExit’, namely\r\n ‘main’\r\n In the first argument of ‘(>>)’, namely\r\n ‘GHC.TopHandler.runIOFastExit main’\r\n In the expression: GHC.TopHandler.runIOFastExit main >> return ()\r\n*** unexpected failure for T13838(ghci)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15239Is there an issue with Haskell GHC 8.4.3 on Travis?2019-07-07T18:13:39ZOromeIs there an issue with Haskell GHC 8.4.3 on Travis?My Travis builds ([https://travis-ci.org/orome/crypto-enigma-hs/jobs/388291576](https://travis-ci.org/orome/crypto-enigma-hs/jobs/388291576)) are failing when they attempt to install using the nightly resolver (since 8.4.3) with:
```
...My Travis builds ([https://travis-ci.org/orome/crypto-enigma-hs/jobs/388291576](https://travis-ci.org/orome/crypto-enigma-hs/jobs/388291576)) are failing when they attempt to install using the nightly resolver (since 8.4.3) with:
```
$ stack --resolver $RESOLVER --no-terminal --install-ghc test --only-dependencies
Selected resolver: nightly-2018-06-05
Downloading nightly-2018-06-05 build plan ...
Downloaded nightly-2018-06-05 build plan.
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Preparing to download ghc-8.4.3 ...
ghc-8.4.3: download has begun
ghc-8.4.3: 15.21 MiB / 144.83 MiB ( 10.50%) downloaded...
ghc-8.4.3: 37.85 MiB / 144.83 MiB ( 26.13%) downloaded...
ghc-8.4.3: 61.16 MiB / 144.83 MiB ( 42.23%) downloaded...
ghc-8.4.3: 76.60 MiB / 144.83 MiB ( 52.89%) downloaded...
ghc-8.4.3: 91.49 MiB / 144.83 MiB ( 63.17%) downloaded...
ghc-8.4.3: 115.03 MiB / 144.83 MiB ( 79.42%) downloaded...
ghc-8.4.3: 138.27 MiB / 144.83 MiB ( 95.47%) downloaded...
ghc-8.4.3: 144.83 MiB / 144.83 MiB (100.00%) downloaded...
Downloaded ghc-8.4.3.
Unpacking GHC into /home/travis/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ ...
Configuring GHC ...
Installing GHC ...
Received ExitFailure 2 when running
Raw command: /usr/bin/make install
Run from: /home/travis/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/
The command "stack --resolver $RESOLVER --no-terminal --install-ghc test --only-dependencies" failed and exited with 1 during .
```
Is there a problem with 8.4.3 on Travis?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Is there an issue with Haskell GHC 8.4.3 on Travis?","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"My Travis builds ([https://travis-ci.org/orome/crypto-enigma-hs/jobs/388291576]) are failing when they attempt to install using the nightly resolver (since 8.4.3) with: \r\n\r\n\r\n{{{\r\n $ stack --resolver $RESOLVER --no-terminal --install-ghc test --only-dependencies\r\n Selected resolver: nightly-2018-06-05\r\n Downloading nightly-2018-06-05 build plan ...\r\n Downloaded nightly-2018-06-05 build plan.\r\n Preparing to install GHC to an isolated location.\r\n This will not interfere with any system-level installation.\r\n Preparing to download ghc-8.4.3 ...\r\n ghc-8.4.3: download has begun\r\n ghc-8.4.3: 15.21 MiB / 144.83 MiB ( 10.50%) downloaded...\r\n ghc-8.4.3: 37.85 MiB / 144.83 MiB ( 26.13%) downloaded...\r\n ghc-8.4.3: 61.16 MiB / 144.83 MiB ( 42.23%) downloaded...\r\n ghc-8.4.3: 76.60 MiB / 144.83 MiB ( 52.89%) downloaded...\r\n ghc-8.4.3: 91.49 MiB / 144.83 MiB ( 63.17%) downloaded...\r\n ghc-8.4.3: 115.03 MiB / 144.83 MiB ( 79.42%) downloaded...\r\n ghc-8.4.3: 138.27 MiB / 144.83 MiB ( 95.47%) downloaded...\r\n ghc-8.4.3: 144.83 MiB / 144.83 MiB (100.00%) downloaded...\r\n Downloaded ghc-8.4.3.\r\n Unpacking GHC into /home/travis/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ ...\r\n Configuring GHC ...\r\n Installing GHC ...\r\n Received ExitFailure 2 when running\r\n Raw command: /usr/bin/make install\r\n Run from: /home/travis/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/\r\n The command \"stack --resolver $RESOLVER --no-terminal --install-ghc test --only-dependencies\" failed and exited with 1 during .\r\n}}}\r\n\r\n\r\nIs there a problem with 8.4.3 on Travis?","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15240GHCi's :doc doesn't find the documentation for some class methods2019-07-07T18:13:39ZSimon JakobiGHCi's :doc doesn't find the documentation for some class methodsWhile `:doc` reliably finds the docs for classes like Foldable and Monad, it fails for some methods.
```
λ :doc return
Inject a value into the monadic type.
λ :doc foldr
<has no documentation>
λ :doc show
<has no documentation>
```
So...While `:doc` reliably finds the docs for classes like Foldable and Monad, it fails for some methods.
```
λ :doc return
Inject a value into the monadic type.
λ :doc foldr
<has no documentation>
λ :doc show
<has no documentation>
```
So far I haven't been able to see a pattern there.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | alexbiehl, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi's :doc doesn't find the documentation for some class methods","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["alexbiehl","hvr"],"type":"Bug","description":"While `:doc` reliably finds the docs for classes like Foldable and Monad, it fails for some methods.\r\n\r\n{{{\r\nλ :doc return\r\n Inject a value into the monadic type.\r\nλ :doc foldr\r\n<has no documentation>\r\nλ :doc show\r\n<has no documentation>\r\n}}}\r\n\r\nSo far I haven't been able to see a pattern there.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Simon JakobiSimon Jakobihttps://gitlab.haskell.org/ghc/ghc/-/issues/15242Typechecker sometimes doesn't preserve HsPar in original source.2019-07-07T18:13:38ZZubinTypechecker sometimes doesn't preserve HsPar in original source.The typechecker doesn't preserve parenthesis that occur at the head of applications.
This results in some weird SrcSpans in the TypecheckedSource
For example, given code
```hs
foo a b c = (bar a) b c
```
The typechecker will emit an ...The typechecker doesn't preserve parenthesis that occur at the head of applications.
This results in some weird SrcSpans in the TypecheckedSource
For example, given code
```hs
foo a b c = (bar a) b c
```
The typechecker will emit an HsApp with head spanning over `bar a) b` and tail spanning over `c`.
Notice that the opening parenthesis is not included.
On the other hand, the renamer will generate the expected SrcSpans that always include both parenthesis, or neither. This becomes an issue when you want to associate RenamedSource with its corresponding TypecheckedSource, as the SrcSpans no longer match and overlap partially.
This occurs due to this line in TcExpr.hs
```hs
tcApp m_herald (L _ (HsPar _ fun)) args res_ty
= tcApp m_herald fun args res_ty
```
I have a work in progress fix here: https://github.com/wz1000/ghc/commit/3b6db5a35dc8677a7187e349a85ffd51f452452a
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | alanz, bgamari, gbaz |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typechecker sometimes doesn't preserve HsPar in original source.","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["alanz","bgamari","gbaz"],"type":"Bug","description":"The typechecker doesn't preserve parenthesis that occur at the head of applications.\r\n\r\nThis results in some weird SrcSpans in the TypecheckedSource\r\n\r\nFor example, given code\r\n\r\n{{{#!hs\r\nfoo a b c = (bar a) b c\r\n}}}\r\n\r\nThe typechecker will emit an HsApp with head spanning over `bar a) b` and tail spanning over `c`.\r\nNotice that the opening parenthesis is not included.\r\n\r\nOn the other hand, the renamer will generate the expected SrcSpans that always include both parenthesis, or neither. This becomes an issue when you want to associate RenamedSource with its corresponding TypecheckedSource, as the SrcSpans no longer match and overlap partially.\r\n\r\nThis occurs due to this line in TcExpr.hs\r\n\r\n{{{#!hs\r\ntcApp m_herald (L _ (HsPar _ fun)) args res_ty\r\n = tcApp m_herald fun args res_ty\r\n}}}\r\n\r\nI have a work in progress fix here: https://github.com/wz1000/ghc/commit/3b6db5a35dc8677a7187e349a85ffd51f452452a","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15243-ddump-splices shenanigans: promoted tycons aren't ticked2019-07-07T18:13:38ZRyan Scott-ddump-splices shenanigans: promoted tycons aren't tickedConsider the following program with a type family that contains four different promoted (i.e., ticked) type constructors:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeFami...Consider the following program with a type family that contains four different promoted (i.e., ticked) type constructors:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeFamilies #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug where
data Unit = Unit
$([d| type family F (a :: k) :: k where
F 'Unit = 'Unit
F '(,) = '(,)
F '[] = '[]
F '(:) = '(:)
|])
```
```
$ /opt/ghc/8.4.3/bin/ghci Bug3.hs
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug3.hs, interpreted )
Bug3.hs:(10,3)-(15,6): Splicing declarations
[d| type family F_a1xJ (a_a1xL :: k_a1xK) :: k_a1xK where
F_a1xJ 'Unit = 'Unit
F_a1xJ '(,) = '(,)
F_a1xJ '[] = '[]
F_a1xJ '(:) = '(:) |]
======>
type family F_a49g (a_a49i :: k_a49h) :: k_a49h where
F_a49g Unit = Unit
F_a49g GHC.Tuple.(,) = GHC.Tuple.(,)
F_a49g '[] = '[]
F_a49g (GHC.Types.:) = (GHC.Types.:)
Ok, one module loaded.
```
The `-ddump-splices` output is quite strange: `'[]` is ticked, but the other three are not! This seems off.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-ddump-splices shenanigans: promoted tycons aren't ticked","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following program with a type family that contains four different promoted (i.e., ticked) type constructors:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DataKinds #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# OPTIONS_GHC -ddump-splices #-}\r\nmodule Bug where\r\n\r\ndata Unit = Unit\r\n\r\n$([d| type family F (a :: k) :: k where\r\n F 'Unit = 'Unit\r\n F '(,) = '(,)\r\n F '[] = '[]\r\n F '(:) = '(:)\r\n |])\r\n}}}\r\n{{{\r\n$ /opt/ghc/8.4.3/bin/ghci Bug3.hs\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug3.hs, interpreted )\r\nBug3.hs:(10,3)-(15,6): Splicing declarations\r\n [d| type family F_a1xJ (a_a1xL :: k_a1xK) :: k_a1xK where\r\n F_a1xJ 'Unit = 'Unit\r\n F_a1xJ '(,) = '(,)\r\n F_a1xJ '[] = '[]\r\n F_a1xJ '(:) = '(:) |]\r\n ======>\r\n type family F_a49g (a_a49i :: k_a49h) :: k_a49h where\r\n F_a49g Unit = Unit\r\n F_a49g GHC.Tuple.(,) = GHC.Tuple.(,)\r\n F_a49g '[] = '[]\r\n F_a49g (GHC.Types.:) = (GHC.Types.:)\r\nOk, one module loaded.\r\n}}}\r\n\r\nThe `-ddump-splices` output is quite strange: `'[]` is ticked, but the other three are not! This seems off.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15244Ambiguity checks in QuantifiedConstraints2020-01-20T14:59:39ZbitwiseshiftleftAmbiguity checks in QuantifiedConstraintsGreat work on QuantifiedConstraints! I'm giving it a whirl. With GHCI 8.5.20180605, I see somewhat annoying behavior around multiple instances. When two copies of the same (or equivalent) quantified constraint are in scope, they produce ...Great work on QuantifiedConstraints! I'm giving it a whirl. With GHCI 8.5.20180605, I see somewhat annoying behavior around multiple instances. When two copies of the same (or equivalent) quantified constraint are in scope, they produce an error. I think this is about some kind of ambiguity check.
```
{-# LANGUAGE QuantifiedConstraints, TypeFamilies #-}
class (forall t . Eq (c t)) => Blah c
-- Unquantified works
foo :: (Eq (a t), Eq (b t), a ~ b) => a t -> b t -> Bool
foo a b = a == b
-- Works
-- Two quantified instances fail with double ambiguity check errors
bar :: (forall t . Eq (a t), forall t . Eq (b t), a ~ b) => a t -> b t -> Bool
bar a b = a == b
-- Minimal.hs:11:8: error:
-- • Could not deduce (Eq (b t1))
-- from the context: (forall t1. Eq (a t1), forall t1. Eq (b t1),
-- a ~ b)
-- bound by the type signature for:
-- bar :: forall (a :: * -> *) (b :: * -> *) t.
-- (forall t1. Eq (a t1), forall t1. Eq (b t1), a ~ b) =>
-- a t -> b t -> Bool
-- at Minimal.hs:11:8-78
-- • In the ambiguity check for ‘bar’
-- To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
-- In the type signature:
-- bar :: (forall t. Eq (a t), forall t. Eq (b t), a ~ b) =>
-- a t -> b t -> Bool
-- |
-- 11 | bar :: (forall t . Eq (a t), forall t . Eq (b t), a ~ b) => a t -> b t -> Bool
-- |
-- [And then another copy of the same error]
-- Two copies from superclass instances fail
baz :: (Blah a, Blah b, a ~ b) => a t -> b t -> Bool
baz a b = a == b
-- Minimal.hs:34:11: error:
-- • Could not deduce (Eq (b t)) arising from a use of ‘==’
-- from the context: (Blah a, Blah b, a ~ b)
-- bound by the type signature for:
-- baz :: forall (a :: * -> *) (b :: * -> *) t.
-- (Blah a, Blah b, a ~ b) =>
-- a t -> b t -> Bool
-- at Minimal.hs:33:1-52
-- • In the expression: a == b
-- In an equation for ‘baz’: baz a b = a == b
-- |
-- 34 | baz a b = a == b
-- |
-- Two copies from superclass from same declaration also fail
mugga :: (Blah a, Blah a) => a t -> a t -> Bool
mugga a b = a == b
-- • Could not deduce (Eq (a t)) arising from a use of ‘==’
-- from the context: (Blah a, Blah a)
-- bound by the type signature for:
-- mugga :: forall (a :: * -> *) t.
-- (Blah a, Blah a) =>
-- a t -> a t -> Bool
-- at Minimal.hs:50:1-47
-- • In the expression: a == b
-- In an equation for ‘mugga’: mugga a b = a == b
-- |
-- 51 | mugga a b = a == b
-- |
-- One copy works
quux :: (Blah a, a ~ b) => a t -> b t -> Bool
quux a b = a == b
-- Works
```
My program is similar to `Baz`. The constraints `Blah a` and `Blah b` are in scope from a pattern match, and I want to compare values of types `a t` and `b t` if they're the same type. So I get `a ~ b` from Typeable and try to compare them, but this doesn't work. I worked around the issue by writing a helper that only takes `(Blah a, Typeable a, Typeable b)`, so only one instance is in scope.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Ambiguity checks in QuantifiedConstraints","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["QuantifiedConstraints"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Great work on QuantifiedConstraints! I'm giving it a whirl. With GHCI 8.5.20180605, I see somewhat annoying behavior around multiple instances. When two copies of the same (or equivalent) quantified constraint are in scope, they produce an error. I think this is about some kind of ambiguity check.\r\n\r\n{{{\r\n{-# LANGUAGE QuantifiedConstraints, TypeFamilies #-}\r\n\r\nclass (forall t . Eq (c t)) => Blah c\r\n\r\n-- Unquantified works\r\nfoo :: (Eq (a t), Eq (b t), a ~ b) => a t -> b t -> Bool\r\nfoo a b = a == b\r\n-- Works\r\n \r\n-- Two quantified instances fail with double ambiguity check errors\r\nbar :: (forall t . Eq (a t), forall t . Eq (b t), a ~ b) => a t -> b t -> Bool\r\nbar a b = a == b\r\n-- Minimal.hs:11:8: error:\r\n-- • Could not deduce (Eq (b t1))\r\n-- from the context: (forall t1. Eq (a t1), forall t1. Eq (b t1),\r\n-- a ~ b)\r\n-- bound by the type signature for:\r\n-- bar :: forall (a :: * -> *) (b :: * -> *) t.\r\n-- (forall t1. Eq (a t1), forall t1. Eq (b t1), a ~ b) =>\r\n-- a t -> b t -> Bool\r\n-- at Minimal.hs:11:8-78\r\n-- • In the ambiguity check for ‘bar’\r\n-- To defer the ambiguity check to use sites, enable AllowAmbiguousTypes\r\n-- In the type signature:\r\n-- bar :: (forall t. Eq (a t), forall t. Eq (b t), a ~ b) =>\r\n-- a t -> b t -> Bool\r\n-- |\r\n-- 11 | bar :: (forall t . Eq (a t), forall t . Eq (b t), a ~ b) => a t -> b t -> Bool\r\n-- |\r\n-- [And then another copy of the same error]\r\n\r\n-- Two copies from superclass instances fail\r\nbaz :: (Blah a, Blah b, a ~ b) => a t -> b t -> Bool\r\nbaz a b = a == b\r\n-- Minimal.hs:34:11: error:\r\n-- • Could not deduce (Eq (b t)) arising from a use of ‘==’\r\n-- from the context: (Blah a, Blah b, a ~ b)\r\n-- bound by the type signature for:\r\n-- baz :: forall (a :: * -> *) (b :: * -> *) t.\r\n-- (Blah a, Blah b, a ~ b) =>\r\n-- a t -> b t -> Bool\r\n-- at Minimal.hs:33:1-52\r\n-- • In the expression: a == b\r\n-- In an equation for ‘baz’: baz a b = a == b\r\n-- |\r\n-- 34 | baz a b = a == b\r\n-- | \r\n\r\n-- Two copies from superclass from same declaration also fail\r\nmugga :: (Blah a, Blah a) => a t -> a t -> Bool\r\nmugga a b = a == b\r\n-- • Could not deduce (Eq (a t)) arising from a use of ‘==’\r\n-- from the context: (Blah a, Blah a)\r\n-- bound by the type signature for:\r\n-- mugga :: forall (a :: * -> *) t.\r\n-- (Blah a, Blah a) =>\r\n-- a t -> a t -> Bool\r\n-- at Minimal.hs:50:1-47\r\n-- • In the expression: a == b\r\n-- In an equation for ‘mugga’: mugga a b = a == b\r\n-- |\r\n-- 51 | mugga a b = a == b\r\n-- |\r\n\r\n-- One copy works\r\nquux :: (Blah a, a ~ b) => a t -> b t -> Bool\r\nquux a b = a == b\r\n-- Works\r\n}}}\r\n\r\nMy program is similar to {{{Baz}}}. The constraints {{{Blah a}}} and {{{Blah b}}} are in scope from a pattern match, and I want to compare values of types {{{a t}}} and {{{b t}}} if they're the same type. So I get {{{a ~ b}}} from Typeable and try to compare them, but this doesn't work. I worked around the issue by writing a helper that only takes {{{(Blah a, Typeable a, Typeable b)}}}, so only one instance is in scope.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15245Data family promotion is possible2021-11-06T12:06:45ZVladislav ZavialovData family promotion is possibleThe User's Guide states that data families cannot be promoted, even with `-XTypeInType`:
> We promote data types and newtypes; type synonyms and type/data families are not promoted.
>
> The flag TypeInType (which implies DataKinds) rela...The User's Guide states that data families cannot be promoted, even with `-XTypeInType`:
> We promote data types and newtypes; type synonyms and type/data families are not promoted.
>
> The flag TypeInType (which implies DataKinds) relaxes some of these restrictions, allowing:
>
> Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types.
And yet the following code typechecks and runs:
```hs
{-# LANGUAGE TypeFamilies, TypeInType, TypeApplications #-}
import Type.Reflection
data family K
data instance K = MkK
main = print (typeRep @'MkK)
```
Is this a GHC bug or a documentation bug? I asked in IRC but I'm still confused:
```
<int-index> The user guide states that data families aren't promoted even when -XTypeInType is enabled. Where's the logic that ensures this? I checked with `data family K; data instance K = MkK` and I can use `'MkK` with no errors/warnings.
<int-index> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#overview "Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types."
<int-index> Is this info outdated?
<RyanGlScott> int-index: Is this in GHCi?
<RyanGlScott> It certainly fails in GHC
<RyanGlScott> But I think I understand why the former works
<int-index> RyanGlScott, yes, I'm checking this in GHCi
<RyanGlScott> int-index: So here's my understanding of how this works
<RyanGlScott> GHC kind-checks top-level declarations using a rather primitive SCC analysis
<RyanGlScott> In particular, it's primitive in the sense that data family instances give it a lot of trouble
<RyanGlScott> If you tried taking your code and putting it into a standalone .hs file and compiling that, then it would definitely complain about a promoted use of MkT
<RyanGlScott> As luck would have it, though, you were trying things out in GHCi
<RyanGlScott> Which essentially checks each line of input as its own strongly connected group of declarations
<RyanGlScott> So you can define MkT on one line and promote it in subsequent lines, since they're separate in the sense
<RyanGlScott> *that sense
<int-index> this sounds related to Trac #12088, and then I could work around it in GHC by using `$(return [])`, so data families are actually promoted anyway and this has nothing to do with GHC needing more powerful type theory
<RyanGlScott> Well, it does need more powerful type theory in the sense that that's a prerequisite for making the SCC analysis for kind-checking sophisticated enough to handle this
<RyanGlScott> But yes, it's quite simple to work around by using Template Haskell to explicitly split up groups.
<int-index> https://gist.github.com/int-index/c6cc1e20c4b9b5c99af40ee4e23ecb61 this works and no template haskell involved
<int-index> The reason I'm asking is that I'm touching this part of the User's Guide and I don't know what to write there.
<RyanGlScott> Huh, now that's interesting
<int-index> RyanGlScott, the only check I could find that controls what's promoted and what's not is 'isLegacyPromotableDataCon' - and enabling -XTypeInType disables this check.
<RyanGlScott> int-index: Right, that's baffling me
<RyanGlScott> Since that's supposed to be checked every time you promote a data constructor (I think)
<RyanGlScott> int-index: File a bug about that, I suppose
<RyanGlScott> Richard (who's sitting next to me right now) seems to think that that shouldn't be possible
<int-index> RyanGlScott, the thing is, I happily removed this check completely in D4748. Does this mean I have to restore a weaker version of it that only checks for data families? Why?
<int-index> Is it bad that -XDataKinds promotes data family constructors? Looks like I can just remove the "restrictions" part of the user guide and be done with it
<RyanGlScott> int-index: In theory, that shouldn't be possible
<int-index> OK, then what the check should be? No data families, any other restrictions?
<RyanGlScott> I might qualify that with "no data family instances defined in the same module"
<RyanGlScott> (Or to be precise, in the same SCC, but that's probably too technical for the users' guide)
<int-index> Well, this sounds hard to check. I was thinking along the lines of keeping the 'not (isFamInstTyCon (dataConTyCon dc))' part of the check...
<RyanGlScott> Oh, I thought you were only changing the users' guide :)
<int-index> Well, at this point I'm confused if I should change only the user guide or the check as well. If data families shouldn't be promoted ever, then I'll change GHC. If the limitation is about the current SCC group, I can just mention Trac #12088 as a known infelicity in the User's Guide
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | RyanGlScott, goldfire |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data family promotion is possible","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":["RyanGlScott","goldfire"],"type":"Bug","description":"The User's Guide states that data families cannot be promoted, even with `-XTypeInType`:\r\n\r\n> We promote data types and newtypes; type synonyms and type/data families are not promoted.\r\n>\r\n> The flag TypeInType (which implies DataKinds) relaxes some of these restrictions, allowing:\r\n>\r\n> Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types.\r\n\r\nAnd yet the following code typechecks and runs:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TypeFamilies, TypeInType, TypeApplications #-}\r\n\r\nimport Type.Reflection\r\n\r\ndata family K\r\ndata instance K = MkK\r\n\r\nmain = print (typeRep @'MkK)\r\n}}}\r\n\r\nIs this a GHC bug or a documentation bug? I asked in IRC but I'm still confused:\r\n\r\n{{{\r\n<int-index> The user guide states that data families aren't promoted even when -XTypeInType is enabled. Where's the logic that ensures this? I checked with `data family K; data instance K = MkK` and I can use `'MkK` with no errors/warnings.\r\n<int-index> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#overview \"Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types.\"\r\n<int-index> Is this info outdated?\r\n<RyanGlScott> int-index: Is this in GHCi?\r\n<RyanGlScott> It certainly fails in GHC\r\n<RyanGlScott> But I think I understand why the former works\r\n<int-index> RyanGlScott, yes, I'm checking this in GHCi\r\n<RyanGlScott> int-index: So here's my understanding of how this works\r\n<RyanGlScott> GHC kind-checks top-level declarations using a rather primitive SCC analysis\r\n<RyanGlScott> In particular, it's primitive in the sense that data family instances give it a lot of trouble\r\n<RyanGlScott> If you tried taking your code and putting it into a standalone .hs file and compiling that, then it would definitely complain about a promoted use of MkT\r\n<RyanGlScott> As luck would have it, though, you were trying things out in GHCi\r\n<RyanGlScott> Which essentially checks each line of input as its own strongly connected group of declarations\r\n<RyanGlScott> So you can define MkT on one line and promote it in subsequent lines, since they're separate in the sense\r\n<RyanGlScott> *that sense\r\n<int-index> this sounds related to Trac #12088, and then I could work around it in GHC by using `$(return [])`, so data families are actually promoted anyway and this has nothing to do with GHC needing more powerful type theory\r\n<RyanGlScott> Well, it does need more powerful type theory in the sense that that's a prerequisite for making the SCC analysis for kind-checking sophisticated enough to handle this\r\n<RyanGlScott> But yes, it's quite simple to work around by using Template Haskell to explicitly split up groups.\r\n<int-index> https://gist.github.com/int-index/c6cc1e20c4b9b5c99af40ee4e23ecb61 this works and no template haskell involved\r\n<int-index> The reason I'm asking is that I'm touching this part of the User's Guide and I don't know what to write there.\r\n<RyanGlScott> Huh, now that's interesting\r\n<int-index> RyanGlScott, the only check I could find that controls what's promoted and what's not is 'isLegacyPromotableDataCon' - and enabling -XTypeInType disables this check.\r\n<RyanGlScott> int-index: Right, that's baffling me\r\n<RyanGlScott> Since that's supposed to be checked every time you promote a data constructor (I think)\r\n<RyanGlScott> int-index: File a bug about that, I suppose\r\n<RyanGlScott> Richard (who's sitting next to me right now) seems to think that that shouldn't be possible\r\n<int-index> RyanGlScott, the thing is, I happily removed this check completely in D4748. Does this mean I have to restore a weaker version of it that only checks for data families? Why?\r\n<int-index> Is it bad that -XDataKinds promotes data family constructors? Looks like I can just remove the \"restrictions\" part of the user guide and be done with it\r\n<RyanGlScott> int-index: In theory, that shouldn't be possible\r\n<int-index> OK, then what the check should be? No data families, any other restrictions?\r\n<RyanGlScott> I might qualify that with \"no data family instances defined in the same module\"\r\n<RyanGlScott> (Or to be precise, in the same SCC, but that's probably too technical for the users' guide)\r\n<int-index> Well, this sounds hard to check. I was thinking along the lines of keeping the 'not (isFamInstTyCon (dataConTyCon dc))' part of the check...\r\n<RyanGlScott> Oh, I thought you were only changing the users' guide :)\r\n<int-index> Well, at this point I'm confused if I should change only the user guide or the check as well. If data families shouldn't be promoted ever, then I'll change GHC. If the limitation is about the current SCC group, I can just mention Trac #12088 as a known infelicity in the User's Guide\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15246-fghci-leak-cheak causes many testsuite failures with the quick build flavour2019-07-07T18:13:38ZRyan Scott-fghci-leak-cheak causes many testsuite failures with the quick build flavourAs [originally reported](https://mail.haskell.org/pipermail/ghc-devs/2018-May/015812.html) on the ghc-devs mailing list, the `-fghci-leak-check` flag is causing several tests to fail when GHC is built with the quick build flavour. On my ...As [originally reported](https://mail.haskell.org/pipermail/ghc-devs/2018-May/015812.html) on the ghc-devs mailing list, the `-fghci-leak-check` flag is causing several tests to fail when GHC is built with the quick build flavour. On my machine, here are all the tests that fail:
```
Unexpected failures:
ghci/prog001/prog001.run prog001 [bad stdout] (ghci)
ghci/prog002/prog002.run prog002 [bad stdout] (ghci)
ghci/prog003/prog003.run prog003 [bad stdout] (ghci)
ghci/prog010/ghci.prog010.run ghci.prog010 [bad stdout] (ghci)
ghci/prog013/prog013.run prog013 [bad stdout] (ghci)
ghci/prog012/prog012.run prog012 [bad stdout] (ghci)
ghci/prog009/ghci.prog009.run ghci.prog009 [bad stdout] (ghci)
ghci/scripts/ghci025.run ghci025 [bad stdout] (ghci)
ghci/scripts/ghci038.run ghci038 [bad stdout] (ghci)
ghci/scripts/ghci057.run ghci057 [bad stdout] (ghci)
ghci/scripts/T2182ghci.run T2182ghci [bad stdout] (ghci)
ghci/scripts/ghci058.run ghci058 [bad stdout] (ghci)
ghci/scripts/T6106.run T6106 [bad stdout] (ghci)
ghci/scripts/T8353.run T8353 [bad stdout] (ghci)
ghci/scripts/T9293.run T9293 [bad stdout] (ghci)
ghci/scripts/T10989.run T10989 [bad stdout] (ghci)
ghci/should_run/T13825-ghci.run T13825-ghci [bad stdout] (ghci)
ghci.debugger/scripts/print007.run print007 [bad stdout] (ghci)
ghci.debugger/scripts/break009.run break009 [bad stdout] (ghci)
ghci.debugger/scripts/break008.run break008 [bad stdout] (ghci)
ghci.debugger/scripts/break026.run break026 [bad stdout] (ghci)
perf/space_leaks/T4029.run T4029 [bad stdout] (ghci)
```
[Here](https://gist.githubusercontent.com/RyanGlScott/f920737287049b82947e1c47cdbc2b94/raw/4fe68d47cc78675424e09cf451be556c6f430d08/gistfile1.txt) is the full test output. Generally, the test output discrepancies are all of the form of extra lines of:
```
+-fghci-leak-check: HomeModInfo for D is still alive!
+-fghci-leak-check: ModIface is still alive!
+-fghci-leak-check: ModDetails is still alive!
+-fghci-leak-check: Linkable is still alive!
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-fghci-leak-cheak causes many testsuite failures with the quick build flavour","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"As [https://mail.haskell.org/pipermail/ghc-devs/2018-May/015812.html originally reported] on the ghc-devs mailing list, the `-fghci-leak-check` flag is causing several tests to fail when GHC is built with the quick build flavour. On my machine, here are all the tests that fail:\r\n\r\n{{{\r\nUnexpected failures:\r\n ghci/prog001/prog001.run prog001 [bad stdout] (ghci)\r\n ghci/prog002/prog002.run prog002 [bad stdout] (ghci)\r\n ghci/prog003/prog003.run prog003 [bad stdout] (ghci)\r\n ghci/prog010/ghci.prog010.run ghci.prog010 [bad stdout] (ghci)\r\n ghci/prog013/prog013.run prog013 [bad stdout] (ghci)\r\n ghci/prog012/prog012.run prog012 [bad stdout] (ghci)\r\n ghci/prog009/ghci.prog009.run ghci.prog009 [bad stdout] (ghci)\r\n ghci/scripts/ghci025.run ghci025 [bad stdout] (ghci)\r\n ghci/scripts/ghci038.run ghci038 [bad stdout] (ghci)\r\n ghci/scripts/ghci057.run ghci057 [bad stdout] (ghci)\r\n ghci/scripts/T2182ghci.run T2182ghci [bad stdout] (ghci)\r\n ghci/scripts/ghci058.run ghci058 [bad stdout] (ghci)\r\n ghci/scripts/T6106.run T6106 [bad stdout] (ghci)\r\n ghci/scripts/T8353.run T8353 [bad stdout] (ghci)\r\n ghci/scripts/T9293.run T9293 [bad stdout] (ghci)\r\n ghci/scripts/T10989.run T10989 [bad stdout] (ghci)\r\n ghci/should_run/T13825-ghci.run T13825-ghci [bad stdout] (ghci)\r\n ghci.debugger/scripts/print007.run print007 [bad stdout] (ghci)\r\n ghci.debugger/scripts/break009.run break009 [bad stdout] (ghci)\r\n ghci.debugger/scripts/break008.run break008 [bad stdout] (ghci)\r\n ghci.debugger/scripts/break026.run break026 [bad stdout] (ghci)\r\n perf/space_leaks/T4029.run T4029 [bad stdout] (ghci)\r\n}}}\r\n\r\n[https://gist.githubusercontent.com/RyanGlScott/f920737287049b82947e1c47cdbc2b94/raw/4fe68d47cc78675424e09cf451be556c6f430d08/gistfile1.txt Here] is the full test output. Generally, the test output discrepancies are all of the form of extra lines of:\r\n\r\n{{{\r\n+-fghci-leak-check: HomeModInfo for D is still alive!\r\n+-fghci-leak-check: ModIface is still alive!\r\n+-fghci-leak-check: ModDetails is still alive!\r\n+-fghci-leak-check: Linkable is still alive!\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15247Use empty types for TTG extension constructors2021-11-22T14:29:38ZAdam GundryUse empty types for TTG extension constructorsI happened to be looking at `AmbiguousFieldOcc` and noticed that it has gained an `XAmbiguousFieldOcc` extension constructor for Trees That Grow, but lots of the destructor functions in `HsTypes` panic if they see this constructor (which...I happened to be looking at `AmbiguousFieldOcc` and noticed that it has gained an `XAmbiguousFieldOcc` extension constructor for Trees That Grow, but lots of the destructor functions in `HsTypes` panic if they see this constructor (which is understandable, because they aren't expecting extensions).
In general, perhaps it should be the case that for concrete phase descriptors (e.g. `GhcRn`) where extension constructors are not expected, the extension constructor argument type should be empty? It would then be clear that they should not be expected (barring abuse of laziness) and pattern matching on them could eliminate the empty type.
That is, instead of the existing
```hs
data NoExt = NoExt
type instance XXAmbiguousFieldOcc (GhcPass _) = NoExt
```
we would define
```hs
data NoExtConstructor -- empty data type
noExtConstructor :: NoExtConstructor -> a
noExtConstructor x = case x of {}
type instance XXAmbiguousFieldOcc (GhcPass _) = NoExtConstructor
```
and similarly for other `XX...` type families.
Alan, Shayan, is there any reason this couldn't work?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.5 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Shayan-Najd, alanz |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Use empty types for TTG extension constructors","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["TTG"],"differentials":[],"test_case":"","architecture":"","cc":["Shayan-Najd","alanz"],"type":"Task","description":"I happened to be looking at `AmbiguousFieldOcc` and noticed that it has gained an `XAmbiguousFieldOcc` extension constructor for Trees That Grow, but lots of the destructor functions in `HsTypes` panic if they see this constructor (which is understandable, because they aren't expecting extensions).\r\n\r\nIn general, perhaps it should be the case that for concrete phase descriptors (e.g. `GhcRn`) where extension constructors are not expected, the extension constructor argument type should be empty? It would then be clear that they should not be expected (barring abuse of laziness) and pattern matching on them could eliminate the empty type.\r\n\r\nThat is, instead of the existing\r\n{{{#!hs\r\ndata NoExt = NoExt\r\n\r\ntype instance XXAmbiguousFieldOcc (GhcPass _) = NoExt\r\n}}}\r\nwe would define\r\n{{{#!hs\r\ndata NoExtConstructor -- empty data type\r\n\r\nnoExtConstructor :: NoExtConstructor -> a\r\nnoExtConstructor x = case x of {}\r\n\r\ntype instance XXAmbiguousFieldOcc (GhcPass _) = NoExtConstructor\r\n}}}\r\nand similarly for other `XX...` type families.\r\n\r\nAlan, Shayan, is there any reason this couldn't work?","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/15254Cabal submodule bump is needed2019-07-07T18:13:36ZquasicomputationalCabal submodule bump is neededCabal HEAD has recently been somewhat broken (https://github.com/haskell/cabal/issues/5318) and the current submodule is pointing to a buggy commit. This only manifests when installing `build-type: Custom` packages, because that uses the...Cabal HEAD has recently been somewhat broken (https://github.com/haskell/cabal/issues/5318) and the current submodule is pointing to a buggy commit. This only manifests when installing `build-type: Custom` packages, because that uses the bad code from the bootstrap Cabal; `build-type: Simple` will use good code from the external `cabal-install` process.
Please bump the Cabal submodule to fix this. I've verified that the observed problem (`happy` breaking) goes away when this is done.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cabal submodule bump is needed","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Cabal HEAD has recently been somewhat broken (https://github.com/haskell/cabal/issues/5318) and the current submodule is pointing to a buggy commit. This only manifests when installing `build-type: Custom` packages, because that uses the bad code from the bootstrap Cabal; `build-type: Simple` will use good code from the external `cabal-install` process.\r\n\r\nPlease bump the Cabal submodule to fix this. I've verified that the observed problem (`happy` breaking) goes away when this is done.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15255overflow1 breaks on i3862019-07-07T18:13:36ZBen Gamarioverflow1 breaks on i386The i386 CircleCI target is showing a mysterious failure of the `overflow1` test:
```
=====> overflow1(normal) 4082 of 6414 [0, 3, 0]
Wrong exit code for overflow1(normal)(expected 251 , actual 0 )
*** unexpected failure for overflow1(n...The i386 CircleCI target is showing a mysterious failure of the `overflow1` test:
```
=====> overflow1(normal) 4082 of 6414 [0, 3, 0]
Wrong exit code for overflow1(normal)(expected 251 , actual 0 )
*** unexpected failure for overflow1(normal)
```
Need to work out what is going on here.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Continuous Integration |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"overflow1 breaks on i386","status":"New","operating_system":"","component":"Continuous Integration","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The i386 CircleCI target is showing a mysterious failure of the `overflow1` test:\r\n{{{\r\n=====> overflow1(normal) 4082 of 6414 [0, 3, 0]\r\nWrong exit code for overflow1(normal)(expected 251 , actual 0 )\r\n*** unexpected failure for overflow1(normal)\r\n}}}\r\n\r\nNeed to work out what is going on here.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15259Out-of-scope-variables error still can be deferred in ghci2019-07-07T18:13:35ZTao Hesighingnow@gmail.comOut-of-scope-variables error still can be deferred in ghciDeferring type errors is unhelpful in ghci, since the expression is evaluated immediately. In #11130, we disabled typed holes in ghci as well. The `-fdefer-out-of-scope-variables` should also be disabled in ghci.
<details><summary>Trac ...Deferring type errors is unhelpful in ghci, since the expression is evaluated immediately. In #11130, we disabled typed holes in ghci as well. The `-fdefer-out-of-scope-variables` should also be disabled in ghci.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Out-of-scope-variables error still can be deferred in ghci","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Deferring type errors is unhelpful in ghci, since the expression is evaluated immediately. In #11130, we disabled typed holes in ghci as well. The `-fdefer-out-of-scope-variables` should also be disabled in ghci.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Tobias Dammerstdammers@gmail.comTobias Dammerstdammers@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/15260Xmobar crashes with segmentation fault2019-07-07T18:13:35ZVoronweXmobar crashes with segmentation faultOS: Arch
Kernel version: 4.16.13-2-ARCH
Xmobar version: 0.26
ghc version: 8.4.3
Xmobar crashes after some time (1 sec or 1 day - very different each time).
And, as I see, reasons are different to:
1:
```
voronwe@sul ~> xmobar
Fields ...OS: Arch
Kernel version: 4.16.13-2-ARCH
Xmobar version: 0.26
ghc version: 8.4.3
Xmobar crashes after some time (1 sec or 1 day - very different each time).
And, as I see, reasons are different to:
1:
```
voronwe@sul ~> xmobar
Fields missing from config defaulted: additionalFonts,wmClass,wmName,border,borderColor,textOffset,iconOffset,iconRoot,alpha
xmobar: internal error: evacuate: strange closure type 4689
(GHC version 8.4.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
fish: 'xmobar' terminated by signal SIGABRT (Abort)
```
2:
```
voronwe@sul ~> xmobar
Fields missing from config defaulted: additionalFonts,wmClass,wmName,border,borderColor,textOffset,iconOffset,iconRoot,alpha
fish: 'xmobar' terminated by signal SIGSEGV (Address boundary error)
```
See my issue on xmobar github for details: https://github.com/jaor/xmobar/issues/354
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Xmobar crashes with segmentation fault","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"OS: Arch\r\nKernel version: 4.16.13-2-ARCH\r\nXmobar version: 0.26\r\nghc version: 8.4.3\r\n\r\nXmobar crashes after some time (1 sec or 1 day - very different each time).\r\nAnd, as I see, reasons are different to:\r\n\r\n1:\r\n{{{\r\nvoronwe@sul ~> xmobar \r\nFields missing from config defaulted: additionalFonts,wmClass,wmName,border,borderColor,textOffset,iconOffset,iconRoot,alpha\r\nxmobar: internal error: evacuate: strange closure type 4689\r\n (GHC version 8.4.3 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nfish: 'xmobar' terminated by signal SIGABRT (Abort)\r\n}}}\r\n\r\n2:\r\n{{{\r\nvoronwe@sul ~> xmobar \r\nFields missing from config defaulted: additionalFonts,wmClass,wmName,border,borderColor,textOffset,iconOffset,iconRoot,alpha\r\nfish: 'xmobar' terminated by signal SIGSEGV (Address boundary error)\r\n}}}\r\nSee my issue on xmobar github for details: https://github.com/jaor/xmobar/issues/354","type_of_failure":"OtherFailure","blocking":[]} -->8.4.4https://gitlab.haskell.org/ghc/ghc/-/issues/15261Show -with-rtsopts options in runtime's --info2019-07-07T18:13:35ZÖmer Sinan AğacanShow -with-rtsopts options in runtime's --infoAs far as I know currently we don't have a way to show `-with-rtsopts` options provided when compiling an executable. It'd be useful if `--info` showed this. Some use cases:
- When you have multiple binaries of the same program you can ...As far as I know currently we don't have a way to show `-with-rtsopts` options provided when compiling an executable. It'd be useful if `--info` showed this. Some use cases:
- When you have multiple binaries of the same program you can see how each one is compiled. Useful when debugging.
- Sometimes we instruct users saying "compile with this and run with that". This steps becomes easier with `-with-rtsopts` because with that the user doesn't have to pass runtime parameters. But currently we don't have an easy way check if the users did it right. If `+RTS --info` showed this information we could say "look at the info, you should see this and that".
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Show -with-rtsopts options in runtime's --info","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"As far as I know currently we don't have a way to show `-with-rtsopts` options provided when compiling an executable. It'd be useful if `--info` showed this. Some use cases:\r\n\r\n- When you have multiple binaries of the same program you can see how each one is compiled. Useful when debugging.\r\n- Sometimes we instruct users saying \"compile with this and run with that\". This steps becomes easier with `-with-rtsopts` because with that the user doesn't have to pass runtime parameters. But currently we don't have an easy way check if the users did it right. If `+RTS --info` showed this information we could say \"look at the info, you should see this and that\".","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/15262GHC and iserv cannot agree on what an Integer is; insanity ensues2020-06-19T14:35:19ZhowtonotwinGHC and iserv cannot agree on what an Integer is; insanity ensuesTested off `ghc-8.6.1-alpha1`, running on macOS 10.13.5.
1. Compile a GHC that uses `integer-gmp`.
2. Compile a GHC that uses `integer-simple`.
3. Make `Main.hs`:
> ```haskell
> {-# LANGUAGE TemplateHaskell #-}
...Tested off `ghc-8.6.1-alpha1`, running on macOS 10.13.5.
1. Compile a GHC that uses `integer-gmp`.
2. Compile a GHC that uses `integer-simple`.
3. Make `Main.hs`:
> ```haskell
> {-# LANGUAGE TemplateHaskell #-}
> main = print $([e| 0 |])
> ```
4. Try to compile the file with `integer-gmp` `ghc` and `integer-simple` `ghc-iserv`.
* Expected behavior: (compiles fine and executable prints `0`) or (outputs to-the-point error message)
* Actual:
```none
[1 of 1] Compiling Main ( Main.hs, Main.o )
Main.hs:2:14: error:
• Exception when trying to run compile-time code:
ghc: ghc-iserv terminated (-11)
Code: [| 0 |]
• In the untyped splice: $([| 0 |])
|
2 | main = print $([e| 0 |])
| ^^^^^^^^^^^
```
4. Try to compile the file with `integer-simple` `ghc` and `integer-gmp` `ghc-iserv`.
* Expected behavior: (compiles fine and executable prints `0`) or (outputs to-the-point error message)
* Actual:
```none
[1 of 1] Compiling Main ( Main.hs, Main.o )
Main.hs:2:14: error:
• Exception when trying to run compile-time code:
heap overflow
Code: [| 0 |]
• In the untyped splice: $([| 0 |])
|
2 | main = print $([e| 0 |])
| ^^^^^^^^^^^
```
For more fun, replace the `0` with a `1`. `gmp` `ghc` + `simple` `iserv` continues to explode. This is better than `simple` `ghc` + `gmp` `iserv`:
```bash
$ ./Main
283468057265
$ ./Main
283468057265
$ $simple_ghc -fexternal-interpreter -pgmi=$gmp_iserv Main.hs # again
# ...
$ ./Main
283468057105
```
Absolutely delicious. There is a similar situation for fractional literals.
It would be nice if there were at least a warning for situations like this.9.0.1John EricsonJohn Ericsonhttps://gitlab.haskell.org/ghc/ghc/-/issues/15263Fuse zipWith32019-07-07T18:13:34ZRichard Eisenbergrae@richarde.devFuse zipWith3I was surprised to discover that `zipWith3` has no `RULES` associated with it to aid fusion.
Can we add these?
I have no idea what I'm doing, but would this substitution work:
```
{-# RULES "zipWith3"
zipWith3 f a b c = zipWith id (zi...I was surprised to discover that `zipWith3` has no `RULES` associated with it to aid fusion.
Can we add these?
I have no idea what I'm doing, but would this substitution work:
```
{-# RULES "zipWith3"
zipWith3 f a b c = zipWith id (zipWith f a b) c
#-}
```
Those who know what they're doing will likely devise a better strategy.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Fuse zipWith3","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was surprised to discover that `zipWith3` has no `RULES` associated with it to aid fusion.\r\n\r\nCan we add these?\r\n\r\nI have no idea what I'm doing, but would this substitution work:\r\n\r\n{{{\r\n{-# RULES \"zipWith3\"\r\nzipWith3 f a b c = zipWith id (zipWith f a b) c\r\n#-}\r\n}}}\r\n\r\nThose who know what they're doing will likely devise a better strategy.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Tobias DeckingTobias Deckinghttps://gitlab.haskell.org/ghc/ghc/-/issues/15264Warn about implicit kind variables with -Wcompat2019-07-07T18:13:34ZVladislav ZavialovWarn about implicit kind variables with -WcompatAccording to an accepted proposal https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst:
> With `-Wcompat`, warn if a kind variable is brought into scope implicitly in a type with an explicit `forall...According to an accepted proposal https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst:
> With `-Wcompat`, warn if a kind variable is brought into scope implicitly in a type with an explicit `forall`. This applies to type signatures and to other contexts that allow a `forall` with the forall-or-nothing rule in effect (for example, class instances).
Creating ticket just for the record. Implementation coming soon.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15265Print result summary in test suite when interrupted2019-07-07T18:13:33ZÖmer Sinan AğacanPrint result summary in test suite when interruptedIt'd be helpful if the test runner showed summary of the tests run so far when it's interrupted. This is useful when working on new features: I sometimes run the test suite only to realize something's broken and I'm getting lots of failu...It'd be helpful if the test runner showed summary of the tests run so far when it's interrupted. This is useful when working on new features: I sometimes run the test suite only to realize something's broken and I'm getting lots of failures. At this point no need to wait until it completes so I interrupt the process, but this doesn't print the summary of the tests run so far, so I have to use terminal scrollback and manually list failing tests etc.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Print result summary in test suite when interrupted","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"It'd be helpful if the test runner showed summary of the tests run so far when it's interrupted. This is useful when working on new features: I sometimes run the test suite only to realize something's broken and I'm getting lots of failures. At this point no need to wait until it completes so I interrupt the process, but this doesn't print the summary of the tests run so far, so I have to use terminal scrollback and manually list failing tests etc.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15266Add QuantifiedConstraints to release notes2020-06-23T23:16:09ZRichard Eisenbergrae@richarde.devAdd QuantifiedConstraints to release notesIt seems `-XQuantifiedConstraints` never made it into the release notes. We should fix this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version ...It seems `-XQuantifiedConstraints` never made it into the release notes. We should fix this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add QuantifiedConstraints to release notes","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It seems `-XQuantifiedConstraints` never made it into the release notes. We should fix this.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15268Clarify and test the interaction of -with-rtsopts and -rtsopts flags2019-07-07T18:13:31ZÖmer Sinan AğacanClarify and test the interaction of -with-rtsopts and -rtsopts flagsLooking at the user manual it's not clear how do `-with-rtsopts` and `-rtsopts` flags interact. I'd expect `-with-rtsopts` to work even with `-rtsopts=ignoreAll`, but I don't know if this is really the case, and because we don't have a w...Looking at the user manual it's not clear how do `-with-rtsopts` and `-rtsopts` flags interact. I'd expect `-with-rtsopts` to work even with `-rtsopts=ignoreAll`, but I don't know if this is really the case, and because we don't have a way to print RTS flags (see #15261 for this) it's hard to make sure this works as expected.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | AndreasK |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Clarify and test the interaction of -with-rtsopts and -rtsopts flags","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["AndreasK"],"type":"Task","description":"Looking at the user manual it's not clear how do `-with-rtsopts` and `-rtsopts` flags interact. I'd expect `-with-rtsopts` to work even with `-rtsopts=ignoreAll`, but I don't know if this is really the case, and because we don't have a way to print RTS flags (see #15261 for this) it's hard to make sure this works as expected.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15269Qualified Names in --show-iface output2019-07-07T18:13:30ZSimon JakobiQualified Names in --show-iface output## Motivation
In the Hi Haddock project we use tests based on the `--show-iface` mode.
In the `.hi`-files we dump, we list the `Name`s that may correspond to an identifier found in a docstring. In the case of ambiguous identifiers, it ...## Motivation
In the Hi Haddock project we use tests based on the `--show-iface` mode.
In the `.hi`-files we dump, we list the `Name`s that may correspond to an identifier found in a docstring. In the case of ambiguous identifiers, it would be nice to see the module names of the corresponding `Name`s, so we can tell them apart.
For example, for a module containing a docstring `"'elem'"` and a declaration for `elem`, we would currently see:
```
"elem":
elem
elem
```
One `elem` refers to the local one, the other to the one in the `Prelude`.
What I'd like to see instead is
```
"elem":
Data.Foldable.elem
MyModule.elem
```
If the output would also contain package names and/or ids, I wouldn't mind.
## Possible solutions
- In [D4806](https://phabricator.haskell.org/D4806), I proposed to hardcode qualification for `--show-iface`. But this may create unwanted noise in different usecases.
- If I could use `-dppr-debug` with `--show-iface` I would do that. Currently I get the following error if try:
`
Warning: the following files would be used as linker inputs, but linking is not being done: NoExportList.hi
-dppr-debug: openBinaryFile: does not exist (No such file or directory)
`8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/152711e1000000000 :: Double yields 0.0 instead of Infinity2019-07-07T18:13:30Zclaude1e1000000000 :: Double yields 0.0 instead of Infinity(This bug report is about the incorrect result not the poor performance.)
Very large positive exponent in floating point literal at Double type gives `0` instead of `Infinity` in `ghci-8.4.3` (self-compiled on Debian Buster x86_64 / amd...(This bug report is about the incorrect result not the poor performance.)
Very large positive exponent in floating point literal at Double type gives `0` instead of `Infinity` in `ghci-8.4.3` (self-compiled on Debian Buster x86_64 / amd64):
```
$ ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Prelude> :set +s
Prelude> 1e100000000 :: Double
Infinity
(5.70 secs, 68,552 bytes)
Prelude> 1e1000000000 :: Double
0.0
(69.35 secs, 60,088 bytes)
```
Writing `10^` instead of `1e` completes almost instantly with the correct result (`Infinity`) in both cases.
More precisely,
```
Prelude> 1e646457008 :: Double
Infinity
(40.80 secs, 64,272 bytes)
Prelude> 1e646457009 :: Double
0.0
(40.46 secs, 60,088 bytes)
```
Note:
```hs
(floor $ 2^31 / logBase 2 10 + 16) == 646457009
```
This vague numerology makes me think something C `int`-related is overflowing somewhere (GMP? integer-gmp? GHC?).
Standalone test program:
```hs
main = do
print 1e646457008
print 1e646457009
```
Interestingly, it doesn't occur, or at least not near the same threshold, in 32-bit `ghci-8.0.1` (Debian Stretch i686), though it aborts when getting too large (the 32-bit i686 machine has 1GB RAM and 4GB swap, the 64-bit x86_64/amd64 has 32GB RAM). The sheer time it takes to run makes bisecting the exact threshold on i686 not something I want to take on (though if someone writes some code that can do it programmatically I'd be happy to run it overnight if it would help).
```
$ ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Prelude> :set +s
Prelude> 1e646457008 :: Double
Infinity
(415.26 secs, 17,908 bytes)
Prelude> 1e646457009 :: Double
Infinity
(417.66 secs, 17,820 bytes)
Prelude> 1e746457298 :: Double
Infinity
(490.00 secs, 17,820 bytes)
Prelude> 1e1000000000 :: Double
GNU MP: Cannot allocate memory (size=419438600)
Aborted
$
```
`ghci-8.0.2` on Debian Buster amd64 exhibits the problem also.8.6.3Zhou FangyiZhou Fangyihttps://gitlab.haskell.org/ghc/ghc/-/issues/15273Datatypes with CUSKs should quantify over unknown kinds2019-07-07T18:13:29ZRichard Eisenbergrae@richarde.devDatatypes with CUSKs should quantify over unknown kindsIn [the future](https://github.com/ghc-proposals/ghc-proposals/pull/54), we will be able to give full kind signatures to datatype declarations. But in the present, we use CUSKs to write kind signatures.
However, consider
```hs
data T (...In [the future](https://github.com/ghc-proposals/ghc-proposals/pull/54), we will be able to give full kind signatures to datatype declarations. But in the present, we use CUSKs to write kind signatures.
However, consider
```hs
data T (a :: Proxy k)
```
That has a CUSK, according to the CUSK rules. Yet we don't know the kind of `k`. Currently, this definition is rejected, accusing the user of lying about having a complete kind. However, let's instead pretend the user had written
```hs
type T :: Proxy k -> Type
data T a
```
After all, that's what the CUSK is shorthand for. In this case, it's clear that we should infer `T :: forall k1 (k :: k1). Proxy k -> Type`, just the way we would do with a term-level type signature.
This turns out to be quite easy. See [D4845](https://phabricator.haskell.org/D4845).
This change allows strictly more programs to be accepted, and I think it falls under the threshold for requiring a proposal.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Datatypes with CUSKs should quantify over unknown kinds","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In [https://github.com/ghc-proposals/ghc-proposals/pull/54 the future], we will be able to give full kind signatures to datatype declarations. But in the present, we use CUSKs to write kind signatures.\r\n\r\nHowever, consider\r\n\r\n{{{#!hs\r\ndata T (a :: Proxy k)\r\n}}}\r\n\r\nThat has a CUSK, according to the CUSK rules. Yet we don't know the kind of `k`. Currently, this definition is rejected, accusing the user of lying about having a complete kind. However, let's instead pretend the user had written\r\n\r\n{{{#!hs\r\ntype T :: Proxy k -> Type\r\ndata T a\r\n}}}\r\n\r\nAfter all, that's what the CUSK is shorthand for. In this case, it's clear that we should infer `T :: forall k1 (k :: k1). Proxy k -> Type`, just the way we would do with a term-level type signature.\r\n\r\nThis turns out to be quite easy. See Phab:D4845.\r\n\r\nThis change allows strictly more programs to be accepted, and I think it falls under the threshold for requiring a proposal.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15274Numerous validation failures when building GHC with LLVM2019-07-07T18:13:29ZBen GamariNumerous validation failures when building GHC with LLVMThe CircleCI x86_64/Linux LLVM way exhibits numerous testsuite failures:
```
Unexpected results from:
TEST="CPUTime001 ClosedFam1TH T10828 T10891 T11341 T11345 T11463 T11721_TH T11797 T12403 T12646 T12962 T13642 T13887 T14060 T1835 T222...The CircleCI x86_64/Linux LLVM way exhibits numerous testsuite failures:
```
Unexpected results from:
TEST="CPUTime001 ClosedFam1TH T10828 T10891 T11341 T11345 T11463 T11721_TH T11797 T12403 T12646 T12962 T13642 T13887 T14060 T1835 T2222 T2552 T2700 T3920 T4135 T4188 T5037 T5358 T5362 T5363 T5559 T680 T7477 T8761 T8884 T8953 T9064 T9262 T9692 TH_PromotedList TH_RichKinds TH_RichKinds2 TH_Roles3 TH_TyInstWhere2 TH_foreignCallingConventions TH_reifyDecl1 TH_reifyDecl2 TH_reifyInstances TH_repE2 TH_repGuard TH_repPrim TH_repPrim2 TH_repUnboxedTuples posix002 prof-doc-fib prof-doc-last profinline001 scc001 scc002 scc003 scc005"
SUMMARY for test run started at Mon Jun 18 08:57:25 2018 UTC
1:18:58 spent to go through
6443 total tests, which gave rise to
25148 test cases, of which
4810 were skipped
229 had missing libraries
19825 expected passes
227 expected failures
0 caused framework failures
0 caused framework warnings
0 unexpected passes
57 unexpected failures
0 unexpected stat failures
Unexpected failures:
profiling/should_run/scc001.run scc001 [bad exit code] (ghci-ext-prof)
profiling/should_run/scc002.run scc002 [bad exit code] (ghci-ext-prof)
profiling/should_run/scc003.run scc003 [bad exit code] (ghci-ext-prof)
profiling/should_run/scc005.run scc005 [bad exit code] (ghci-ext-prof)
profiling/should_run/T680.run T680 [bad exit code] (ghci-ext-prof)
profiling/should_run/T2552.run T2552 [bad exit code] (ghci-ext-prof)
profiling/should_run/prof-doc-fib.run prof-doc-fib [bad exit code] (ghci-ext-prof)
profiling/should_run/T5559.run T5559 [bad exit code] (ghci-ext-prof)
profiling/should_run/prof-doc-last.run prof-doc-last [bad exit code] (ghci-ext-prof)
profiling/should_run/profinline001.run profinline001 [bad exit code] (ghci-ext-prof)
profiling/should_run/T5363.run T5363 [bad exit code] (ghci-ext-prof)
profiling/should_run/T12962.run T12962 [bad exit code] (ghci-ext-prof)
th/TH_repPrim.run TH_repPrim [exit code non-0] (ext-interp)
th/TH_repPrim2.run TH_repPrim2 [exit code non-0] (ext-interp)
th/TH_repUnboxedTuples.run TH_repUnboxedTuples [exit code non-0] (ext-interp)
th/TH_repGuard.run TH_repGuard [exit code non-0] (ext-interp)
th/TH_repE2.run TH_repE2 [exit code non-0] (ext-interp)
th/TH_reifyDecl1.run TH_reifyDecl1 [exit code non-0] (ext-interp)
th/TH_reifyDecl2.run TH_reifyDecl2 [exit code non-0] (ext-interp)
th/TH_reifyInstances.run TH_reifyInstances [exit code non-0] (ext-interp)
th/T2700.run T2700 [exit code non-0] (ext-interp)
th/TH_foreignCallingConventions.run TH_foreignCallingConventions [exit code non-0] (ext-interp)
th/T4188.run T4188 [exit code non-0] (ext-interp)
th/T3920.run T3920 [exit code non-0] (ext-interp)
th/T5037.run T5037 [exit code non-0] (ext-interp)
th/T5362.run T5362 [exit code non-0] (ext-interp)
th/T1835.run T1835 [exit code non-0] (ext-interp)
th/T5358.run T5358 [stderr mismatch] (ext-interp)
th/TH_PromotedList.run TH_PromotedList [exit code non-0] (ext-interp)
th/TH_RichKinds.run TH_RichKinds [exit code non-0] (ext-interp)
th/TH_RichKinds2.run TH_RichKinds2 [exit code non-0] (ext-interp)
th/T4135.run T4135 [exit code non-0] (ext-interp)
th/TH_TyInstWhere2.run TH_TyInstWhere2 [exit code non-0] (ext-interp)
th/T2222.run T2222 [exit code non-0] (ext-interp)
th/ClosedFam1TH.run ClosedFam1TH [exit code non-0] (ext-interp)
th/TH_Roles3.run TH_Roles3 [exit code non-0] (ext-interp)
th/T7477.run T7477 [exit code non-0] (ext-interp)
th/T8884.run T8884 [exit code non-0] (ext-interp)
th/T9262.run T9262 [exit code non-0] (ext-interp)
th/T9692.run T9692 [exit code non-0] (ext-interp)
th/T8953.run T8953 [exit code non-0] (ext-interp)
th/T9064.run T9064 [exit code non-0] (ext-interp)
th/T10828.run T10828 [exit code non-0] (ext-interp)
th/T10891.run T10891 [exit code non-0] (ext-interp)
th/T11341.run T11341 [exit code non-0] (ext-interp)
th/T11345.run T11345 [exit code non-0] (ext-interp)
th/T11721_TH.run T11721_TH [exit code non-0] (ext-interp)
th/T11797.run T11797 [exit code non-0] (ext-interp)
th/T11463.run T11463 [exit code non-0] (ext-interp)
th/T8761.run T8761 [exit code non-0] (ext-interp)
th/T12403.run T12403 [exit code non-0] (ext-interp)
th/T12646.run T12646 [exit code non-0] (ext-interp)
th/T13642.run T13642 [exit code non-0] (ext-interp)
th/T13887.run T13887 [exit code non-0] (ext-interp)
th/T14060.run T14060 [exit code non-0] (ext-interp)
../../libraries/base/tests/CPUTime001.run CPUTime001 [bad stdout] (threaded2)
../../libraries/unix/tests/libposix/posix002.run posix002 [bad exit code] (threaded2)
```
Unfortunately, most of these appear to be segmentation faults and similar, suggesting miscompilation.8.6.1Alp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15276Bogus type in typechecker error recovery2019-07-07T18:13:28ZSimon Peyton JonesBogus type in typechecker error recoveryIf the typechecker sees
```
let f = <rhs> in <body>
```
and there's a type error in `<rhs>`, GHC recovers from the error, binds `f` to "a type that should cause no more trouble", and continues with `<both>` in the hope of finding more ...If the typechecker sees
```
let f = <rhs> in <body>
```
and there's a type error in `<rhs>`, GHC recovers from the error, binds `f` to "a type that should cause no more trouble", and continues with `<both>` in the hope of finding more type errors.
What is "a type that should cause no more trouble"? Well `forall a.a` seems like a good candidate.
But, in this commit
```
commit 6746549772c5cc0ac66c0fce562f297f4d4b80a2
Author: Richard Eisenberg <eir@cis.upenn.edu>
Date: Fri Dec 11 18:19:53 2015 -0500
Add kind equalities to GHC.
```
we made the type look like this: `forall r. forall (a :: TYPE r). a`
Alas! That type is ill-formed because the kind `TYPE r` escapes the scope of `f`.
I discovered this when beefing up `typeKind` in pursuit of #14939
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Bogus type in typechecker error recovery","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If the typechecker sees\r\n{{{\r\nlet f = <rhs> in <body>\r\n}}}\r\nand there's a type error in `<rhs>`, GHC recovers from the error, binds `f` to \"a type that should cause no more trouble\", and continues with `<both>` in the hope of finding more type errors.\r\n\r\nWhat is \"a type that should cause no more trouble\"? Well `forall a.a` seems like a good candidate.\r\n\r\nBut, in this commit\r\n{{{\r\ncommit 6746549772c5cc0ac66c0fce562f297f4d4b80a2\r\nAuthor: Richard Eisenberg <eir@cis.upenn.edu>\r\nDate: Fri Dec 11 18:19:53 2015 -0500\r\n\r\n Add kind equalities to GHC.\r\n}}}\r\nwe made the type look like this: `forall r. forall (a :: TYPE r). a`\r\n\r\nAlas! That type is ill-formed because the kind `TYPE r` escapes the scope of `f`.\r\n\r\nI discovered this when beefing up `typeKind` in pursuit of #14939","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15277Move field name resolution to the type-checker2020-12-03T22:24:34ZAdam GundryMove field name resolution to the type-checkerPer discussion on #15149, we plan to make the type-checker responsible for all field name lookup in record construction, pattern-matching and updates. This should be simpler than the current story and let us get rid of `tcg_field_env`.
...Per discussion on #15149, we plan to make the type-checker responsible for all field name lookup in record construction, pattern-matching and updates. This should be simpler than the current story and let us get rid of `tcg_field_env`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Move field name resolution to the type-checker","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["ORF"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Per discussion on #15149, we plan to make the type-checker responsible for all field name lookup in record construction, pattern-matching and updates. This should be simpler than the current story and let us get rid of `tcg_field_env`.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Adam GundryAdam Gundryhttps://gitlab.haskell.org/ghc/ghc/-/issues/15278Add -Werror=compat, enable it in the testsuite2019-07-07T18:13:28ZVladislav ZavialovAdd -Werror=compat, enable it in the testsuite# Proposed change
Add a flag `-Werror=compat` to GHC which would have the effect of `-Werror=x -Werror=y ...` where `x, y, ...` are warnings from `minusWcompatOpts`. Enable `-Werror=compat` in the testsuite.
# Motivation
1. `-Werror=c...# Proposed change
Add a flag `-Werror=compat` to GHC which would have the effect of `-Werror=x -Werror=y ...` where `x, y, ...` are warnings from `minusWcompatOpts`. Enable `-Werror=compat` in the testsuite.
# Motivation
1. `-Werror=compat` would be a convenient shorthand to ensure forwards-compatibility of code. I can imagine Haskell libs enabling it on their CI.
1. Enabling `-Werror=compat` in the testsuite would allow us to easily see the impact that a new warning has on code. It also means that in the period between adding the warning and making the actual breaking change, all new test cases that are being added to the testsuite will be forwards-compatible. This is good because it will make the actual breaking change contain less irrelevant testsuite updates.
The idea came up during my work on [D4834](https://phabricator.haskell.org/D4834) which defines a new warning and adds it to `-Wcompat`. Ryan Scott raised the following concern:
> There are likely many tests in the testsuite that will now fail due to this change—I'm unclear if you're intending to fix them by explicitly quantifying their kind variables, or leaving the new error message as-is.
My intention was to update the test cases, but it turned out that I couldn't even locate these test cases without `make EXTRA_HC_OPTS="-Werror=implicit-kind-vars"`. And even if I updated the testsuite, nothing would prevent new test cases that are not forwards-compatible, because the warning isn't enabled by default (and without `-Werror=compat`, enabling `-Wcompat` would not cause test failures in all circumstances).
# Implementation plan
1. Add new flags: `-Werror=compat`, `-Wno-error=compat`, `-Wwarn=compat`. Document these flags in the User's Guide.
1. Enable `-Werror=compat` in the testsuite by default and fix all tests that break.8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15279CPP #includes may result in nonsensical SrcSpans2019-07-07T18:13:28ZZubinCPP #includes may result in nonsensical SrcSpansConsider the following code in `compiler/prelude/PrimOp.hs`
```hs
primOpInfo :: PrimOp -> PrimOpInfo
#include "primop-primop-info.hs-incl"
primOpInfo _ = error "primOpInfo: unknown primop" -- line 175 in PrimOp.hs
```
The MatchGroup fo...Consider the following code in `compiler/prelude/PrimOp.hs`
```hs
primOpInfo :: PrimOp -> PrimOpInfo
#include "primop-primop-info.hs-incl"
primOpInfo _ = error "primOpInfo: unknown primop" -- line 175 in PrimOp.hs
```
The MatchGroup for primOpInfo includes the `SrcSpan`
`compiler/stage2/build/primop-primop-info.hs-incl:(1,1)-(175,49)`
Here is line 175 in `primop-primop-info.hs-incl`
```hs
primOpInfo IndexSmallArrayOp = mkGenPrimOp (fsLit "indexSmallArray#") [alphaTyVar] [mkSmallArrayPrimTy alphaTy, intPrimTy] ((mkTupleTy Unboxed [alphaTy]))
```
The `SrcSpan`s end is somewhere in the middle of that line.
I guess this occurs because `combineSrcSpans` doesn't take the file into account.
I can think of multiple ways to fix this:
1. Make `combineSrcSpans` output an `UnhelpfulSrcSpan` if the files don't match(quick and easy)
1. Extend SrcSpan to properly support things spanning multiple files
1. Don't fix: People who use CPP get what they deserve.
Option 3 is not unreasonable as options 1 and 2 will incur some performance penalty.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"CPP #includes may result in nonsensical SrcSpans","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following code in `compiler/prelude/PrimOp.hs`\r\n{{{#!hs\r\nprimOpInfo :: PrimOp -> PrimOpInfo\r\n#include \"primop-primop-info.hs-incl\"\r\nprimOpInfo _ = error \"primOpInfo: unknown primop\" -- line 175 in PrimOp.hs\r\n}}}\r\nThe MatchGroup for primOpInfo includes the `SrcSpan`\r\n\r\n`compiler/stage2/build/primop-primop-info.hs-incl:(1,1)-(175,49)`\r\n\r\nHere is line 175 in `primop-primop-info.hs-incl`\r\n{{{#!hs\r\nprimOpInfo IndexSmallArrayOp = mkGenPrimOp (fsLit \"indexSmallArray#\") [alphaTyVar] [mkSmallArrayPrimTy alphaTy, intPrimTy] ((mkTupleTy Unboxed [alphaTy]))\r\n}}}\r\n\r\nThe `SrcSpan`s end is somewhere in the middle of that line.\r\n\r\nI guess this occurs because `combineSrcSpans` doesn't take the file into account.\r\n\r\nI can think of multiple ways to fix this:\r\n\r\n1. Make `combineSrcSpans` output an `UnhelpfulSrcSpan` if the files don't match(quick and easy)\r\n2. Extend SrcSpan to properly support things spanning multiple files\r\n3. Don't fix: People who use CPP get what they deserve.\r\n\r\nOption 3 is not unreasonable as options 1 and 2 will incur some performance penalty.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15280StgCmmEnv: variable not found2019-07-07T18:13:28ZwanjachStgCmmEnv: variable not found```
stack build
warduino-0.1.0.0: build (lib + exe)
Preprocessing library warduino-0.1.0.0...
Preprocessing executable 'blink' for warduino-0.1.0.0...
Preprocessing executable 'lcd' for warduino-0.1.0.0...
[1 of 1] Compiling Main ...```
stack build
warduino-0.1.0.0: build (lib + exe)
Preprocessing library warduino-0.1.0.0...
Preprocessing executable 'blink' for warduino-0.1.0.0...
Preprocessing executable 'lcd' for warduino-0.1.0.0...
[1 of 1] Compiling Main ( lcd/Main.hs, .stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0/build/lcd/lcd-tmp/Main.o )
/home/user/src/warduino/lcd/Main.hs:31:5: warning: [-Wname-shadowing]
This binding for `lcd' shadows the existing binding
defined at lcd/Main.hs:30:1
/home/user/src/warduino/lcd/Main.hs:33:9: warning: [-Wname-shadowing]
This binding for `print' shadows the existing binding
imported from `Prelude' at lcd/Main.hs:2:8-11
(and originally defined in `System.IO')
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.2 for x86_64-unknown-linux):
StgCmmEnv: variable not found
lcd_a3jG
local binds for:
delay_deep'1
$trModule1
$trModule2
delay
lcdController
$trModule
lcd5
lcdController1
lcdController2
lcdController3
lcdController4
lcdController5
lcdController6
lcdController7
lcd6
lcd7
lvl_r9Ee
lvl1_r9Ef
lvl2_r9Eg
lvl3_r9Eh
lvl4_r9Ei
lvl5_r9Ej
lvl6_r9Ek
lvl7_r9El
delay_deep'
ipv1_s9Ev
addr#_s9Ew
ds4_s9EA
sat_s9EB
sat_s9EC
sat_s9ED
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
-- While building custom Setup.hs for package warduino-0.1.0.0 using:
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"StgCmmEnv: variable not found","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nstack build\r\nwarduino-0.1.0.0: build (lib + exe)\r\nPreprocessing library warduino-0.1.0.0...\r\nPreprocessing executable 'blink' for warduino-0.1.0.0...\r\nPreprocessing executable 'lcd' for warduino-0.1.0.0...\r\n[1 of 1] Compiling Main ( lcd/Main.hs, .stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0/build/lcd/lcd-tmp/Main.o )\r\n\r\n/home/user/src/warduino/lcd/Main.hs:31:5: warning: [-Wname-shadowing]\r\n This binding for `lcd' shadows the existing binding\r\n defined at lcd/Main.hs:30:1\r\n\r\n/home/user/src/warduino/lcd/Main.hs:33:9: warning: [-Wname-shadowing]\r\n This binding for `print' shadows the existing binding\r\n imported from `Prelude' at lcd/Main.hs:2:8-11\r\n (and originally defined in `System.IO')\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.2 for x86_64-unknown-linux):\r\n StgCmmEnv: variable not found\r\n lcd_a3jG\r\n local binds for:\r\n delay_deep'1\r\n $trModule1\r\n $trModule2\r\n delay\r\n lcdController\r\n $trModule\r\n lcd5\r\n lcdController1\r\n lcdController2\r\n lcdController3\r\n lcdController4\r\n lcdController5\r\n lcdController6\r\n lcdController7\r\n lcd6\r\n lcd7\r\n lvl_r9Ee\r\n lvl1_r9Ef\r\n lvl2_r9Eg\r\n lvl3_r9Eh\r\n lvl4_r9Ei\r\n lvl5_r9Ej\r\n lvl6_r9Ek\r\n lvl7_r9El\r\n delay_deep'\r\n ipv1_s9Ev\r\n addr#_s9Ew\r\n ds4_s9EA\r\n sat_s9EB\r\n sat_s9EC\r\n sat_s9ED\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n\r\n-- While building custom Setup.hs for package warduino-0.1.0.0 using:\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15281GHC 8.6.1 can't be bootstrapped with GHC 8.2.12019-07-07T18:13:28ZBen GamariGHC 8.6.1 can't be bootstrapped with GHC 8.2.160e4bb4d305bc1a65457ee79b1e69c11b9ed747d (#9136) triggers a bug in GHC 8.2.1 which causes the build to fail with,
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.1 for x86_64-unknown-linux):
runtimeRepPrimRep
typePrimR...60e4bb4d305bc1a65457ee79b1e69c11b9ed747d (#9136) triggers a bug in GHC 8.2.1 which causes the build to fail with,
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.1 for x86_64-unknown-linux):
runtimeRepPrimRep
typePrimRep (r_aqbE :: TYPE rep_aqbD)
rep_aqbD
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/simplStg/RepType.hs:360:5 in ghc:RepType
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
This is a manifestation of #14393, which is fixed in 8.2.2 and later.
We should probably add a `configure` check warning about this brokenness when the user tries to bootstrap with GHC 8.2.1.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.6.1 can't be bootstrapped with GHC 8.2.1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"60e4bb4d305bc1a65457ee79b1e69c11b9ed747d (#9136) triggers a bug in GHC 8.2.1 which causes the build to fail with,\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.1 for x86_64-unknown-linux):\r\n\truntimeRepPrimRep\r\n typePrimRep (r_aqbE :: TYPE rep_aqbD)\r\n rep_aqbD\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler/simplStg/RepType.hs:360:5 in ghc:RepType\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThis is a manifestation of #14393, which is fixed in 8.2.2 and later.\r\n\r\nWe should probably add a `configure` check warning about this brokenness when the user tries to bootstrap with GHC 8.2.1.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15282Document how equality-bearing constructors are promoted in Core2019-07-07T18:13:27ZRyan ScottDocument how equality-bearing constructors are promoted in CoreIn [D4728](https://phabricator.haskell.org/D4728), Simon was utterly baffled as to how one could promote the `MkT` constructor in:
```hs
data T a where
MkT :: (a ~ Int) => T a
```
Richard knows the inner machinations of how this work...In [D4728](https://phabricator.haskell.org/D4728), Simon was utterly baffled as to how one could promote the `MkT` constructor in:
```hs
data T a where
MkT :: (a ~ Int) => T a
```
Richard knows the inner machinations of how this works (including what coercions are used in the Core that `'MkT` desugars to), but not many others do. Simon requested that Richard document this knowledge in a Note somewhere. This ticket exists to keep track of this request.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | goldfire |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Document how equality-bearing constructors are promoted in Core","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":["goldfire"],"type":"Bug","description":"In Phab:D4728, Simon was utterly baffled as to how one could promote the `MkT` constructor in:\r\n\r\n{{{#!hs\r\ndata T a where\r\n MkT :: (a ~ Int) => T a\r\n}}}\r\n\r\nRichard knows the inner machinations of how this works (including what coercions are used in the Core that `'MkT` desugars to), but not many others do. Simon requested that Richard document this knowledge in a Note somewhere. This ticket exists to keep track of this request.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/15284Can't parse ''(*) in GHC HEAD2019-07-07T18:13:27ZRyan ScottCan't parse ''(*) in GHC HEADI can't build the `reflection` library on GHC HEAD since the `''(*)` Template Haskell name no longer parses. Here is a smaller example which compares GHC 8.4.3 (what should happens) with HEAD (which fails):
```
$ /opt/ghc/8.4.3/bin/ghci...I can't build the `reflection` library on GHC HEAD since the `''(*)` Template Haskell name no longer parses. Here is a smaller example which compares GHC 8.4.3 (what should happens) with HEAD (which fails):
```
$ /opt/ghc/8.4.3/bin/ghci -XTemplateHaskell
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> import GHC.TypeNats
λ> ''(*)
GHC.TypeNats.*
```
```
$ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive -XTemplateHaskell
GHCi, version 8.5.20180617: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> import GHC.TypeNats
λ> ''(*)
<interactive>:2:4: error: parse error on input ‘*’
```
int-index, I believe this was caused by your commit d650729f9a0f3b6aa5e6ef2d5fba337f6f70fa60 (`Embrace -XTypeInType, add -XStarIsType`). Do you know what is going on here?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | int-index |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Can't parse ''(*) in GHC HEAD","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["int-index"],"type":"Bug","description":"I can't build the `reflection` library on GHC HEAD since the `''(*)` Template Haskell name no longer parses. Here is a smaller example which compares GHC 8.4.3 (what should happens) with HEAD (which fails):\r\n\r\n{{{\r\n$ /opt/ghc/8.4.3/bin/ghci -XTemplateHaskell\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\nλ> import GHC.TypeNats\r\nλ> ''(*)\r\nGHC.TypeNats.*\r\n}}}\r\n\r\n{{{\r\n$ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive -XTemplateHaskell \r\nGHCi, version 8.5.20180617: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\nλ> import GHC.TypeNats\r\nλ> ''(*)\r\n\r\n<interactive>:2:4: error: parse error on input ‘*’\r\n}}}\r\n\r\nint-index, I believe this was caused by your commit d650729f9a0f3b6aa5e6ef2d5fba337f6f70fa60 (`Embrace -XTypeInType, add -XStarIsType`). Do you know what is going on here?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15285"strange closure type" in T7919 with the threaded2 way2019-07-07T18:13:27ZAlp Mestanogullari"strange closure type" in T7919 with the threaded2 wayLast night's `./validate --slow` run on Circle CI revealed the following failure:
```
Wrong exit code for T7919(threaded2)(expected 0 , actual 134 )
Stderr ( T7919 ):
T7919: internal error: evacuate: strange closure type 32554624
(G...Last night's `./validate --slow` run on Circle CI revealed the following failure:
```
Wrong exit code for T7919(threaded2)(expected 0 , actual 134 )
Stderr ( T7919 ):
T7919: internal error: evacuate: strange closure type 32554624
(GHC version 8.5.20180617 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
*** unexpected failure for T7919(threaded2)
```
The full log is available [here](https://circleci.com/api/v1.1/project/github/ghc/ghc/6205/output/107/0?file=true). Among other things, you can see that it indeed only fails in the threaded2 way.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"strange closure type\" in T7919 with the threaded2 way","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Last night's `./validate --slow` run on Circle CI revealed the following failure:\r\n\r\n{{{\r\nWrong exit code for T7919(threaded2)(expected 0 , actual 134 )\r\nStderr ( T7919 ):\r\nT7919: internal error: evacuate: strange closure type 32554624\r\n (GHC version 8.5.20180617 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAborted\r\n*** unexpected failure for T7919(threaded2)\r\n}}}\r\n\r\nThe full log is available [https://circleci.com/api/v1.1/project/github/ghc/ghc/6205/output/107/0?file=true here]. Among other things, you can see that it indeed only fails in the threaded2 way.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15286"Can't use Natural in base" when compiling GHC.Natural with -O02020-07-22T06:52:44ZAlp Mestanogullari"Can't use Natural in base" when compiling GHC.Natural with -O0```
_build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id base-4.12.0.0' '-package-id ghc-prim-0.5.3' '-package-id integer-sim...```
_build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id base-4.12.0.0' '-package-id ghc-prim-0.5.3' '-package-id integer-simple-0.1.1.1' '-package-id rts-1.0' -i -i_build/stage1/libraries/base/build -i_build/stage1/libraries/base/build/autogen -ilibraries/base/. -Iincludes -I_build/generated -I_build/stage1/libraries/base/build -I_build/stage1/libraries/base/build/include -Ilibraries/base/include -I/home/travis/build/snowleopard/hadrian/ghc/_build/stage1/lib/x86_64-linux-ghc-8.5.20180617/rts-1.0/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage1/libraries/base/build/autogen/cabal_macros.h -optc-std=gnu99 -optc-fno-stack-protector -optP-std=gnu99 -odir _build/stage1/libraries/base/build -hidir _build/stage1/libraries/base/build -stubdir _build/stage1/libraries/base/build -Wnoncanonical-monad-instances -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/base/GHC/Num.hs -o _build/stage1/libraries/base/build/GHC/Num.o -O0 -H64m -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 -ghcversion-file=/home/travis/build/snowleopard/hadrian/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags -Wno-trustworthy-safe
Exit code: 1
Stderr:
ghc: panic! (the 'impossible' happened)
(GHC version 8.5.20180617 for x86_64-unknown-linux):
Can't use Natural in base
```
We noticed this in hadrian land (in [this PR](https://github.com/snowleopard/hadrian/issues/499) and [https://github.com/snowleopard/hadrian/issues/629](https://github.com/snowleopard/hadrian/issues/629)), and noticed that this happens:
- with 8.4.2 as the boot compiler but not 8.2.2
- with integer-simple as the integer library
- only with the quickest flavour (or more generally when we build GHC.Natural with -O0)
Some optimisation seems critical to making any trace of `Natural` disappear, but this seems rather fragile. The code that throws the error got introduced in fe770c211631e7b4c9b0b1e88ef9b6046c6585ef.
The full build log is available [here](https://travis-ci.org/snowleopard/hadrian/jobs/393259151#L4209), anchored to where the error appears.
An example of hadrian command to reproduce the problem, assuming a configured build tree: `hadrian/build.sh --flavour=quickest --integer-simple -j4`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"Can't use Natural in base\" when compiling GHC.Natural with -O0","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["bgamari"],"type":"Bug","description":"{{{\r\n_build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id base-4.12.0.0' '-package-id ghc-prim-0.5.3' '-package-id integer-simple-0.1.1.1' '-package-id rts-1.0' -i -i_build/stage1/libraries/base/build -i_build/stage1/libraries/base/build/autogen -ilibraries/base/. -Iincludes -I_build/generated -I_build/stage1/libraries/base/build -I_build/stage1/libraries/base/build/include -Ilibraries/base/include -I/home/travis/build/snowleopard/hadrian/ghc/_build/stage1/lib/x86_64-linux-ghc-8.5.20180617/rts-1.0/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage1/libraries/base/build/autogen/cabal_macros.h -optc-std=gnu99 -optc-fno-stack-protector -optP-std=gnu99 -odir _build/stage1/libraries/base/build -hidir _build/stage1/libraries/base/build -stubdir _build/stage1/libraries/base/build -Wnoncanonical-monad-instances -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/base/GHC/Num.hs -o _build/stage1/libraries/base/build/GHC/Num.o -O0 -H64m -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 -ghcversion-file=/home/travis/build/snowleopard/hadrian/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags -Wno-trustworthy-safe\r\nExit code: 1\r\nStderr:\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.5.20180617 for x86_64-unknown-linux):\r\n\tCan't use Natural in base\r\n}}}\r\n\r\nWe noticed this in hadrian land (in [https://github.com/snowleopard/hadrian/issues/499 this PR] and [https://github.com/snowleopard/hadrian/issues/629]), and noticed that this happens:\r\n\r\n- with 8.4.2 as the boot compiler but not 8.2.2\r\n- with integer-simple as the integer library\r\n- only with the quickest flavour (or more generally when we build GHC.Natural with -O0)\r\n\r\nSome optimisation seems critical to making any trace of `Natural` disappear, but this seems rather fragile. The code that throws the error got introduced in fe770c211631e7b4c9b0b1e88ef9b6046c6585ef.\r\n\r\nThe full build log is available [https://travis-ci.org/snowleopard/hadrian/jobs/393259151#L4209 here], anchored to where the error appears.\r\n\r\nAn example of hadrian command to reproduce the problem, assuming a configured build tree: `hadrian/build.sh --flavour=quickest --integer-simple -j4`.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15288Figure out what to do about retainer profiling debugging code2020-10-13T06:48:32ZBen GamariFigure out what to do about retainer profiling debugging code`rts/RetainerProfile.c` has a hope pile of code guarded by the unset-by-default `DEBUG_RETAINER` macro. I tried to resuscitate it while debugging #15287, but it seems like a bit of a lost cause. In particular, the `cost()` function which...`rts/RetainerProfile.c` has a hope pile of code guarded by the unset-by-default `DEBUG_RETAINER` macro. I tried to resuscitate it while debugging #15287, but it seems like a bit of a lost cause. In particular, the `cost()` function which seems to be critical to the accounting done by in this code was removed in dbef766ce79e37a74468a07a93b15ba1f06fe8f8. While I can't tell for certain, it's possible that this "cost" notion coincides with the value currently computed by `closure_sizeW`.
Regardless, we should either drop this code if it's beyond saving or fix it to do something useful.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Figure out what to do about retainer profiling debugging code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"`rts/RetainerProfile.c` has a hope pile of code guarded by the unset-by-default `DEBUG_RETAINER` macro. I tried to resuscitate it while debugging #15287, but it seems like a bit of a lost cause. In particular, the `cost()` function which seems to be critical to the accounting done by in this code was removed in dbef766ce79e37a74468a07a93b15ba1f06fe8f8. While I can't tell for certain, it's possible that this \"cost\" notion coincides with the value currently computed by `closure_sizeW`.\r\n\r\nRegardless, we should either drop this code if it's beyond saving or fix it to do something useful.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15289isUnliftedType GHC panic on pattern with True :: Maybe2019-07-07T18:13:25ZRemiisUnliftedType GHC panic on pattern with True :: Maybe```hs
{-# LANGUAGE PatternSynonyms #-}
{-# LANGUAGE ScopedTypeVariables #-}
module Oops where
pattern What = True :: Maybe
```
Fails on 8.4.3 with:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-unknown-li...```hs
{-# LANGUAGE PatternSynonyms #-}
{-# LANGUAGE ScopedTypeVariables #-}
module Oops where
pattern What = True :: Maybe
```
Fails on 8.4.3 with:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-unknown-linux):
isUnliftedType
(Maybe |> {co_a1Dg3}) :: TYPE t_a1Dg9[tau:1]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:1939:10 in ghc:Type
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I'm currently cloning from git, and will try to get around to check it with HEAD over the next days. BTW, it's not a show-stopper for me.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | aarch64 |
</details>
<!-- {"blocked_by":[],"summary":"isUnliftedType GHC panic on pattern with True :: Maybe","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"aarch64","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# LANGUAGE PatternSynonyms #-}\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\nmodule Oops where\r\n\r\npattern What = True :: Maybe\r\n}}}\r\n\r\nFails on 8.4.3 with:\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.3 for x86_64-unknown-linux):\r\n\tisUnliftedType\r\n (Maybe |> {co_a1Dg3}) :: TYPE t_a1Dg9[tau:1]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable\r\n pprPanic, called at compiler/types/Type.hs:1939:10 in ghc:Type\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nI'm currently cloning from git, and will try to get around to check it with HEAD over the next days. BTW, it's not a show-stopper for me.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15290QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar"2024-01-11T02:06:42ZRichard Eisenbergrae@richarde.devQuantifiedConstraints: panic "addTcEvBind NoEvBindsVar"I wanted to see if we're ready to put `join` into `Monad`. So I typed this in:
```hs
{-# LANGUAGE QuantifiedConstraints, StandaloneDeriving, GeneralizedNewtypeDeriving #-}
module Bug where
import Prelude hiding ( Monad(..) )
import Da...I wanted to see if we're ready to put `join` into `Monad`. So I typed this in:
```hs
{-# LANGUAGE QuantifiedConstraints, StandaloneDeriving, GeneralizedNewtypeDeriving #-}
module Bug where
import Prelude hiding ( Monad(..) )
import Data.Coerce ( Coercible )
class Monad m where
(>>=) :: m a -> (a -> m b) -> m b
join :: m (m a) -> m a
newtype StateT s m a = StateT { runStateT :: s -> m (s, a) }
instance Monad m => Monad (StateT s m) where
ma >>= fmb = StateT $ \s -> runStateT ma s >>= \(s1, a) -> runStateT (fmb a) s1
join ssa = StateT $ \s -> runStateT ssa s >>= \(s, sa) -> runStateT sa s
newtype IntStateT m a = IntStateT { runIntStateT :: StateT Int m a }
deriving instance (Monad m, forall p q. Coercible p q => Coercible (m p) (m q)) => Monad (IntStateT m)
```
This looks like it should be accepted. But I get
```
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.5.20180617 for x86_64-apple-darwin):
addTcEvBind NoEvBindsVar
[G] df_a67k
= \ (@ p_a62C) (@ q_a62D) (v_B1 :: Coercible p_a62C q_a62D) ->
coercible_sel
@ *
@ (m_a64Z[ssk:1] p_a62C)
@ (m_a64Z[ssk:1] q_a62D)
(df_a651 @ p_a62C @ q_a62D v_B1)
a67c
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable
pprPanic, called at compiler/typecheck/TcRnMonad.hs:1404:5 in ghc:TcRnMonad
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"QuantifiedConstraints: panic \"addTcEvBind NoEvBindsVar\"","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["QuantifiedConstraints"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I wanted to see if we're ready to put `join` into `Monad`. So I typed this in:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE QuantifiedConstraints, StandaloneDeriving, GeneralizedNewtypeDeriving #-}\r\n\r\nmodule Bug where\r\n\r\nimport Prelude hiding ( Monad(..) )\r\nimport Data.Coerce ( Coercible )\r\n\r\nclass Monad m where\r\n (>>=) :: m a -> (a -> m b) -> m b\r\n join :: m (m a) -> m a\r\n\r\nnewtype StateT s m a = StateT { runStateT :: s -> m (s, a) }\r\n\r\ninstance Monad m => Monad (StateT s m) where\r\n ma >>= fmb = StateT $ \\s -> runStateT ma s >>= \\(s1, a) -> runStateT (fmb a) s1\r\n join ssa = StateT $ \\s -> runStateT ssa s >>= \\(s, sa) -> runStateT sa s\r\n\r\nnewtype IntStateT m a = IntStateT { runIntStateT :: StateT Int m a }\r\n\r\nderiving instance (Monad m, forall p q. Coercible p q => Coercible (m p) (m q)) => Monad (IntStateT m)\r\n\r\n}}}\r\n\r\nThis looks like it should be accepted. But I get\r\n\r\n{{{\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.5.20180617 for x86_64-apple-darwin):\r\n\taddTcEvBind NoEvBindsVar\r\n [G] df_a67k\r\n = \\ (@ p_a62C) (@ q_a62D) (v_B1 :: Coercible p_a62C q_a62D) ->\r\n coercible_sel\r\n @ *\r\n @ (m_a64Z[ssk:1] p_a62C)\r\n @ (m_a64Z[ssk:1] q_a62D)\r\n (df_a651 @ p_a62C @ q_a62D v_B1)\r\n a67c\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable\r\n pprPanic, called at compiler/typecheck/TcRnMonad.hs:1404:5 in ghc:TcRnMonad\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15292ghc_ticker loops if permission denied on timerfd2019-07-07T18:13:24Zjon.fairbairn@cl.cam.ac.ukghc_ticker loops if permission denied on timerfdUsing stack with lts-11.6 to compile a cgi programme, I got something that runs OK from the command line, but which goes into a busy loop when run from httpd.
This is caused by selinux preventing read on the timer. Changing the selunix p...Using stack with lts-11.6 to compile a cgi programme, I got something that runs OK from the command line, but which goes into a busy loop when run from httpd.
This is caused by selinux preventing read on the timer. Changing the selunix permissions solves the problems, but ghc-ticker ought to check whether the read succeeded and not try again if it fails.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc_ticker loops if permission denied on timerfd","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using stack with lts-11.6 to compile a cgi programme, I got something that runs OK from the command line, but which goes into a busy loop when run from httpd.\r\nThis is caused by selinux preventing read on the timer. Changing the selunix permissions solves the problems, but ghc-ticker ought to check whether the read succeeded and not try again if it fails.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15293Set up staging branch2019-07-07T18:13:24ZBen GamariSet up staging branchGoal: Keep commits that would break CI out of `master`.
Approach: Introduce a staging branch where commits will first land to go through the full CI workup. When a commit passes on `staging`, merge it into `master`.
<details><summary>T...Goal: Keep commits that would break CI out of `master`.
Approach: Introduce a staging branch where commits will first land to go through the full CI workup. When a commit passes on `staging`, merge it into `master`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.4.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Continuous Integration |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Set up staging branch","status":"New","operating_system":"","component":"Continuous Integration","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Goal: Keep commits that would break CI out of `master`.\r\n\r\nApproach: Introduce a staging branch where commits will first land to go through the full CI workup. When a commit passes on `staging`, merge it into `master`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15294Unused "foralls" prevent types from being Coercible2021-03-02T09:05:33ZIcelandjackUnused "foralls" prevent types from being CoercibleJust a quick question, do these have the same representation?
```hs
newtype A where
A :: (Int -> Bool) -> A
newtype B where
B :: (forall (a::Type). Int -> Bool) -> B
```
I'm wondering because they aren't `Coercible`
```
> :t coer...Just a quick question, do these have the same representation?
```hs
newtype A where
A :: (Int -> Bool) -> A
newtype B where
B :: (forall (a::Type). Int -> Bool) -> B
```
I'm wondering because they aren't `Coercible`
```
> :t coerce :: A -> B
<interactive>:1:1: error:
• Couldn't match representation of type ‘forall a. Int -> Bool’
with that of ‘Int -> Bool’
arising from a use of ‘coerce’
• In the expression: coerce :: A -> B
```
`C` isn't `Coercible` to `B` either
```hs
newtype C where
C :: (forall k (a :: k). Int -> Bool) -> C
```
Also
```hs
-- D is not Coercible to E, "can't match type ‘Bool’ with ‘Ordering’"
newtype D where
D :: (forall (a::Bool) (b::Ordering). Int -> Bool) -> D
newtype E where
E :: (forall (a::Ordering) (b::Bool). Int -> Bool) -> E
```
My question is is this intended?8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15296Sentence is about Complex type but mentions Simple constructor2019-07-07T18:13:23ZSasha Bogicevicsasa.bogicevic@pm.meSentence is about Complex type but mentions Simple constructorThere is a mistype in one of the sentences regarding Roles in the documentation :
https://ghc.readthedocs.io/en/latest/glasgow_exts.html\#nominal-representational-and-phantom
```
Here are some examples:
data Simple a = MkSimple a ...There is a mistype in one of the sentences regarding Roles in the documentation :
https://ghc.readthedocs.io/en/latest/glasgow_exts.html\#nominal-representational-and-phantom
```
Here are some examples:
data Simple a = MkSimple a -- a has role representational
type family F
type instance F Int = Bool
type instance F Age = Char
data Complex a = MkComplex (F a) -- a has role nominal
data Phant a = MkPhant Bool -- a has role phantom
```
The type Simple has its parameter at role representational, which is generally the most common case. Simple Age would have the same representation as Simple Int. The type Complex, on the other hand, has its parameter at role nominal, because Simple Age and Simple Int are not the same. Lastly, Phant Age and Phant Bool have the same representation, even though Age and Bool are unrelated.
The wrong sentence is `The type Complex, on the other hand, has its parameter at role nominal, because Simple Age and Simple Int are not the same. `
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Sentence is about Complex type but mentions Simple constructor","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There is a mistype in one of the sentences regarding Roles in the documentation :\r\nhttps://ghc.readthedocs.io/en/latest/glasgow_exts.html#nominal-representational-and-phantom\r\n\r\n{{{\r\nHere are some examples:\r\n\r\ndata Simple a = MkSimple a -- a has role representational\r\n\r\ntype family F\r\ntype instance F Int = Bool\r\ntype instance F Age = Char\r\n\r\ndata Complex a = MkComplex (F a) -- a has role nominal\r\n\r\ndata Phant a = MkPhant Bool -- a has role phantom\r\n}}}\r\nThe type Simple has its parameter at role representational, which is generally the most common case. Simple Age would have the same representation as Simple Int. The type Complex, on the other hand, has its parameter at role nominal, because Simple Age and Simple Int are not the same. Lastly, Phant Age and Phant Bool have the same representation, even though Age and Bool are unrelated.\r\n\r\n\r\nThe wrong sentence is `The type Complex, on the other hand, has its parameter at role nominal, because Simple Age and Simple Int are not the same. `\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Sasha Bogicevicsasa.bogicevic@pm.meSasha Bogicevicsasa.bogicevic@pm.mehttps://gitlab.haskell.org/ghc/ghc/-/issues/15299GHCi :print produces variables that cause a panic2021-05-20T08:20:20ZOmfGHCi :print produces variables that cause a panicUsing ghci installed by Stack, I noted some strange behaviour from the :sprint and :print commands:
```hs
λ> xs = [1,2,3]
λ> :sprint xs
xs = _
λ> head xs
1
λ> :sprint xs
xs = _
λ> :print xs
xs = (_t1::Num a => [a])
λ> _t1
<interactive>...Using ghci installed by Stack, I noted some strange behaviour from the :sprint and :print commands:
```hs
λ> xs = [1,2,3]
λ> :sprint xs
xs = _
λ> head xs
1
λ> :sprint xs
xs = _
λ> :print xs
xs = (_t1::Num a => [a])
λ> _t1
<interactive>:6:1: error:
• No instance for (Num a) arising from a use of ‘_t1’
• In the expression: _t1
In an equation for ‘it’: it = _t1
λ> :t _t1
<interactive>:1:1: error:
No instance for (Num a) arising from a use of ‘_t1’
λ> :info _t1
_t1 :: Num a => [a] -- Defined in ‘interactive:Ghci3’
λ> _t1 :: [Int]
<interactive>:9:1: error:ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-linux):
No skolem info:
a_a1rR
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/typecheck/TcErrors.hs:2653:5 in ghc:TcErrors
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I don't really understand the error, or why even the :type command fails, but it appears to be related to the way numeric types are polymorphic until a specific type is forced. Note that the both the :sprint and :print commands don't seem to recognise that we've evaluated any of xs, just printing an underscore no matter what.
The panic doesn't happen if I force a type when defining xs:
```hs
λ> xs = [1,2,3] :: [Int]
λ> :sp xs
xs = _
λ> head xs
1
λ> :sp xs
xs = 1 : _
λ> :print xs
xs = 1 : (_t2::[Int])
λ> _t2
[2,3]
λ> :t _t2
_t2 :: [Int]
λ> :in _t2
_t2 :: [Int] -- Defined in ‘interactive:Ghci6’
λ> _t2 :: [Integer]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi :print produces variables that cause a panic","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using ghci installed by Stack, I noted some strange behaviour from the :sprint and :print commands:\r\n\r\n{{{#!hs\r\nλ> xs = [1,2,3]\r\nλ> :sprint xs\r\nxs = _\r\nλ> head xs\r\n1\r\nλ> :sprint xs\r\nxs = _\r\nλ> :print xs\r\nxs = (_t1::Num a => [a])\r\nλ> _t1\r\n\r\n<interactive>:6:1: error:\r\n • No instance for (Num a) arising from a use of ‘_t1’\r\n • In the expression: _t1\r\n In an equation for ‘it’: it = _t1\r\nλ> :t _t1\r\n\r\n<interactive>:1:1: error:\r\n No instance for (Num a) arising from a use of ‘_t1’\r\nλ> :info _t1\r\n_t1 :: Num a => [a] -- Defined in ‘interactive:Ghci3’\r\nλ> _t1 :: [Int]\r\n\r\n<interactive>:9:1: error:ghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-unknown-linux):\r\n No skolem info:\r\n a_a1rR\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler/typecheck/TcErrors.hs:2653:5 in ghc:TcErrors\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nI don't really understand the error, or why even the :type command fails, but it appears to be related to the way numeric types are polymorphic until a specific type is forced. Note that the both the :sprint and :print commands don't seem to recognise that we've evaluated any of xs, just printing an underscore no matter what.\r\n\r\nThe panic doesn't happen if I force a type when defining xs:\r\n\r\n{{{#!hs\r\nλ> xs = [1,2,3] :: [Int]\r\nλ> :sp xs\r\nxs = _\r\nλ> head xs\r\n1\r\nλ> :sp xs\r\nxs = 1 : _\r\nλ> :print xs\r\nxs = 1 : (_t2::[Int])\r\nλ> _t2\r\n[2,3]\r\nλ> :t _t2\r\n_t2 :: [Int]\r\nλ> :in _t2\r\n_t2 :: [Int] -- Defined in ‘interactive:Ghci6’\r\nλ> _t2 :: [Integer]\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15300Unboxed Sums Crash2019-07-07T18:13:22ZAndrew MartinUnboxed Sums CrashI've made it a little further in my experiments with unboxed tuples in the `packed` library. However, I've run into another issue that I strongly suspect is the result of bad behavior of unboxed tuples. To replicate this issue (with GHC ...I've made it a little further in my experiments with unboxed tuples in the `packed` library. However, I've run into another issue that I strongly suspect is the result of bad behavior of unboxed tuples. To replicate this issue (with GHC 8.4.3), do the following:
```
git clone https://github.com/andrewthad/packed
cd packed
cabal new-build
```
We use `cabal new-build` for its side effect of creating a `.ghc.environment.xyz` file. Now, create a minimal example in the directory called `eol.hs` with the following contents:
```hs
import Packed.Bytes.Parser (Parser)
import Data.Word
import Packed.Bytes (Bytes)
import GHC.Exts (RealWorld)
import Packed.Bytes.Stream.IO (ByteStream)
import qualified Packed.Bytes as B
import qualified Data.Char
import qualified Packed.Bytes.Parser as P
import qualified Packed.Bytes.Stream.IO as Stream
main :: IO ()
main = do
r <- runExampleParser
( do P.takeBytesUntilEndOfLineConsume
P.takeBytesUntilEndOfLineConsume
P.takeBytesUntilEndOfLineConsume
) (foldMap Stream.singleton (map charToWord8 "the\nemporium\rhas\narrived"))
print r
runExampleParser :: Parser e () a -> ByteStream RealWorld -> IO (Maybe a, Maybe String)
runExampleParser parser stream = do
P.Result mleftovers r _ <- P.parseStreamIO stream () parser
mextra <- case mleftovers of
Nothing -> return Nothing
Just (P.Leftovers chunk remainingStream) -> do
bs <- Stream.unpack remainingStream
return (Just (map word8ToChar (B.unpack chunk ++ bs)))
return (either (const Nothing) Just r,mextra)
word8ToChar :: Word8 -> Char
word8ToChar = Data.Char.chr . fromIntegral
charToWord8 :: Char -> Word8
charToWord8 = fromIntegral . Data.Char.ord
s2b :: String -> Bytes
s2b = B.pack . map charToWord8
c2w :: Char -> Word8
c2w = charToWord8
```
Finally, build this with `ghc -O2 eol.hs`, and then run the executable this produces to get the following:
```
(Nothing,Just "\rhas\narrived")
eol: internal error: stg_ap_n_ret
(GHC version 8.4.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
```
Things worth noting:
1. I think the program fails in the final GC that runs right before the program terminates. We can see that it produces a correct result of `(Nothing,Just "\rhas\narrived")`, but something on the heap has definitely been corrupted.
1. This only happens with `-O2` turned on.
1. This only happens when the parser does not successfully parse its input.
Here's some more context around this. I've been working on a parser that uses unboxed sums instead of continuations. After #15038 was fixed, everything had been going well. Then, I took the parser type and added two things to it: (1) context and (2) typed errors. Context is basically like throwing `StateT` on top and errors are like throwing `ExceptT` on top. After this, everything in my test suite kept working except for a single test, which now consistently crashes my test suite. So, I originally had this:
```hs
type Bytes# = (# ByteArray#, Int#, Int# #)
type Maybe# (a :: TYPE r) = (# (# #) | a #)
type Leftovers# s = (# Bytes# , ByteStream s #)
type Result# s (r :: RuntimeRep) (a :: TYPE r) =
(# Maybe# (Leftovers# s), Maybe# a #)
newtype ParserLevity (r :: RuntimeRep) (a :: TYPE r) = ParserLevity
{ getParserLevity :: forall s.
Maybe# (Leftovers# s)
-> State# s
-> (# State# s, Result# s r a #)
}
```
But I changed it to this:
```hs
type Bytes# = (# ByteArray#, Int#, Int# #)
type Maybe# (a :: TYPE r) = (# (# #) | a #)
type Either# a (b :: TYPE r) = (# a | b #)
type Leftovers# s = (# Bytes# , ByteStream s #)
type Result# e c s (r :: RuntimeRep) (a :: TYPE r) =
(# Maybe# (Leftovers# s), Either# (Maybe e) a, c #)
newtype ParserLevity e c (r :: RuntimeRep) (a :: TYPE r) = ParserLevity
{ getParserLevity :: forall s.
c
-> Maybe# (Leftovers# s)
-> State# s
-> (# State# s, Result# e c s r a #)
}
```
Specifically, the function causing trouble is (as currently defined):
```hs
{-# NOINLINE takeBytesUntilEndOfLineConsumeUnboxed #-}
takeBytesUntilEndOfLineConsumeUnboxed :: ParserLevity e c BytesRep Bytes#
takeBytesUntilEndOfLineConsumeUnboxed = ParserLevity (go (# (# #) | #)) where
go :: Maybe# Bytes# -> c -> Maybe# (Leftovers# s) -> State# s -> (# State# s, Result# e c s BytesRep Bytes# #)
go !_ c (# (# #) | #) s0 = (# s0, (# (# (# #) | #), (# Nothing | #), c #) #)
go !mbytes c (# | (# bytes0@(# arr0, off0, len0 #), !stream0@(ByteStream streamFunc) #) #) s0 = case BAW.findAnyByte2 (I# off0) (I# len0) 10 13 (ByteArray arr0) of
Nothing -> case streamFunc s0 of
(# s1, r #) -> go (# | appendMaybeBytes mbytes bytes0 #) c r s1
Just (I# ix, W8# theByte) -> case theByte of
10## -> (# s0, (# (# | (# unsafeDrop# ((ix -# off0) +# 1# ) bytes0, stream0 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) #), c #) #)
-- second case means it was 13
_ -> case ix <# (off0 +# len0 -# 1#) of
1# -> case indexWord8Array# arr0 (ix +# 1# ) of
10## -> (# s0, (# (# | (# unsafeDrop# ((ix -# off0) +# 2# ) bytes0, stream0 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) #), c #) #)
_ -> (# s0, (# (# | (# unsafeDrop# (ix -# off0) bytes0, stream0 #) #), (# Nothing | #), c #) #)
_ -> case nextNonEmpty stream0 s0 of
(# s1, m #) -> case m of
(# (# #) | #) -> (# s1, (# (# | (# unboxBytes (B.singleton 13), Stream.empty #) #), (# Nothing | #), c #) #)
(# | (# bytes1@(# arr1, _, _ #), stream1 #) #) -> case indexWord8Array# arr1 0# of
10## -> (# s1, (# (# | (# unsafeDrop# 1# bytes1, stream1 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) #), c #) #)
_ -> (# s1, (# (# | (# unboxBytes (B.cons 13 (boxBytes bytes1)), stream1 #) #), (# Nothing | #), c #) #)
```
That's all I've got for now. If no one's able to make headway, I'll probably come back to this and try to make a more minimal example at some point. I won't have time to do this soon though.8.6.1Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/15301Regression in Natural desugaring2019-07-07T18:13:22ZSylvain HenryRegression in Natural desugaringMy recent merged patch "Built-in Natural literals in Core" https://phabricator.haskell.org/rGHCfe770c211631e7b4c9b0b1e88ef9b6046c6585ef introduced a regression when desugaring large numbers.
Patch coming.
<details><summary>Trac metadat...My recent merged patch "Built-in Natural literals in Core" https://phabricator.haskell.org/rGHCfe770c211631e7b4c9b0b1e88ef9b6046c6585ef introduced a regression when desugaring large numbers.
Patch coming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Regression in Natural desugaring","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"My recent merged patch \"Built-in Natural literals in Core\" https://phabricator.haskell.org/rGHCfe770c211631e7b4c9b0b1e88ef9b6046c6585ef introduced a regression when desugaring large numbers.\r\n\r\nPatch coming.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15302TTG for IPBind wrong extension name2019-08-02T15:33:03ZAlan ZimmermanTTG for IPBind wrong extension nameThe standard\[1\] for extension naming is to use the `XC` prefix for the internal extension points, rather than for a new constructor.
This is violated for `IPBind`, having
```hs
data IPBind id
= IPBind
(XIPBind id)
(...The standard\[1\] for extension naming is to use the `XC` prefix for the internal extension points, rather than for a new constructor.
This is violated for `IPBind`, having
```hs
data IPBind id
= IPBind
(XIPBind id)
(Either (Located HsIPName) (IdP id))
(LHsExpr id)
| XCIPBind (XXIPBind id)
```
Swap the usage of `XIPBind` and `XCIPBind`
\[1\] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow\#Namingconventions
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TTG for IPBind wrong extension name","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["ttg"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The standard[1] for extension naming is to use the `XC` prefix for the internal extension points, rather than for a new constructor.\r\n\r\nThis is violated for `IPBind`, having\r\n\r\n{{{#!hs\r\ndata IPBind id\r\n = IPBind\r\n (XIPBind id)\r\n (Either (Located HsIPName) (IdP id))\r\n (LHsExpr id)\r\n | XCIPBind (XXIPBind id)\r\n}}}\r\n\r\nSwap the usage of `XIPBind` and `XCIPBind`\r\n\r\n[1] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow#Namingconventions\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/15303API Annotations lost when parsing tyapp2019-07-07T18:13:21ZAlan ZimmermanAPI Annotations lost when parsing tyappIn `Parser.y`, the `typapp` production has
```hs
| SIMPLEQUOTE qconop {% ams (sLL $1 $> $ TyElOpr (unLoc $2))
[mj AnnSimpleQuote $1] }
| SIMPLEQUOTE varop ...In `Parser.y`, the `typapp` production has
```hs
| SIMPLEQUOTE qconop {% ams (sLL $1 $> $ TyElOpr (unLoc $2))
[mj AnnSimpleQuote $1] }
| SIMPLEQUOTE varop {% ams (sLL $1 $> $ TyElOpr (unLoc $2))
[mj AnnSimpleQuote $1] }
```
By using `unLoc $2` we are discarding any annotations attached to the `qconop` or `qvarop`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"API Annotations lost when parsing tyapp","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In `Parser.y`, the `typapp` production has\r\n\r\n{{{#!hs\r\n | SIMPLEQUOTE qconop {% ams (sLL $1 $> $ TyElOpr (unLoc $2))\r\n [mj AnnSimpleQuote $1] }\r\n | SIMPLEQUOTE varop {% ams (sLL $1 $> $ TyElOpr (unLoc $2))\r\n [mj AnnSimpleQuote $1] }\r\n}}}\r\n\r\nBy using `unLoc $2` we are discarding any annotations attached to the `qconop` or `qvarop`.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/15304Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.22021-10-19T08:50:33ZNathanWaivioHuge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2I am the author of the cl3 library on Hackage. I have noticed a huge increase of compile time and memory use when testing 8.2.2 and 8.4.2. ghc-8.0.2 compiled in 4:17.33 using 3.5 GB. ghc-8.2.2 compiled in 26:40.15 using 32.8 GB. This is ...I am the author of the cl3 library on Hackage. I have noticed a huge increase of compile time and memory use when testing 8.2.2 and 8.4.2. ghc-8.0.2 compiled in 4:17.33 using 3.5 GB. ghc-8.2.2 compiled in 26:40.15 using 32.8 GB. This is an increase of 6x in time and 9x in memory. This is not all bad, my nbody benchmark has improved about 35% between ghc-8.0.2 and ghc-8.4.2 so the increased compilation time and memory usage are producing much better runtime performance. I am interested if you could suggest some workarounds to help others compile on systems with less resources. I have 64GB memory in my system and would like to test out some -fno-\* GHC Options. Could you point me in the right direction? The library is almost entirely pure functions. I am also interested in other options, like if there are ways to rewrite things to make it easier on the compiler or using NOINLINE on a trouble spot and how to find that trouble spot.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I am the author of the cl3 library on Hackage. I have noticed a huge increase of compile time and memory use when testing 8.2.2 and 8.4.2. ghc-8.0.2 compiled in 4:17.33 using 3.5 GB. ghc-8.2.2 compiled in 26:40.15 using 32.8 GB. This is an increase of 6x in time and 9x in memory. This is not all bad, my nbody benchmark has improved about 35% between ghc-8.0.2 and ghc-8.4.2 so the increased compilation time and memory usage are producing much better runtime performance. I am interested if you could suggest some workarounds to help others compile on systems with less resources. I have 64GB memory in my system and would like to test out some -fno-* GHC Options. Could you point me in the right direction? The library is almost entirely pure functions. I am also interested in other options, like if there are ways to rewrite things to make it easier on the compiler or using NOINLINE on a trouble spot and how to find that trouble spot.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/15305Erroneous "non-exhaustive pattern match" using nested GADT with strictness an...2020-09-22T13:41:25ZjkoppelErroneous "non-exhaustive pattern match" using nested GADT with strictness annotationIn the following code, `fun` contains an exhaustive pattern match, but, when compiling with -Wall, ghc erroneously reports a non-exhaustive pattern match.
```hs
data (:+:) f g a = Inl !(f a) | Inr !(g a)
data A
data B
data Foo l where...In the following code, `fun` contains an exhaustive pattern match, but, when compiling with -Wall, ghc erroneously reports a non-exhaustive pattern match.
```hs
data (:+:) f g a = Inl !(f a) | Inr !(g a)
data A
data B
data Foo l where
Foo :: Foo A
data Bar l where
Bar :: Bar B
type Sig = Foo :+: Bar
fun :: Sig B -> Int
fun (Inr Bar) = 1
```
This report came from https://stackoverflow.com/questions/16225281/gadts-failed-exhaustiveness-checking . Without strictness annotations, this is indeed a failed exhaustive check, due to bottom. I spoke to Richard Eisenberg at PLDI a few days ago, and he informed me that, if this warning did not disappear with strictness annotations, it was a bug. I added strictness annotations, and it did not disappear. I've tried all combinations of using strictness annotations and/or running with `{-# LANGUAGE Strict #-}`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Erroneous \"non-exhaustive pattern match\" using nested GADT with strictness annotation","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In the following code, `fun` contains an exhaustive pattern match, but, when compiling with -Wall, ghc erroneously reports a non-exhaustive pattern match.\r\n\r\n{{{#!hs\r\n\r\ndata (:+:) f g a = Inl !(f a) | Inr !(g a)\r\n\r\ndata A\r\ndata B\r\n\r\ndata Foo l where\r\n Foo :: Foo A\r\n\r\ndata Bar l where\r\n Bar :: Bar B\r\n\r\ntype Sig = Foo :+: Bar\r\n\r\nfun :: Sig B -> Int\r\nfun (Inr Bar) = 1\r\n\r\n}}}\r\n\r\nThis report came from https://stackoverflow.com/questions/16225281/gadts-failed-exhaustiveness-checking . Without strictness annotations, this is indeed a failed exhaustive check, due to bottom. I spoke to Richard Eisenberg at PLDI a few days ago, and he informed me that, if this warning did not disappear with strictness annotations, it was a bug. I added strictness annotations, and it did not disappear. I've tried all combinations of using strictness annotations and/or running with `{-# LANGUAGE Strict #-}`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15306First attempt at starting GHCI failed2019-07-07T18:13:21ZDaleBFirst attempt at starting GHCI failed```
PS C:\WINDOWS\system32> ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
ghc.exe: C:\F\G77\lib\libmingw32.a: Not a x86_64 PE+ file.
ghc.exe: getNumberOfSymbols: error whilst reading `CRTglob.o' header in `C:\F\G77\l...```
PS C:\WINDOWS\system32> ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
ghc.exe: C:\F\G77\lib\libmingw32.a: Not a x86_64 PE+ file.
ghc.exe: getNumberOfSymbols: error whilst reading `CRTglob.o' header in `C:\F\G77\lib\libmingw32.a': Unknown COFF_OBJ_TYPE.
ghc.exe: loadArchive: error whilst reading `C:\F\G77\lib\libmingw32.a'
ghc.exe: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-unknown-mingw32):
loadArchive "C:\\F\\G77\\lib\\libmingw32.a": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15307Incorrect -ddump-deriv parenthesization for GND'd fmap implementation2019-07-07T18:13:20ZRyan ScottIncorrect -ddump-deriv parenthesization for GND'd fmap implementationThis program:
```hs
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# OPTIONS_GHC -ddump-deriv #-}
module Bug where
newtype Foo a = MkFoo (Maybe a) deriving Functor
```
When compiling, displays incorrect code in its `-ddump-deriv` outpu...This program:
```hs
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# OPTIONS_GHC -ddump-deriv #-}
module Bug where
newtype Foo a = MkFoo (Maybe a) deriving Functor
```
When compiling, displays incorrect code in its `-ddump-deriv` output:
```
$ ghci Bug.hs
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/ryanglscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
==================== Derived instances ====================
Derived class instances:
instance GHC.Base.Functor Bug.Foo where
GHC.Base.fmap
= GHC.Prim.coerce
@(forall (a_a1y2 :: TYPE GHC.Types.LiftedRep)
(b_a1y3 :: TYPE GHC.Types.LiftedRep).
a_a1y2 -> b_a1y3 -> GHC.Base.Maybe a_a1y2 -> GHC.Base.Maybe b_a1y3)
@(forall (a_a1y2 :: TYPE GHC.Types.LiftedRep)
(b_a1y3 :: TYPE GHC.Types.LiftedRep).
a_a1y2 -> b_a1y3 -> Bug.Foo a_a1y2 -> Bug.Foo b_a1y3)
GHC.Base.fmap
(GHC.Base.<$)
= GHC.Prim.coerce
@(forall (a_a1y9 :: TYPE GHC.Types.LiftedRep)
(b_a1ya :: TYPE GHC.Types.LiftedRep).
a_a1y9 -> GHC.Base.Maybe b_a1ya -> GHC.Base.Maybe a_a1y9)
@(forall (a_a1y9 :: TYPE GHC.Types.LiftedRep)
(b_a1ya :: TYPE GHC.Types.LiftedRep).
a_a1y9 -> Bug.Foo b_a1ya -> Bug.Foo a_a1y9)
(GHC.Base.<$)
Derived type family instances:
Ok, one module loaded.
```
Notice how the type of `fmap` is `a_a1y2 -> b_a1y3 -> Bug.Foo a_a1y2 -> Bug.Foo b_a1y3`, not `(a_a1y2 -> b_a1y3) -> Bug.Foo a_a1y2 -> Bug.Foo b_a1y3`.
The culprit is the `nlHsFunTy` function, which is used to construct this function type in `typeToLHsType`:
```hs
nlHsFunTy :: LHsType (GhcPass p) -> LHsType (GhcPass p) -> LHsType (GhcPass p)
nlHsFunTy a b = noLoc (HsFunTy noExt a b)
```
This makes no attempt to add `HsParTy`s around any of its arguments. It's tempting to parenthesize //both// arguments, but interestingly, if you do this, then the type of `fmap` would become:
```hs
(a -> b) -> (Foo a -> Foo b)
```
This perhaps not what we want, since the parentheses around `Foo a -> Foo b` are redundant. Therefore, I propose that we adopt the same parenthesization scheme that `ppr_ty` uses for pretty-printing Core `Type`s:
```hs
ppr_ty ctxt_prec (IfaceFunTy ty1 ty2)
= -- We don't want to lose synonyms, so we mustn't use splitFunTys here.
maybeParen ctxt_prec funPrec $
sep [ppr_ty funPrec ty1, sep (ppr_fun_tail ty2)]
where
ppr_fun_tail (IfaceFunTy ty1 ty2)
= (arrow <+> ppr_ty funPrec ty1) : ppr_fun_tail ty2
ppr_fun_tail other_ty
= [arrow <+> pprIfaceType other_ty]
```
Namely, always parenthesize the argument type under `funPrec`, and recursively check the result type to see if it's also a function type, parenthesizing its arguments as necessary.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect -ddump-deriv parenthesization for GND'd fmap implementation","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GeneralizedNewtypeDeriving #-}\r\n{-# OPTIONS_GHC -ddump-deriv #-}\r\nmodule Bug where\r\n\r\nnewtype Foo a = MkFoo (Maybe a) deriving Functor\r\n}}}\r\n\r\nWhen compiling, displays incorrect code in its `-ddump-deriv` output:\r\n\r\n{{{\r\n$ ghci Bug.hs\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/ryanglscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\n\r\n==================== Derived instances ====================\r\nDerived class instances:\r\n instance GHC.Base.Functor Bug.Foo where\r\n GHC.Base.fmap\r\n = GHC.Prim.coerce\r\n @(forall (a_a1y2 :: TYPE GHC.Types.LiftedRep)\r\n (b_a1y3 :: TYPE GHC.Types.LiftedRep).\r\n a_a1y2 -> b_a1y3 -> GHC.Base.Maybe a_a1y2 -> GHC.Base.Maybe b_a1y3)\r\n @(forall (a_a1y2 :: TYPE GHC.Types.LiftedRep)\r\n (b_a1y3 :: TYPE GHC.Types.LiftedRep).\r\n a_a1y2 -> b_a1y3 -> Bug.Foo a_a1y2 -> Bug.Foo b_a1y3)\r\n GHC.Base.fmap\r\n (GHC.Base.<$)\r\n = GHC.Prim.coerce\r\n @(forall (a_a1y9 :: TYPE GHC.Types.LiftedRep)\r\n (b_a1ya :: TYPE GHC.Types.LiftedRep).\r\n a_a1y9 -> GHC.Base.Maybe b_a1ya -> GHC.Base.Maybe a_a1y9)\r\n @(forall (a_a1y9 :: TYPE GHC.Types.LiftedRep) \r\n (b_a1ya :: TYPE GHC.Types.LiftedRep). \r\n a_a1y9 -> Bug.Foo b_a1ya -> Bug.Foo a_a1y9) \r\n (GHC.Base.<$) \r\n \r\n \r\nDerived type family instances: \r\n \r\n \r\nOk, one module loaded.\r\n}}}\r\n\r\nNotice how the type of `fmap` is `a_a1y2 -> b_a1y3 -> Bug.Foo a_a1y2 -> Bug.Foo b_a1y3`, not `(a_a1y2 -> b_a1y3) -> Bug.Foo a_a1y2 -> Bug.Foo b_a1y3`.\r\n\r\nThe culprit is the `nlHsFunTy` function, which is used to construct this function type in `typeToLHsType`:\r\n\r\n{{{#!hs\r\nnlHsFunTy :: LHsType (GhcPass p) -> LHsType (GhcPass p) -> LHsType (GhcPass p)\r\nnlHsFunTy a b = noLoc (HsFunTy noExt a b)\r\n}}}\r\n\r\nThis makes no attempt to add `HsParTy`s around any of its arguments. It's tempting to parenthesize //both// arguments, but interestingly, if you do this, then the type of `fmap` would become:\r\n\r\n{{{#!hs\r\n(a -> b) -> (Foo a -> Foo b)\r\n}}}\r\n\r\nThis perhaps not what we want, since the parentheses around `Foo a -> Foo b` are redundant. Therefore, I propose that we adopt the same parenthesization scheme that `ppr_ty` uses for pretty-printing Core `Type`s:\r\n\r\n{{{#!hs\r\nppr_ty ctxt_prec (IfaceFunTy ty1 ty2)\r\n = -- We don't want to lose synonyms, so we mustn't use splitFunTys here.\r\n maybeParen ctxt_prec funPrec $\r\n sep [ppr_ty funPrec ty1, sep (ppr_fun_tail ty2)]\r\n where\r\n ppr_fun_tail (IfaceFunTy ty1 ty2)\r\n = (arrow <+> ppr_ty funPrec ty1) : ppr_fun_tail ty2\r\n ppr_fun_tail other_ty\r\n = [arrow <+> pprIfaceType other_ty]\r\n}}}\r\n\r\nNamely, always parenthesize the argument type under `funPrec`, and recursively check the result type to see if it's also a function type, parenthesizing its arguments as necessary.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15308Error message prints explicit kinds when it shouldn't2019-07-07T18:13:20ZRyan ScottError message prints explicit kinds when it shouldn'tWhen compiled, this program:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeInType #-}
{-# OPTIONS_GHC -fno-print-explicit-kinds #-}
module Bug where
import Data.Kind
data Foo (a :: Type) :: forall ...When compiled, this program:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeInType #-}
{-# OPTIONS_GHC -fno-print-explicit-kinds #-}
module Bug where
import Data.Kind
data Foo (a :: Type) :: forall b. (a -> b -> Type) -> Type where
MkFoo :: Foo a f
f :: Foo a f -> String
f = show
```
Gives the following error:
```
$ /opt/ghc/8.4.3/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:13:5: error:
• No instance for (Show (Foo a b f)) arising from a use of ‘show’
• In the expression: show
In an equation for ‘f’: f = show
|
13 | f = show
| ^^^^
```
This error message is slightly incorrect, however. In "`No instance for (Show (Foo a b f))`", it claims that `Foo` has three visible type parameters, but it only has two. (I've even made sure to enable `-fno-print-explicit-kinds` at the type to ensure that the invisible `b` kind shouldn't get printed, but it was anyway.)
This is a regression that was apparently introduced between GHC 8.0 and 8.2, since in GHC 8.0.2, it prints the correct thing:
```
$ /opt/ghc/8.0.2/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:13:5: error:
• No instance for (Show (Foo a f)) arising from a use of ‘show’
• In the expression: show
In an equation for ‘f’: f = show
```
But it does not in GHC 8.2.1:
```
$ /opt/ghc/8.2.1/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:13:5: error:
• No instance for (Show (Foo a b f)) arising from a use of ‘show’
• In the expression: show
In an equation for ‘f’: f = show
|
13 | f = show
| ^^^^
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Error message prints explicit kinds when it shouldn't","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When compiled, this program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n{-# LANGUAGE TypeInType #-}\r\n{-# OPTIONS_GHC -fno-print-explicit-kinds #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\n\r\ndata Foo (a :: Type) :: forall b. (a -> b -> Type) -> Type where\r\n MkFoo :: Foo a f\r\n\r\nf :: Foo a f -> String\r\nf = show\r\n}}}\r\n\r\nGives the following error:\r\n\r\n{{{\r\n$ /opt/ghc/8.4.3/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:13:5: error:\r\n • No instance for (Show (Foo a b f)) arising from a use of ‘show’\r\n • In the expression: show\r\n In an equation for ‘f’: f = show\r\n |\r\n13 | f = show\r\n | ^^^^\r\n}}}\r\n\r\nThis error message is slightly incorrect, however. In \"`No instance for (Show (Foo a b f))`\", it claims that `Foo` has three visible type parameters, but it only has two. (I've even made sure to enable `-fno-print-explicit-kinds` at the type to ensure that the invisible `b` kind shouldn't get printed, but it was anyway.)\r\n\r\nThis is a regression that was apparently introduced between GHC 8.0 and 8.2, since in GHC 8.0.2, it prints the correct thing:\r\n\r\n{{{\r\n$ /opt/ghc/8.0.2/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:13:5: error:\r\n • No instance for (Show (Foo a f)) arising from a use of ‘show’\r\n • In the expression: show\r\n In an equation for ‘f’: f = show\r\n}}}\r\n\r\nBut it does not in GHC 8.2.1:\r\n\r\n{{{\r\n$ /opt/ghc/8.2.1/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:13:5: error:\r\n • No instance for (Show (Foo a b f)) arising from a use of ‘show’\r\n • In the expression: show\r\n In an equation for ‘f’: f = show\r\n |\r\n13 | f = show\r\n | ^^^^\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15311MCoercion lacks an Outputable instance2019-07-07T18:13:19ZMatthew PickeringMCoercion lacks an Outputable instanceThere should be an outputable instance for `MCoercion` so it can be printed when debugging.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version ...There should be an outputable instance for `MCoercion` so it can be printed when debugging.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"MCoercion lacks an Outputable instance","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"There should be an outputable instance for `MCoercion` so it can be printed when debugging.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15314Internal error during typechecking of a hole in GHCi when there's shadowed id...2019-07-07T18:13:19ZmniipInternal error during typechecking of a hole in GHCi when there's shadowed identifiers```hs
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Prelude> let x = ()
Prelude> let x = ()
Prelude> :t _
<interactive>:1:1: error:
GHC internal error: ‘Ghci1.x’ is not in scope during type checking, but it passed th...```hs
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Prelude> let x = ()
Prelude> let x = ()
Prelude> :t _
<interactive>:1:1: error:
GHC internal error: ‘Ghci1.x’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: []
```
Seems to only happen when there were two identifiers defined with the same name.
As verified by mpickering on IRC this isn't reproducible in 8.2.2.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Internal error during typechecking of a hole in GHCi when there's shadowed identifiers","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\nPrelude> let x = ()\r\nPrelude> let x = ()\r\nPrelude> :t _\r\n\r\n<interactive>:1:1: error:\r\n GHC internal error: ‘Ghci1.x’ is not in scope during type checking, but it passed the renamer\r\n tcl_env of environment: []\r\n}}}\r\n\r\nSeems to only happen when there were two identifiers defined with the same name.\r\n\r\nAs verified by mpickering on IRC this isn't reproducible in 8.2.2.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15315Renamer plugins could run after each group has been renamed2021-06-21T09:36:49ZMatthew PickeringRenamer plugins could run after each group has been renamedIn discussion with Ben, he suggested that it might be possible for a renamer plugin to run after each group had been renamed. This would then make it possible to modify renamed bindings.
Currently, the interface for renamer plugins is q...In discussion with Ben, he suggested that it might be possible for a renamer plugin to run after each group had been renamed. This would then make it possible to modify renamed bindings.
Currently, the interface for renamer plugins is quite strange and they run just before typechecker plugins in the implementation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Renamer plugins could run after each group has been renamed","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["plugins"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In discussion with Ben, he suggested that it might be possible for a renamer plugin to run after each group had been renamed. This would then make it possible to modify renamed bindings. \r\n\r\nCurrently, the interface for renamer plugins is quite strange and they run just before typechecker plugins in the implementation. ","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15316Regarding coherence and implication loops in presence of QuantifiedConstraints2020-10-03T12:38:44ZmniipRegarding coherence and implication loops in presence of QuantifiedConstraintsFirst of all this piece of code:
```hs
{-# LANGUAGE RankNTypes, QuantifiedConstraints #-}
-- NB: disabling these if enabled:
{-# LANGUAGE NoUndecidableInstances, NoUndecidableSuperClasses #-}
import Data.Proxy
class Class a where
me...First of all this piece of code:
```hs
{-# LANGUAGE RankNTypes, QuantifiedConstraints #-}
-- NB: disabling these if enabled:
{-# LANGUAGE NoUndecidableInstances, NoUndecidableSuperClasses #-}
import Data.Proxy
class Class a where
method :: a
subsume :: (Class a => Class b) => Proxy a -> Proxy b -> ((Class a => Class b) => r) -> r
subsume _ _ x = x
value :: Proxy a -> a
value p = subsume p p method
```
This produces a nonterminating `value` even though nothing warranting recursion was used.
Adding:
```hs
value' :: Class a => Proxy a -> a
value' p = subsume p p method
```
Produces a `value'` that is legitimately equivalent to `method` in that it equals to the value in the dictionary whenever an instance exists (and doesn't typecheck otherwise). Thus two identical expressions in different instance contexts end up having different values (violating coherence?)
If we add:
```hs
joinSubsume :: Proxy a -> ((Class a => Class a) => r) -> r
joinSubsume p x = subsume p p x
```
The fact that this typechecks suggests that GHC is able to infer `Class a => Class a` at will, which doesn't seem wrong. However, the fact that `Class a` is solved from `Class a => Class a` via an infinite loop of implication constraints is questionable. Probably even outright wrong in absence of `UndecidableInstances`.
Another issue is the following:
```hs
{-# LANGUAGE ConstraintKinds #-}
subsume' :: Proxy c -> ((c => c) => r) -> r
subsume' _ x = x
```
```
• Reduction stack overflow; size = 201
When simplifying the following type: c
Use -freduction-depth=0 to disable this check
(any upper bound you could choose might fail unpredictably with
minor updates to GHC, so disabling the check is recommended if
you're sure that type checking should terminate)
• In the type signature:
subsume' :: Proxy c -> ((c => c) => r) -> r
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Regarding coherence and implication loops in presence of QuantifiedConstraints","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["QuantifiedConstraints"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"First of all this piece of code:\r\n{{{#!hs\r\n{-# LANGUAGE RankNTypes, QuantifiedConstraints #-}\r\n-- NB: disabling these if enabled:\r\n{-# LANGUAGE NoUndecidableInstances, NoUndecidableSuperClasses #-}\r\n\r\nimport Data.Proxy\r\n\r\nclass Class a where\r\n\t method :: a\r\n\r\nsubsume :: (Class a => Class b) => Proxy a -> Proxy b -> ((Class a => Class b) => r) -> r\r\nsubsume _ _ x = x\r\n\r\nvalue :: Proxy a -> a\r\nvalue p = subsume p p method\r\n}}}\r\n\r\nThis produces a nonterminating `value` even though nothing warranting recursion was used.\r\n\r\nAdding:\r\n{{{#!hs\r\nvalue' :: Class a => Proxy a -> a\r\nvalue' p = subsume p p method\r\n}}}\r\nProduces a `value'` that is legitimately equivalent to `method` in that it equals to the value in the dictionary whenever an instance exists (and doesn't typecheck otherwise). Thus two identical expressions in different instance contexts end up having different values (violating coherence?)\r\n\r\nIf we add:\r\n{{{#!hs\r\njoinSubsume :: Proxy a -> ((Class a => Class a) => r) -> r\r\njoinSubsume p x = subsume p p x\r\n}}}\r\nThe fact that this typechecks suggests that GHC is able to infer `Class a => Class a` at will, which doesn't seem wrong. However, the fact that `Class a` is solved from `Class a => Class a` via an infinite loop of implication constraints is questionable. Probably even outright wrong in absence of `UndecidableInstances`.\r\n\r\nAnother issue is the following:\r\n{{{#!hs\r\n{-# LANGUAGE ConstraintKinds #-}\r\nsubsume' :: Proxy c -> ((c => c) => r) -> r\r\nsubsume' _ x = x\r\n}}}\r\n{{{\r\n • Reduction stack overflow; size = 201\r\n When simplifying the following type: c\r\n Use -freduction-depth=0 to disable this check\r\n (any upper bound you could choose might fail unpredictably with\r\n minor updates to GHC, so disabling the check is recommended if\r\n you're sure that type checking should terminate)\r\n • In the type signature:\r\n subsume' :: Proxy c -> ((c => c) => r) -> r\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15317GHCi panic when trying to avoid GHC_OPTIONS -O warning2019-07-07T18:13:18ZChaiTRexGHCi panic when trying to avoid GHC_OPTIONS -O warningFollowing the advice on [an answer to "How can I load optimized code in GHCI?"](https://stackoverflow.com/a/27881726/7208029), I get a GHCi panic. Running `ghc Luhn` succeeds just fine. On running `ghci Luhn`, I get:
```
$ ghci Luhn
GHC...Following the advice on [an answer to "How can I load optimized code in GHCI?"](https://stackoverflow.com/a/27881726/7208029), I get a GHCi panic. Running `ghc Luhn` succeeds just fine. On running `ghci Luhn`, I get:
```
$ ghci Luhn
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Luhn ( Luhn.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-unknown-linux):
floatExpr tick break<15>()
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Contents of `Luhn.hs`:
```hs
{-# OPTIONS_GHC -fobject-code -O3 #-}
module Luhn (checkLuhn) where
import Data.Bits (shiftL)
import Data.Char (digitToInt)
import Data.List (foldl')
-- Quickly gets a list of digits from a nonnegative Integer
-- Gives error for negative inputs
-- Uses GMP's show for greatly-improved speed over GMP's div and mod
toDigits :: Integer -> [Int]
{-# INLINE toDigits #-}
toDigits = map digitToInt . show
-- Quickly gets the same result as iteratively getting the digit sum of a nonnegative Int until the digit sum is only one digit long
-- Gives an erroneous value for negative inputs
repeatedDigitSum :: Int -> Int
{-# INLINE repeatedDigitSum #-}
repeatedDigitSum n = (n - 1) `rem` 9 + 1
-- Gets the Luhn sum, which is zero for valid inputs, of a list of digits
-- Uses Data.Bits.shiftL to quickly double
luhnSum :: [Int] -> Int
{-# INLINE luhnSum #-}
luhnSum = fromInteger . flip rem 10 . foldl' (+) 0 . zipWith ($) (cycle [toInteger, toInteger . repeatedDigitSum . flip shiftL 1])
-- Checks whether a nonnegative Integer passes the Luhn algorithm
-- Negative inputs are False, since the Luhn algorithm is intended for unsigned inputs
checkLuhn :: Integer -> Bool
{-# INLINABLE checkLuhn #-}
checkLuhn n = (n >= 0) && ((== 0) . luhnSum . reverse . toDigits) n
```
Strangely, `ghci -fobject-code -O3 Luhn` works just great, so apparently it's not a problem with the switches?
----
`ghc --version`:
```
The Glorious Glasgow Haskell Compilation System, version 7.10.3
```
Ubuntu (and presumably Debian) package information:
```
ghc:
Installed: 7.10.3-7
Candidate: 7.10.3-7
Version table:
*** 7.10.3-7 500
500 http://mirror.atlantic.net/ubuntu xenial/universe amd64 Packages
100 /var/lib/dpkg/status
```7.10.4https://gitlab.haskell.org/ghc/ghc/-/issues/15318Core Lint error involving newtype family instances with wrappers2019-07-07T18:13:18ZRyan ScottCore Lint error involving newtype family instances with wrappersThe following program gives a Core Lint error on GHC 8.4 and later:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
data family Sn a
newtype instance Sn (Either a b) wher...The following program gives a Core Lint error on GHC 8.4 and later:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
data family Sn a
newtype instance Sn (Either a b) where
SnC :: forall b a. Char -> Sn (Either a b)
```
```
$ /opt/ghc/8.4.3/bin/ghc -dcore-lint Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
*** Core Lint errors : in result of Tidy Core ***
<no location info>: warning:
[in body of lambda with binder dt_aZm :: Char]
From-type of Cast differs from type of enclosed expression
From-type: R:SnEither a_auS b_auR
Type of enclosed expr: Sn (Either a_auS b_auR)
Actual enclosed expr: dt_aZm
`cast` (Sym (N:R:SnEither[0]
<a_auS>_N <b_auR>_N) ; Sym (D:R:SnEither0[0]
<a_auS>_N <b_auR>_N)
:: (Char :: *) ~R# (Sn (Either a_auS b_auR) :: *))
Coercion used in cast: Sym (D:R:SnEither0[0] <a_auS>_N <b_auR>_N)
*** Offending Program ***
$WSnC [InlPrag=INLINE[2]] :: forall b a. Char -> Sn (Either a b)
[GblId[DataConWrapper],
Arity=1,
Caf=NoCafRefs,
Str=<L,U>,
Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True,
WorkFree=True, Expandable=True,
Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)
Tmpl= \ (@ b_auR) (@ a_auS) (dt_aZm [Occ=Once] :: Char) ->
(dt_aZm
`cast` (Sym (N:R:SnEither[0]
<a_auS>_N <b_auR>_N) ; Sym (D:R:SnEither0[0] <a_auS>_N <b_auR>_N)
:: (Char :: *) ~R# (Sn (Either a_auS b_auR) :: *)))
`cast` (Sym (D:R:SnEither0[0] <a_auS>_N <b_auR>_N)
:: (R:SnEither a_auS b_auR :: *)
~R# (Sn (Either a_auS b_auR) :: *))}]
$WSnC
= \ (@ b_auR) (@ a_auS) (dt_aZm [Occ=Once] :: Char) ->
(dt_aZm
`cast` (Sym (N:R:SnEither[0]
<a_auS>_N <b_auR>_N) ; Sym (D:R:SnEither0[0] <a_auS>_N <b_auR>_N)
:: (Char :: *) ~R# (Sn (Either a_auS b_auR) :: *)))
`cast` (Sym (D:R:SnEither0[0] <a_auS>_N <b_auR>_N)
:: (R:SnEither a_auS b_auR :: *)
~R# (Sn (Either a_auS b_auR) :: *))
$trModule1_r10g :: Addr#
[GblId, Caf=NoCafRefs]
$trModule1_r10g = "main"#
$trModule2_r10D :: TrName
[GblId, Caf=NoCafRefs]
$trModule2_r10D = TrNameS $trModule1_r10g
$trModule3_r10E :: Addr#
[GblId, Caf=NoCafRefs]
$trModule3_r10E = "Bug"#
$trModule4_r10F :: TrName
[GblId, Caf=NoCafRefs]
$trModule4_r10F = TrNameS $trModule3_r10E
$trModule :: Module
[GblId, Caf=NoCafRefs]
$trModule = Module $trModule2_r10D $trModule4_r10F
$krep_r10G :: KindRep
[GblId]
$krep_r10G = KindRepTyConApp $tcChar ([] @ KindRep)
$krep1_r10H :: KindRep
[GblId, Caf=NoCafRefs]
$krep1_r10H = KindRepVar 1#
$krep2_r10I :: KindRep
[GblId, Caf=NoCafRefs]
$krep2_r10I = KindRepVar 0#
$krep3_r10J :: [KindRep]
[GblId, Caf=NoCafRefs]
$krep3_r10J = : @ KindRep $krep2_r10I ([] @ KindRep)
$krep4_r10K :: [KindRep]
[GblId, Caf=NoCafRefs]
$krep4_r10K = : @ KindRep $krep1_r10H $krep3_r10J
$krep5_r10L :: KindRep
[GblId]
$krep5_r10L = KindRepTyConApp $tcEither $krep4_r10K
$tcSn1_r10M :: Addr#
[GblId, Caf=NoCafRefs]
$tcSn1_r10M = "Sn"#
$tcSn2_r10N :: TrName
[GblId, Caf=NoCafRefs]
$tcSn2_r10N = TrNameS $tcSn1_r10M
$tcSn :: TyCon
[GblId]
$tcSn
= TyCon
461968091845555535##
16320521938866097056##
$trModule
$tcSn2_r10N
0#
krep$*Arr*
$krep6_r10O :: [KindRep]
[GblId]
$krep6_r10O = : @ KindRep $krep5_r10L ([] @ KindRep)
$krep7_r10P :: KindRep
[GblId]
$krep7_r10P = KindRepTyConApp $tcSn $krep6_r10O
$krep8_r10Q :: KindRep
[GblId]
$krep8_r10Q = KindRepFun $krep_r10G $krep7_r10P
$tc'SnC1_r10R :: Addr#
[GblId, Caf=NoCafRefs]
$tc'SnC1_r10R = "'SnC"#
$tc'SnC2_r10S :: TrName
[GblId, Caf=NoCafRefs]
$tc'SnC2_r10S = TrNameS $tc'SnC1_r10R
$tc'SnC :: TyCon
[GblId]
$tc'SnC
= TyCon
3818830880305712792##
17484539998814842835##
$trModule
$tc'SnC2_r10S
2#
$krep8_r10Q
*** End of Offense ***
<no location info>: error:
Compilation had errors
```
If we look at the Core for `$WSnC`, we see the culprit:
```
$WSnC
= \ (@ b_auR) (@ a_auS) (dt_aZm [Occ=Once] :: Char) ->
(dt_aZm
`cast` (Sym (N:R:SnEither[0]
<a_auS>_N <b_auR>_N) ; Sym (D:R:SnEither0[0] <a_auS>_N <b_auR>_N)
:: (Char :: *) ~R# (Sn (Either a_auS b_auR) :: *)))
`cast` (Sym (D:R:SnEither0[0] <a_auS>_N <b_auR>_N)
:: (R:SnEither a_auS b_auR :: *)
~R# (Sn (Either a_auS b_auR) :: *))
```
The inner cast goes from `Char` to `Sn (Either a b)`, but then the outer cast goes from `R:SnEither a b` to `Sn (Either a b)`, which is not transitive.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mpickering |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Core Lint error involving newtype family instances with wrappers","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["TypeFamilies"],"differentials":[],"test_case":"","architecture":"","cc":["mpickering"],"type":"Bug","description":"The following program gives a Core Lint error on GHC 8.4 and later:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule Bug where\r\n\r\ndata family Sn a\r\nnewtype instance Sn (Either a b) where\r\n SnC :: forall b a. Char -> Sn (Either a b)\r\n}}}\r\n{{{\r\n$ /opt/ghc/8.4.3/bin/ghc -dcore-lint Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n*** Core Lint errors : in result of Tidy Core ***\r\n<no location info>: warning:\r\n [in body of lambda with binder dt_aZm :: Char]\r\n From-type of Cast differs from type of enclosed expression\r\n From-type: R:SnEither a_auS b_auR\r\n Type of enclosed expr: Sn (Either a_auS b_auR)\r\n Actual enclosed expr: dt_aZm\r\n `cast` (Sym (N:R:SnEither[0]\r\n <a_auS>_N <b_auR>_N) ; Sym (D:R:SnEither0[0]\r\n <a_auS>_N <b_auR>_N)\r\n :: (Char :: *) ~R# (Sn (Either a_auS b_auR) :: *))\r\n Coercion used in cast: Sym (D:R:SnEither0[0] <a_auS>_N <b_auR>_N)\r\n*** Offending Program ***\r\n$WSnC [InlPrag=INLINE[2]] :: forall b a. Char -> Sn (Either a b)\r\n[GblId[DataConWrapper],\r\n Arity=1,\r\n Caf=NoCafRefs,\r\n Str=<L,U>,\r\n Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True,\r\n WorkFree=True, Expandable=True,\r\n Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)\r\n Tmpl= \\ (@ b_auR) (@ a_auS) (dt_aZm [Occ=Once] :: Char) ->\r\n (dt_aZm\r\n `cast` (Sym (N:R:SnEither[0]\r\n <a_auS>_N <b_auR>_N) ; Sym (D:R:SnEither0[0] <a_auS>_N <b_auR>_N)\r\n :: (Char :: *) ~R# (Sn (Either a_auS b_auR) :: *)))\r\n `cast` (Sym (D:R:SnEither0[0] <a_auS>_N <b_auR>_N)\r\n :: (R:SnEither a_auS b_auR :: *)\r\n ~R# (Sn (Either a_auS b_auR) :: *))}]\r\n$WSnC\r\n = \\ (@ b_auR) (@ a_auS) (dt_aZm [Occ=Once] :: Char) ->\r\n (dt_aZm\r\n `cast` (Sym (N:R:SnEither[0]\r\n <a_auS>_N <b_auR>_N) ; Sym (D:R:SnEither0[0] <a_auS>_N <b_auR>_N)\r\n :: (Char :: *) ~R# (Sn (Either a_auS b_auR) :: *)))\r\n `cast` (Sym (D:R:SnEither0[0] <a_auS>_N <b_auR>_N)\r\n :: (R:SnEither a_auS b_auR :: *)\r\n ~R# (Sn (Either a_auS b_auR) :: *))\r\n\r\n$trModule1_r10g :: Addr#\r\n[GblId, Caf=NoCafRefs]\r\n$trModule1_r10g = \"main\"#\r\n\r\n$trModule2_r10D :: TrName\r\n[GblId, Caf=NoCafRefs]\r\n$trModule2_r10D = TrNameS $trModule1_r10g\r\n\r\n$trModule3_r10E :: Addr#\r\n[GblId, Caf=NoCafRefs]\r\n$trModule3_r10E = \"Bug\"#\r\n\r\n$trModule4_r10F :: TrName\r\n[GblId, Caf=NoCafRefs]\r\n$trModule4_r10F = TrNameS $trModule3_r10E\r\n\r\n$trModule :: Module\r\n[GblId, Caf=NoCafRefs]\r\n$trModule = Module $trModule2_r10D $trModule4_r10F\r\n\r\n$krep_r10G :: KindRep\r\n[GblId]\r\n$krep_r10G = KindRepTyConApp $tcChar ([] @ KindRep)\r\n\r\n$krep1_r10H :: KindRep\r\n[GblId, Caf=NoCafRefs]\r\n$krep1_r10H = KindRepVar 1#\r\n\r\n$krep2_r10I :: KindRep\r\n[GblId, Caf=NoCafRefs]\r\n$krep2_r10I = KindRepVar 0#\r\n\r\n$krep3_r10J :: [KindRep]\r\n[GblId, Caf=NoCafRefs]\r\n$krep3_r10J = : @ KindRep $krep2_r10I ([] @ KindRep)\r\n\r\n$krep4_r10K :: [KindRep]\r\n[GblId, Caf=NoCafRefs]\r\n$krep4_r10K = : @ KindRep $krep1_r10H $krep3_r10J\r\n\r\n$krep5_r10L :: KindRep\r\n[GblId]\r\n$krep5_r10L = KindRepTyConApp $tcEither $krep4_r10K\r\n\r\n$tcSn1_r10M :: Addr#\r\n[GblId, Caf=NoCafRefs]\r\n$tcSn1_r10M = \"Sn\"#\r\n\r\n$tcSn2_r10N :: TrName\r\n[GblId, Caf=NoCafRefs]\r\n$tcSn2_r10N = TrNameS $tcSn1_r10M\r\n\r\n$tcSn :: TyCon\r\n[GblId]\r\n$tcSn\r\n = TyCon\r\n 461968091845555535##\r\n 16320521938866097056##\r\n $trModule\r\n $tcSn2_r10N\r\n 0#\r\n krep$*Arr*\r\n\r\n$krep6_r10O :: [KindRep]\r\n[GblId]\r\n$krep6_r10O = : @ KindRep $krep5_r10L ([] @ KindRep)\r\n\r\n$krep7_r10P :: KindRep\r\n[GblId]\r\n$krep7_r10P = KindRepTyConApp $tcSn $krep6_r10O\r\n\r\n$krep8_r10Q :: KindRep\r\n[GblId]\r\n$krep8_r10Q = KindRepFun $krep_r10G $krep7_r10P\r\n\r\n$tc'SnC1_r10R :: Addr#\r\n[GblId, Caf=NoCafRefs]\r\n$tc'SnC1_r10R = \"'SnC\"#\r\n\r\n$tc'SnC2_r10S :: TrName\r\n[GblId, Caf=NoCafRefs]\r\n$tc'SnC2_r10S = TrNameS $tc'SnC1_r10R\r\n\r\n$tc'SnC :: TyCon\r\n[GblId]\r\n$tc'SnC\r\n = TyCon\r\n 3818830880305712792##\r\n 17484539998814842835##\r\n $trModule\r\n $tc'SnC2_r10S\r\n 2#\r\n $krep8_r10Q\r\n\r\n*** End of Offense ***\r\n\r\n\r\n<no location info>: error: \r\nCompilation had errors\r\n}}}\r\n\r\nIf we look at the Core for `$WSnC`, we see the culprit:\r\n\r\n{{{\r\n$WSnC\r\n = \\ (@ b_auR) (@ a_auS) (dt_aZm [Occ=Once] :: Char) ->\r\n (dt_aZm\r\n `cast` (Sym (N:R:SnEither[0]\r\n <a_auS>_N <b_auR>_N) ; Sym (D:R:SnEither0[0] <a_auS>_N <b_auR>_N)\r\n :: (Char :: *) ~R# (Sn (Either a_auS b_auR) :: *)))\r\n `cast` (Sym (D:R:SnEither0[0] <a_auS>_N <b_auR>_N)\r\n :: (R:SnEither a_auS b_auR :: *)\r\n ~R# (Sn (Either a_auS b_auR) :: *))\r\n}}}\r\n\r\nThe inner cast goes from `Char` to `Sn (Either a b)`, but then the outer cast goes from `R:SnEither a b` to `Sn (Either a b)`, which is not transitive.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15319Configurable/overridable settings file2023-07-17T18:00:29ZMathieu BoespflugConfigurable/overridable settings fileGHC ships with a `settings` file. This file specifies what was known about the C compiler at GHC `./configure` time (whether to pass `-no-pie` etc, the path to the C compiler etc). Fortunately, I can override at least some of the entries...GHC ships with a `settings` file. This file specifies what was known about the C compiler at GHC `./configure` time (whether to pass `-no-pie` etc, the path to the C compiler etc). Fortunately, I can override at least some of the entries of the `settings` file, e.g. to use a different GCC than the one GHC got to know about during the `./configure` phase. This is important because is multi-lingual projects, sometimes the build tool for the C++ part of the code wants a special compiler, which GHC should also be using when compiling C.
The problem is that I can't override \*everything\*. If I supply via `-pgmc` a compiler that doesn't understand `-no-pie`, then I can't tell GHC to not pass `-no-pie`. Because I can't supply my own `settings` file, or (equivalently) there exists no CLI flag that allows me to override that particular entry in the `settings` file.
What I'd like is something like:
```
$ ghc -settings /path/to/settings/file
```
that subsumes `-pgmc` and other such flags. I'd be able to tell GHC in one go which compiler I want to use, and what flags GHC should or should not pass to that compiler depending on the features of the compiler.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Configurable/overridable settings file","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GHC ships with a `settings` file. This file specifies what was known about the C compiler at GHC `./configure` time (whether to pass `-no-pie` etc, the path to the C compiler etc). Fortunately, I can override at least some of the entries of the `settings` file, e.g. to use a different GCC than the one GHC got to know about during the `./configure` phase. This is important because is multi-lingual projects, sometimes the build tool for the C++ part of the code wants a special compiler, which GHC should also be using when compiling C.\r\n\r\nThe problem is that I can't override *everything*. If I supply via `-pgmc` a compiler that doesn't understand `-no-pie`, then I can't tell GHC to not pass `-no-pie`. Because I can't supply my own `settings` file, or (equivalently) there exists no CLI flag that allows me to override that particular entry in the `settings` file.\r\n\r\nWhat I'd like is something like:\r\n{{{\r\n$ ghc -settings /path/to/settings/file\r\n}}}\r\n\r\nthat subsumes `-pgmc` and other such flags. I'd be able to tell GHC in one go which compiler I want to use, and what flags GHC should or should not pass to that compiler depending on the features of the compiler.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15321Typed holes in Template Haskell splices produce bewildering error messages2019-07-07T18:13:14ZRyan ScottTyped holes in Template Haskell splices produce bewildering error messagesIf you compile this program with GHC 8.4 or later:
```hs
{-# LANGUAGE TemplateHaskell #-}
module Bug where
foo :: String
foo = test
bar :: String
bar = $(_ "baz")
```
You'll be greeted with a rather strange error message:
```
$ /opt...If you compile this program with GHC 8.4 or later:
```hs
{-# LANGUAGE TemplateHaskell #-}
module Bug where
foo :: String
foo = test
bar :: String
bar = $(_ "baz")
```
You'll be greeted with a rather strange error message:
```
$ /opt/ghc/8.4.3/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:8:7: error:
• GHC stage restriction:
‘foo’ is used in a top-level splice, quasi-quote, or annotation,
and must be imported, not defined locally
• In the untyped splice: $(_ "baz")
|
8 | bar = $(_ "baz")
| ^^^^^^^^^^
```
`foo` has nothing do with how `bar`'s RHS should be typechecked, so why is it being mentioned in the error message?
In contrast, GHC 8.2 and earlier gives you quite a nice error message:
```
$ /opt/ghc/8.2.2/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:8:9: error:
• Found hole: _ :: [Char] -> Language.Haskell.TH.Lib.ExpQ
• In the expression: _
In the expression: _ "baz"
In the untyped splice: $(_ "baz")
|
8 | bar = $(_ "baz")
| ^
```
Tritlo, my hunch is that the valid hole fits stuff is the culprit here. Do you think that perhaps when building the subsumption graph, we are trying to check the hole's type against that of `foo`, which causes the stage restriction error? If so, do you think it is possible to work around this?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Tritlo |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typed holes in Template Haskell splices produce bewildering error messages","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["TypedHoles"],"differentials":[],"test_case":"","architecture":"","cc":["Tritlo"],"type":"Bug","description":"If you compile this program with GHC 8.4 or later:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Bug where\r\n\r\nfoo :: String\r\nfoo = test\r\n\r\nbar :: String\r\nbar = $(_ \"baz\")\r\n}}}\r\n\r\nYou'll be greeted with a rather strange error message:\r\n\r\n{{{\r\n$ /opt/ghc/8.4.3/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:8:7: error:\r\n • GHC stage restriction:\r\n ‘foo’ is used in a top-level splice, quasi-quote, or annotation,\r\n and must be imported, not defined locally\r\n • In the untyped splice: $(_ \"baz\")\r\n |\r\n8 | bar = $(_ \"baz\")\r\n | ^^^^^^^^^^\r\n}}}\r\n\r\n`foo` has nothing do with how `bar`'s RHS should be typechecked, so why is it being mentioned in the error message?\r\n\r\nIn contrast, GHC 8.2 and earlier gives you quite a nice error message:\r\n\r\n{{{\r\n$ /opt/ghc/8.2.2/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:8:9: error:\r\n • Found hole: _ :: [Char] -> Language.Haskell.TH.Lib.ExpQ\r\n • In the expression: _\r\n In the expression: _ \"baz\"\r\n In the untyped splice: $(_ \"baz\")\r\n |\r\n8 | bar = $(_ \"baz\")\r\n | ^\r\n}}}\r\n\r\nTritlo, my hunch is that the valid hole fits stuff is the culprit here. Do you think that perhaps when building the subsumption graph, we are trying to check the hole's type against that of `foo`, which causes the stage restriction error? If so, do you think it is possible to work around this?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15323mkGadtDecl does not set con_forall correctly2019-07-07T18:13:10ZAlan ZimmermanmkGadtDecl does not set con_forall correctlyA GADT declaration surrounded in parens does not det the `con_forall` field correctly.
e.g.
```hs
data MaybeDefault v where
TestParens :: (forall v . (Eq v) => MaybeDefault v)
```
<details><summary>Trac metadata</summary>
| Trac...A GADT declaration surrounded in parens does not det the `con_forall` field correctly.
e.g.
```hs
data MaybeDefault v where
TestParens :: (forall v . (Eq v) => MaybeDefault v)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"mkGadtDecl does not set con_forall correctly","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A GADT declaration surrounded in parens does not det the `con_forall` field correctly.\r\n\r\ne.g.\r\n\r\n{{{#!hs\r\ndata MaybeDefault v where\r\n TestParens :: (forall v . (Eq v) => MaybeDefault v)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/15324-ddump-splices does not parenthesize rank-n contexts correctly2019-07-07T18:13:09ZRyan Scott-ddump-splices does not parenthesize rank-n contexts correctlyRyan discovers another `-ddump-splices` bug—news at 11:
```hs
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug where
$([d| f :: forall a. (Show a => a) -> a
f _ = undefine...Ryan discovers another `-ddump-splices` bug—news at 11:
```hs
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug where
$([d| f :: forall a. (Show a => a) -> a
f _ = undefined
|])
```
```
$ /opt/ghc/8.4.3/bin/ghci Bug.hs -dsuppress-uniques
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:(6,3)-(8,6): Splicing declarations
[d| f :: forall a. (Show a => a) -> a
f _ = undefined |]
======>
f :: forall a. Show a => a -> a
f _ = undefined
```
Notice that `f`'s type signature is pretty-printed as `forall a. Show a => a -> a`, which is just wrong. Patch incoming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-ddump-splices does not parenthesize rank-n contexts correctly","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Ryan discovers another `-ddump-splices` bug—news at 11:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE RankNTypes #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# OPTIONS_GHC -ddump-splices #-}\r\nmodule Bug where\r\n\r\n$([d| f :: forall a. (Show a => a) -> a\r\n f _ = undefined\r\n |])\r\n}}}\r\n{{{\r\n$ /opt/ghc/8.4.3/bin/ghci Bug.hs -dsuppress-uniques\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help \r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\nBug.hs:(6,3)-(8,6): Splicing declarations\r\n [d| f :: forall a. (Show a => a) -> a\r\n f _ = undefined |]\r\n ======>\r\n f :: forall a. Show a => a -> a\r\n f _ = undefined\r\n}}}\r\n\r\nNotice that `f`'s type signature is pretty-printed as `forall a. Show a => a -> a`, which is just wrong. Patch incoming.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15325GHCi panic in getIdFromTrivialExpr with -fdefer-type-errors2020-11-18T11:28:48ZdramforeverGHCi panic in getIdFromTrivialExpr with -fdefer-type-errors## Steps to reproduce:
Put this in `bug.hs`: (It's a very failed attempt to make a polymorphic list maker function.)
```hs
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
module ...## Steps to reproduce:
Put this in `bug.hs`: (It's a very failed attempt to make a polymorphic list maker function.)
```hs
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
module PolyvariadicFunctions where
class PolyList e a where
polyList :: ([e] -> [e]) -> a
-- instance PolyList e [e] where
-- polyList dl = dl []
instance (e ~ e2, PolyList e a) => PolyList e (e2 -> a) where
polyList dl x = polyList ((x :) . dl)
plh :: [Integer]
plh = polyList 1 2 3 4 5
```
Load it in GHCi with `-fdefer-type-errors` to get the following output. Note the 'panic' in the end, and also note that the last `>` line is a no-module-loaded GHCi prompt.
The question marks `?` seem to be encoding related and not relevant.
This panic not seem to occur with GHC the compiler. The rest of the error messages seem otherwise identical.
```
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Prelude> :set -fdefer-type-errors
Prelude> :l bug.hs
[1 of 1] Compiling PolyvariadicFunctions ( bug.hs, interpreted )
bug.hs:17:7: warning: [-Wdeferred-type-errors]
? No instance for (PolyList t0 [Integer])
arising from a use of ‘polyList’
? In the expression: polyList 1 2 3 4 5
In an equation for ‘plh’: plh = polyList 1 2 3 4 5
|
17 | plh = polyList 1 2 3 4 5
| ^^^^^^^^^^^^^^^^^^
bug.hs:17:16: warning: [-Wdeferred-type-errors]
? No instance for (Num ([t0] -> [t0])) arising from the literal ‘1’
(maybe you haven't applied a function to enough arguments?)
? In the first argument of ‘polyList’, namely ‘1’
In the expression: polyList 1 2 3 4 5
In an equation for ‘plh’: plh = polyList 1 2 3 4 5
|
17 | plh = polyList 1 2 3 4 5
| ^
bug.hs:17:18: warning: [-Wdeferred-type-errors]
? Ambiguous type variable ‘t0’ arising from the literal ‘2’
prevents the constraint ‘(Num t0)’ from being solved.
Probable fix: use a type annotation to specify what ‘t0’ should be.
These potential instances exist:
instance Num Integer -- Defined in ‘GHC.Num’
instance Num Double -- Defined in ‘GHC.Float’
instance Num Float -- Defined in ‘GHC.Float’
...plus two others
(use -fprint-potential-instances to see them all)
? In the second argument of ‘polyList’, namely ‘2’
In the expression: polyList 1 2 3 4 5
In an equation for ‘plh’: plh = polyList 1 2 3 4 5
|
17 | plh = polyList 1 2 3 4 5
| ^
ghc.exe: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-unknown-mingw32):
getIdFromTrivialExpr
case $dNum_a1Be of wild_00 { }
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler\utils\Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler\\coreSyn\\CoreUtils.hs:883:18 in ghc:CoreUtils
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panic in getIdFromTrivialExpr with -fdefer-type-errors","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"== Steps to reproduce:\r\n\r\nPut this in `bug.hs`: (It's a very failed attempt to make a polymorphic list maker function.)\r\n\r\n{{{#!hs\r\n{-# LANGUAGE FlexibleInstances #-}\r\n{-# LANGUAGE MultiParamTypeClasses #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\nmodule PolyvariadicFunctions where\r\n\r\nclass PolyList e a where\r\n polyList :: ([e] -> [e]) -> a\r\n\r\n-- instance PolyList e [e] where\r\n-- polyList dl = dl []\r\n\r\ninstance (e ~ e2, PolyList e a) => PolyList e (e2 -> a) where\r\n polyList dl x = polyList ((x :) . dl)\r\n\r\nplh :: [Integer]\r\nplh = polyList 1 2 3 4 5\r\n}}}\r\n\r\nLoad it in GHCi with `-fdefer-type-errors` to get the following output. Note the 'panic' in the end, and also note that the last `>` line is a no-module-loaded GHCi prompt.\r\n\r\nThe question marks `?` seem to be encoding related and not relevant.\r\n\r\nThis panic not seem to occur with GHC the compiler. The rest of the error messages seem otherwise identical.\r\n\r\n{{{\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set -fdefer-type-errors\r\nPrelude> :l bug.hs\r\n[1 of 1] Compiling PolyvariadicFunctions ( bug.hs, interpreted )\r\n\r\nbug.hs:17:7: warning: [-Wdeferred-type-errors]\r\n ? No instance for (PolyList t0 [Integer])\r\n arising from a use of ‘polyList’\r\n ? In the expression: polyList 1 2 3 4 5\r\n In an equation for ‘plh’: plh = polyList 1 2 3 4 5\r\n |\r\n17 | plh = polyList 1 2 3 4 5\r\n | ^^^^^^^^^^^^^^^^^^\r\n\r\nbug.hs:17:16: warning: [-Wdeferred-type-errors]\r\n ? No instance for (Num ([t0] -> [t0])) arising from the literal ‘1’\r\n (maybe you haven't applied a function to enough arguments?)\r\n ? In the first argument of ‘polyList’, namely ‘1’\r\n In the expression: polyList 1 2 3 4 5\r\n In an equation for ‘plh’: plh = polyList 1 2 3 4 5\r\n |\r\n17 | plh = polyList 1 2 3 4 5\r\n | ^\r\n\r\nbug.hs:17:18: warning: [-Wdeferred-type-errors]\r\n ? Ambiguous type variable ‘t0’ arising from the literal ‘2’\r\n prevents the constraint ‘(Num t0)’ from being solved.\r\n Probable fix: use a type annotation to specify what ‘t0’ should be.\r\n These potential instances exist:\r\n instance Num Integer -- Defined in ‘GHC.Num’\r\n instance Num Double -- Defined in ‘GHC.Float’\r\n instance Num Float -- Defined in ‘GHC.Float’\r\n ...plus two others\r\n (use -fprint-potential-instances to see them all)\r\n ? In the second argument of ‘polyList’, namely ‘2’\r\n In the expression: polyList 1 2 3 4 5\r\n In an equation for ‘plh’: plh = polyList 1 2 3 4 5\r\n |\r\n17 | plh = polyList 1 2 3 4 5\r\n | ^\r\nghc.exe: panic! (the 'impossible' happened)\r\n (GHC version 8.4.3 for x86_64-unknown-mingw32):\r\n getIdFromTrivialExpr\r\n case $dNum_a1Be of wild_00 { }\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler\\utils\\Outputable.hs:1150:37 in ghc:Outputable\r\n pprPanic, called at compiler\\\\coreSyn\\\\CoreUtils.hs:883:18 in ghc:CoreUtils\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n>\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15326Add option to disable error message expression context (the 'In the expressio...2022-10-19T15:13:07ZdramforeverAdd option to disable error message expression context (the 'In the expression' things)A typical error looks like this:
```
bug.hs:17:7: warning: [-Wdeferred-type-errors]
? No instance for (PolyList t0 [Integer])
arising from a use of ‘polyList’
? In the expression: polyList 1 2 3 4 5
In an equation ...A typical error looks like this:
```
bug.hs:17:7: warning: [-Wdeferred-type-errors]
? No instance for (PolyList t0 [Integer])
arising from a use of ‘polyList’
? In the expression: polyList 1 2 3 4 5
In an equation for ‘plh’: plh = polyList 1 2 3 4 5
|
17 | plh = polyList 1 2 3 4 5
| ^^^^^^^^^^^^^^^^^^
```
Note the two lines starting with `In`. They waste two lines of error message space and now provides near zero utility since:
1. There's a caret view right below that context.
1. There are editor integrations that show squiggles right in the editor.
Now we have an option `-f[no-]diagnostics-show-caret` that disables the caret. It would be great to have one that disables those code context lines too.
This would make code errors shorter and easier to scroll through and read. And in editor integration, this would make the, say, error message popup less of a 'wall of text'.
As for naming. I'm thinking about `-f[no-]diagnostics-show-context`, which may be confused with constraint contexts, and `-f[no-]diagnostics-show-code-context`, which is a bit too long. I don't really know what those context lines are properly called, so maybe someone can come up with a more precise one.nadinenadinehttps://gitlab.haskell.org/ghc/ghc/-/issues/15327Optimize remainders by powers of two for Integer and Natural2023-04-01T17:25:28ZBodigrimOptimize remainders by powers of two for Integer and NaturalIt appears that GHC does not optimise `even (n :: Integer)` to a bitwise check, as it does for `Int` and `Word` (#14437). Here is a benchmark:
```hs
import Data.Time.Clock
evenRem :: Integer -> Bool
evenRem n = fromIntegral n `rem` 2 =...It appears that GHC does not optimise `even (n :: Integer)` to a bitwise check, as it does for `Int` and `Word` (#14437). Here is a benchmark:
```hs
import Data.Time.Clock
evenRem :: Integer -> Bool
evenRem n = fromIntegral n `rem` 2 == (0 :: Word)
lim :: Integer
lim = 100000000
main :: IO ()
main = do
t0 <- getCurrentTime
print $ maximum $ filter even [1..lim]
t1 <- getCurrentTime
putStrLn "even"
print $ diffUTCTime t1 t0
t0 <- getCurrentTime
print $ maximum $ filter evenRem [1..lim]
t1 <- getCurrentTime
putStrLn "evenRem"
print $ diffUTCTime t1 t0
```
```
$ ghc -O2 Even.hs
[1 of 1] Compiling Main ( Even.hs, Even.o )
Linking Even ...
$ ./Even
100000000
even
6.367393s
100000000
evenRem
4.35664s
```
The reason is that `even (n :: Integer)` results in `remInteger` call in CMM, which remains unoptimized.
One possible solution is to add a special case of divisor 2 to `GHC.Integer.Type.remInteger`. Or perhaps even something like
```hs
remInteger n (S# d#)
| isPowerOfTwo (I# d#) = fromIntegral (fromIntegral n `rem` I# d#)
isPowerOfTwo :: Int -> Bool
isPowerOfTwo d = d /= 0 && d .&. (complement d + 1) == d
```
Since `remInteger` is not inlined during Core pipeline, such implementation of `even` will pattern-match in runtime, which is a bit suboptimal. On my machine it benchmarks halfway between `even` and `evenRem` above.
Alternative approach is to add new rules to `PrelRules.builtinIntegerRules` to avoid any possible runtime slowdown. Is is appropriate?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Optimize remainders by powers of two for Integer and Natural","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"It appears that GHC does not optimise `even (n :: Integer)` to a bitwise check, as it does for `Int` and `Word` (#14437). Here is a benchmark:\r\n\r\n{{{#!hs\r\nimport Data.Time.Clock\r\n\r\nevenRem :: Integer -> Bool\r\nevenRem n = fromIntegral n `rem` 2 == (0 :: Word)\r\n\r\nlim :: Integer\r\nlim = 100000000\r\n\r\nmain :: IO ()\r\nmain = do\r\n t0 <- getCurrentTime\r\n print $ maximum $ filter even [1..lim]\r\n t1 <- getCurrentTime\r\n putStrLn \"even\"\r\n print $ diffUTCTime t1 t0\r\n\r\n t0 <- getCurrentTime\r\n print $ maximum $ filter evenRem [1..lim]\r\n t1 <- getCurrentTime\r\n putStrLn \"evenRem\"\r\n print $ diffUTCTime t1 t0\r\n}}}\r\n\r\n{{{\r\n$ ghc -O2 Even.hs\r\n[1 of 1] Compiling Main ( Even.hs, Even.o )\r\nLinking Even ...\r\n$ ./Even\r\n100000000\r\neven\r\n6.367393s\r\n100000000\r\nevenRem\r\n4.35664s\r\n}}}\r\n\r\nThe reason is that `even (n :: Integer)` results in `remInteger` call in CMM, which remains unoptimized.\r\n\r\nOne possible solution is to add a special case of divisor 2 to `GHC.Integer.Type.remInteger`. Or perhaps even something like\r\n\r\n{{{#!hs\r\nremInteger n (S# d#)\r\n | isPowerOfTwo (I# d#) = fromIntegral (fromIntegral n `rem` I# d#)\r\n\r\nisPowerOfTwo :: Int -> Bool\r\nisPowerOfTwo d = d /= 0 && d .&. (complement d + 1) == d\r\n}}}\r\n\r\nSince `remInteger` is not inlined during Core pipeline, such implementation of `even` will pattern-match in runtime, which is a bit suboptimal. On my machine it benchmarks halfway between `even` and `evenRem` above.\r\n\r\nAlternative approach is to add new rules to `PrelRules.builtinIntegerRules` to avoid any possible runtime slowdown. Is is appropriate?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15329Cannot parse `type (*)` in fixity declaration2019-07-07T18:13:08ZRichard Eisenbergrae@richarde.devCannot parse `type (*)` in fixity declarationVanessa McHale posts:
The parser seems to be broken. Attempting to build [basement](http://hackage.haskell.org/package/basement) yields:
```
Basement/Nat.hs:15:46: error: parse error on input ‘*’ | 15 | , type (<=), type (<=?), type (+...Vanessa McHale posts:
The parser seems to be broken. Attempting to build [basement](http://hackage.haskell.org/package/basement) yields:
```
Basement/Nat.hs:15:46: error: parse error on input ‘*’ | 15 | , type (<=), type (<=?), type (+), type (*), type (^), type (-) | ^
```
This is actually in 8.6.0, but there is no version option for this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cannot parse `type (*)` in fixity declaration","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Vanessa McHale posts:\r\n\r\nThe parser seems to be broken. Attempting to build [http://hackage.haskell.org/package/basement basement] yields:\r\n\r\n{{{\r\nBasement/Nat.hs:15:46: error: parse error on input ‘*’ | 15 | , type (<=), type (<=?), type (+), type (*), type (^), type (-) | ^\r\n}}}\r\n\r\nThis is actually in 8.6.0, but there is no version option for this.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15330Error message prints invisible kind arguments in a visible matter2019-07-07T18:13:08ZRyan ScottError message prints invisible kind arguments in a visible matterConsider the following program:
```hs
{-# LANGUAGE RankNTypes #-} ...Consider the following program:
```hs
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TypeInType #-}
module Bug where
import Data.Kind
import Data.Proxy
data T :: forall a. a -> Type
f1 :: Proxy (T True)
f1 = "foo"
f2 :: forall (t :: forall a. a -> Type).
Proxy (t True)
f2 = "foo"
```
This program doesn't typecheck (for good reason). The error messages, however, are a bit iffy:
```
$ /opt/ghc/8.4.3/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:11:6: error:
• Couldn't match expected type ‘Proxy (T 'True)’
with actual type ‘[Char]’
• In the expression: "foo"
In an equation for ‘f1’: f1 = "foo"
|
11 | f1 = "foo"
| ^^^^^
Bug.hs:15:6: error:
• Couldn't match expected type ‘Proxy (t Bool 'True)’
with actual type ‘[Char]’
• In the expression: "foo"
In an equation for ‘f2’: f2 = "foo"
• Relevant bindings include
f2 :: Proxy (t Bool 'True) (bound at Bug.hs:15:1)
|
15 | f2 = "foo"
| ^^^^^
```
Note that in the error message for `f1`, the type `T 'True` is printed correctly—the invisible `Bool` argument is omitted. However, in the error message for `f2`, this is not the case, as the type `t Bool 'True` is printed. That `Bool` is an invisible argument as well, and should not be printed without the use of, say, `-fprint-explicit-kinds`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Error message prints invisible kind arguments in a visible matter","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE RankNTypes #-} \r\n{-# LANGUAGE TypeInType #-} \r\nmodule Bug where \r\n \r\nimport Data.Kind \r\nimport Data.Proxy \r\n \r\ndata T :: forall a. a -> Type \r\n \r\nf1 :: Proxy (T True)\r\nf1 = \"foo\"\r\n\r\nf2 :: forall (t :: forall a. a -> Type).\r\n Proxy (t True)\r\nf2 = \"foo\"\r\n}}}\r\n\r\nThis program doesn't typecheck (for good reason). The error messages, however, are a bit iffy:\r\n\r\n{{{\r\n$ /opt/ghc/8.4.3/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:11:6: error:\r\n • Couldn't match expected type ‘Proxy (T 'True)’\r\n with actual type ‘[Char]’\r\n • In the expression: \"foo\"\r\n In an equation for ‘f1’: f1 = \"foo\"\r\n |\r\n11 | f1 = \"foo\"\r\n | ^^^^^\r\n\r\nBug.hs:15:6: error:\r\n • Couldn't match expected type ‘Proxy (t Bool 'True)’\r\n with actual type ‘[Char]’\r\n • In the expression: \"foo\"\r\n In an equation for ‘f2’: f2 = \"foo\"\r\n • Relevant bindings include\r\n f2 :: Proxy (t Bool 'True) (bound at Bug.hs:15:1)\r\n |\r\n15 | f2 = \"foo\"\r\n | ^^^^^\r\n}}}\r\n\r\nNote that in the error message for `f1`, the type `T 'True` is printed correctly—the invisible `Bool` argument is omitted. However, in the error message for `f2`, this is not the case, as the type `t Bool 'True` is printed. That `Bool` is an invisible argument as well, and should not be printed without the use of, say, `-fprint-explicit-kinds`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15331-ddump-splices does not parenthesize visible type applications correctly2019-07-07T18:13:08ZRyan Scott-ddump-splices does not parenthesize visible type applications correctlySo many `-ddump-splices` bugs...
```hs
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeApplications #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug where
import Data.Proxy
$([d| f :: Proxy (Int -> Int)
f = Proxy @(Int -> Int...So many `-ddump-splices` bugs...
```hs
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeApplications #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug where
import Data.Proxy
$([d| f :: Proxy (Int -> Int)
f = Proxy @(Int -> Int)
|])
```
```
$ /opt/ghc/8.6.1/bin/ghci Bug.hs
GHCi, version 8.6.0.20180627: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:(8,3)-(10,6): Splicing declarations
[d| f_a1Dg :: Proxy (Int -> Int)
f_a1Dg = Proxy @(Int -> Int) |]
======>
f_a4tx :: Proxy (Int -> Int)
f_a4tx = Proxy @Int -> Int
```
Ack—`Proxy @Int -> Int` should actually be `Proxy @(Int -> Int)`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-ddump-splices does not parenthesize visible type applications correctly","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"So many `-ddump-splices` bugs...\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# LANGUAGE TypeApplications #-}\r\n{-# OPTIONS_GHC -ddump-splices #-}\r\nmodule Bug where\r\n\r\nimport Data.Proxy\r\n\r\n$([d| f :: Proxy (Int -> Int)\r\n f = Proxy @(Int -> Int)\r\n |])\r\n}}}\r\n\r\n{{{\r\n$ /opt/ghc/8.6.1/bin/ghci Bug.hs\r\nGHCi, version 8.6.0.20180627: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\nBug.hs:(8,3)-(10,6): Splicing declarations\r\n [d| f_a1Dg :: Proxy (Int -> Int)\r\n f_a1Dg = Proxy @(Int -> Int) |]\r\n ======>\r\n f_a4tx :: Proxy (Int -> Int)\r\n f_a4tx = Proxy @Int -> Int\r\n}}}\r\n\r\nAck—`Proxy @Int -> Int` should actually be `Proxy @(Int -> Int)`.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15332lintIdUnfolding could be simpler2019-07-07T18:13:07ZMatthew PickeringlintIdUnfolding could be simplerI think that `lintIdUnfolding` could use `maybeUnfoldingTemplate` rather than the complicated linting of `DFunUnfolding`. Seeing as `maybeUnfoldingTemplate` is the thing which is used when inlining, it makes sense to use that rather than...I think that `lintIdUnfolding` could use `maybeUnfoldingTemplate` rather than the complicated linting of `DFunUnfolding`. Seeing as `maybeUnfoldingTemplate` is the thing which is used when inlining, it makes sense to use that rather than some ad-hoc reconstruction.
See https://phabricator.haskell.org/D4919 for the patch
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"lintIdUnfolding could be simpler","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"I think that `lintIdUnfolding` could use `maybeUnfoldingTemplate` rather than the complicated linting of `DFunUnfolding`. Seeing as `maybeUnfoldingTemplate` is the thing which is used when inlining, it makes sense to use that rather than some ad-hoc reconstruction. \r\n\r\nSee https://phabricator.haskell.org/D4919 for the patch","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15333Nursery size adulterates cachegrind metrics in nofib2020-01-14T13:17:35ZSebastian GrafNursery size adulterates cachegrind metrics in nofibI'm currently investigating an alleged regression in my branch of the late lambda lift and hit a confusing data point. Note that I'm very much relying on cachegrinds counted instructions/memory accesses for my findings.
Check out the mo...I'm currently investigating an alleged regression in my branch of the late lambda lift and hit a confusing data point. Note that I'm very much relying on cachegrinds counted instructions/memory accesses for my findings.
Check out the most recent version of `nofib`, enter `shootout/binary-trees` and run the following script:
```sh
#! /bin/sh
sed -i 's/import Debug.Trace//g' Main.hs # Make the following line idempotent
echo "import Debug.Trace" | cat - Main.hs > Main.tmp && mv Main.tmp Main.hs # add the import for trace
# bt1: Vanilly
sed -i 's/trace "" \$ bit/bit/g' Main.hs # strip `trace $ ` prefixes in the call to `bit`
ghc -O2 -XBangPatterns Main.hs -o bt1
# bt2: Additional trace call
sed -i 's/bit/trace "" $ bit/g' Main.hs # prepend `trace $ ` to the call to `bit`
ghc -O2 -XBangPatterns Main.hs -o bt2
valgrind --tool=cachegrind ./bt1 12 2>&1 > /dev/null # without trace
valgrind --tool=cachegrind ./bt2 12 2>&1 > /dev/null # with trace
```
This will compile two versions of `binary-trees`, the original, unchanged version and one with an extra `trace "" $` call before the only call to the `bit` function. One would expect the version with the `trace` call (`bt2`) to allocate more than the version without (`bt1`). Indeed, the output of `+RTS -s` suggests that:
```
$ ./bt1 12 +RTS -s
...
43,107,560 bytes allocated in the heap
...
$ ./bt2 12 +RTS -s
...
43,116,888 bytes allocated in the heap
...
```
That's fine. A few benchmark runs by hand also suggested the tracing version is a little slower (probably due to IO).
Compare that to the output of the above cachegrind calls:
```
$ valgrind --tool=cachegrind ./bt1 12 > /dev/null
...
I refs: 118,697,583
...
D refs: 43,475,212
...
$ valgrind --tool=cachegrind ./bt2 12 > /dev/null
...
I refs: 116,340,710
...
D refs: 42,523,369
...
```
It's the other way round here! How's that possible?
Even if this isn't strictly a bug in GHC or NoFib, it's relevant nonetheless, as our benchmark infrastructure currently relies on instruction counts. I couldn't reproduce this by writing my own no-op `trace _ a = a; {-# NOINLINE trace #-}`, btw.
I checked this on GHC 8.2.2, 8.4.3 and a semi-recent HEAD commit (bb539cfe335eeec7989332b859b1f3162c5e105a).Research neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/15334(forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x)2019-08-05T08:46:55ZRyan Scott(forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x)Consider the following code:
```hs
{-# LANGUAGE DeriveTraversable #-}
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE QuantifiedConstraints #-}
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE Undec...Consider the following code:
```hs
{-# LANGUAGE DeriveTraversable #-}
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE QuantifiedConstraints #-}
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE UndecidableInstances #-}
module Foo where
import Data.Kind
type family F a :: Type -> Type
newtype WrappedF a b = WrapF (F a b)
deriving instance Functor (F a) => Functor (WrappedF a)
deriving instance Foldable (F a) => Foldable (WrappedF a)
deriving instance Traversable (F a) => Traversable (WrappedF a)
data SomeF b = forall a. MkSomeF (WrappedF a b)
deriving instance (forall a. Functor (WrappedF a)) => Functor SomeF
deriving instance (forall a. Foldable (WrappedF a)) => Foldable SomeF
deriving instance ( forall a. Functor (WrappedF a)
, forall a. Foldable (WrappedF a)
, forall a. Traversable (WrappedF a)
) => Traversable SomeF
```
This typechecks. However, the last `Traversable SomeF` is a bit unfortunate in that is uses three separate `forall a.`s. I attempted to factor this out, like so:
```hs
deriving instance (forall a. ( Functor (WrappedF a)
, Foldable (WrappedF a)
, Traversable (WrappedF a)
)) => Traversable SomeF
```
But then the file no longer typechecked!
```
$ /opt/ghc/8.6.1/bin/ghc Foo.hs
[1 of 1] Compiling Foo ( Foo.hs, Foo.o )
Foo.hs:21:1: error:
• Could not deduce (Functor (F a))
arising from the superclasses of an instance declaration
from the context: forall a.
(Functor (WrappedF a), Foldable (WrappedF a),
Traversable (WrappedF a))
bound by the instance declaration at Foo.hs:(21,1)-(24,52)
• In the instance declaration for ‘Traversable SomeF’
|
21 | deriving instance (forall a. ( Functor (WrappedF a)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
Foo.hs:21:1: error:
• Could not deduce (Foldable (F a))
arising from the superclasses of an instance declaration
from the context: forall a.
(Functor (WrappedF a), Foldable (WrappedF a),
Traversable (WrappedF a))
bound by the instance declaration at Foo.hs:(21,1)-(24,52)
• In the instance declaration for ‘Traversable SomeF’
|
21 | deriving instance (forall a. ( Functor (WrappedF a)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
Foo.hs:21:1: error:
• Could not deduce (Traversable (F a1))
arising from a use of ‘traverse’
from the context: forall a.
(Functor (WrappedF a), Foldable (WrappedF a),
Traversable (WrappedF a))
bound by the instance declaration at Foo.hs:(21,1)-(24,52)
or from: Applicative f
bound by the type signature for:
traverse :: forall (f :: * -> *) a b.
Applicative f =>
(a -> f b) -> SomeF a -> f (SomeF b)
at Foo.hs:(21,1)-(24,52)
• In the second argument of ‘fmap’, namely ‘(traverse f a1)’
In the expression: fmap (\ b1 -> MkSomeF b1) (traverse f a1)
In an equation for ‘traverse’:
traverse f (MkSomeF a1) = fmap (\ b1 -> MkSomeF b1) (traverse f a1)
When typechecking the code for ‘traverse’
in a derived instance for ‘Traversable SomeF’:
To see the code I am typechecking, use -ddump-deriv
|
21 | deriving instance (forall a. ( Functor (WrappedF a)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
```
Richard suspects that this is a bug in the way quantified constraints expands superclasses, so I decided to post it here.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"(forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x)","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["QuantifiedConstraints"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following code:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DeriveTraversable #-}\r\n{-# LANGUAGE ExistentialQuantification #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE QuantifiedConstraints #-}\r\n{-# LANGUAGE StandaloneDeriving #-}\r\n{-# LANGUAGE UndecidableInstances #-}\r\nmodule Foo where\r\n\r\nimport Data.Kind\r\n\r\ntype family F a :: Type -> Type\r\nnewtype WrappedF a b = WrapF (F a b)\r\nderiving instance Functor (F a) => Functor (WrappedF a)\r\nderiving instance Foldable (F a) => Foldable (WrappedF a)\r\nderiving instance Traversable (F a) => Traversable (WrappedF a)\r\n\r\ndata SomeF b = forall a. MkSomeF (WrappedF a b)\r\n\r\nderiving instance (forall a. Functor (WrappedF a)) => Functor SomeF\r\nderiving instance (forall a. Foldable (WrappedF a)) => Foldable SomeF\r\nderiving instance ( forall a. Functor (WrappedF a)\r\n , forall a. Foldable (WrappedF a)\r\n , forall a. Traversable (WrappedF a)\r\n ) => Traversable SomeF\r\n}}}\r\n\r\nThis typechecks. However, the last `Traversable SomeF` is a bit unfortunate in that is uses three separate `forall a.`s. I attempted to factor this out, like so:\r\n\r\n{{{#!hs\r\nderiving instance (forall a. ( Functor (WrappedF a)\r\n , Foldable (WrappedF a)\r\n , Traversable (WrappedF a)\r\n )) => Traversable SomeF\r\n}}}\r\n\r\nBut then the file no longer typechecked!\r\n\r\n{{{\r\n$ /opt/ghc/8.6.1/bin/ghc Foo.hs\r\n[1 of 1] Compiling Foo ( Foo.hs, Foo.o )\r\n\r\nFoo.hs:21:1: error:\r\n • Could not deduce (Functor (F a))\r\n arising from the superclasses of an instance declaration\r\n from the context: forall a.\r\n (Functor (WrappedF a), Foldable (WrappedF a),\r\n Traversable (WrappedF a))\r\n bound by the instance declaration at Foo.hs:(21,1)-(24,52)\r\n • In the instance declaration for ‘Traversable SomeF’\r\n |\r\n21 | deriving instance (forall a. ( Functor (WrappedF a)\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...\r\n\r\nFoo.hs:21:1: error:\r\n • Could not deduce (Foldable (F a))\r\n arising from the superclasses of an instance declaration\r\n from the context: forall a.\r\n (Functor (WrappedF a), Foldable (WrappedF a),\r\n Traversable (WrappedF a))\r\n bound by the instance declaration at Foo.hs:(21,1)-(24,52)\r\n • In the instance declaration for ‘Traversable SomeF’\r\n |\r\n21 | deriving instance (forall a. ( Functor (WrappedF a)\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...\r\n\r\nFoo.hs:21:1: error:\r\n • Could not deduce (Traversable (F a1))\r\n arising from a use of ‘traverse’\r\n from the context: forall a.\r\n (Functor (WrappedF a), Foldable (WrappedF a),\r\n Traversable (WrappedF a))\r\n bound by the instance declaration at Foo.hs:(21,1)-(24,52)\r\n or from: Applicative f\r\n bound by the type signature for:\r\n traverse :: forall (f :: * -> *) a b.\r\n Applicative f =>\r\n (a -> f b) -> SomeF a -> f (SomeF b)\r\n at Foo.hs:(21,1)-(24,52)\r\n • In the second argument of ‘fmap’, namely ‘(traverse f a1)’\r\n In the expression: fmap (\\ b1 -> MkSomeF b1) (traverse f a1)\r\n In an equation for ‘traverse’:\r\n traverse f (MkSomeF a1) = fmap (\\ b1 -> MkSomeF b1) (traverse f a1)\r\n When typechecking the code for ‘traverse’\r\n in a derived instance for ‘Traversable SomeF’:\r\n To see the code I am typechecking, use -ddump-deriv\r\n |\r\n21 | deriving instance (forall a. ( Functor (WrappedF a)\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...\r\n}}}\r\n\r\nRichard suspects that this is a bug in the way quantified constraints expands superclasses, so I decided to post it here.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15335Export `findImportUsage` from `rename/RnNames.hs` module2019-07-07T18:13:07ZDmitrii KovanikovExport `findImportUsage` from `rename/RnNames.hs` moduleI'm writing source plugin for analyzing imports in Haskell source code. I don't want to duplicate code already written in GHC. So I would like to have `findImportUsage` function and `ImportDeclUsage` type aliases exported from `RnNames` ...I'm writing source plugin for analyzing imports in Haskell source code. I don't want to duplicate code already written in GHC. So I would like to have `findImportUsage` function and `ImportDeclUsage` type aliases exported from `RnNames` module:
- [GitHub: ghc/compilier/rename/RnNames](https://github.com/ghc/ghc/blob/ccd8ce405db89142932daea3fdace8814b110798/compiler/rename/RnNames.hs#L1314-L1318)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Export `findImportUsage` from `rename/RnNames.hs` module","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["imports,refactoring,export"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I'm writing source plugin for analyzing imports in Haskell source code. I don't want to duplicate code already written in GHC. So I would like to have `findImportUsage` function and `ImportDeclUsage` type aliases exported from `RnNames` module:\r\n\r\n* [https://github.com/ghc/ghc/blob/ccd8ce405db89142932daea3fdace8814b110798/compiler/rename/RnNames.hs#L1314-L1318 GitHub: ghc/compilier/rename/RnNames]","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15336./System/IO.hs accidentally overridden when running ghci2019-08-10T10:51:32Zluqui./System/IO.hs accidentally overridden when running ghciRunning ghci fails if there is a System/IO.hs module present in the current directory. Doesn't seem like desirable behavior.
```
% mkdir System
% touch System/IO.hs
% ghci
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
<...Running ghci fails if there is a System/IO.hs module present in the current directory. Doesn't seem like desirable behavior.
```
% mkdir System
% touch System/IO.hs
% ghci
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
<interactive>:1:19: error:
Not in scope: ‘System.IO.hSetBuffering’
No module named ‘System.IO’ is imported.
<interactive>:1:43: error:
Not in scope: ‘System.IO.stdin’
No module named ‘System.IO’ is imported.
<interactive>:1:60: error:
Not in scope: data constructor ‘System.IO.NoBuffering’
No module named ‘System.IO’ is imported.
<interactive>:1:99: error:
Not in scope: ‘System.IO.hSetBuffering’
No module named ‘System.IO’ is imported.
<interactive>:1:123: error:
Not in scope: ‘System.IO.stdout’
No module named ‘System.IO’ is imported.
<interactive>:1:140: error:
Not in scope: data constructor ‘System.IO.NoBuffering’
No module named ‘System.IO’ is imported.
<interactive>:1:179: error:
Not in scope: ‘System.IO.hSetBuffering’
No module named ‘System.IO’ is imported.
<interactive>:1:203: error:
Not in scope: ‘System.IO.stderr’
No module named ‘System.IO’ is imported.
<interactive>:1:220: error:
Not in scope: data constructor ‘System.IO.NoBuffering’
No module named ‘System.IO’ is imported.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"./System/IO.hs accidentally overridden when running ghci","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Running ghci fails if there is a System/IO.hs module present in the current directory. Doesn't seem like desirable behavior.\r\n\r\n{{{\r\n% mkdir System\r\n% touch System/IO.hs\r\n% ghci\r\nGHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help\r\n\r\n<interactive>:1:19: error:\r\n Not in scope: ‘System.IO.hSetBuffering’\r\n No module named ‘System.IO’ is imported.\r\n\r\n<interactive>:1:43: error:\r\n Not in scope: ‘System.IO.stdin’\r\n No module named ‘System.IO’ is imported.\r\n\r\n<interactive>:1:60: error:\r\n Not in scope: data constructor ‘System.IO.NoBuffering’\r\n No module named ‘System.IO’ is imported.\r\n\r\n<interactive>:1:99: error:\r\n Not in scope: ‘System.IO.hSetBuffering’\r\n No module named ‘System.IO’ is imported.\r\n\r\n<interactive>:1:123: error:\r\n Not in scope: ‘System.IO.stdout’\r\n No module named ‘System.IO’ is imported.\r\n\r\n<interactive>:1:140: error:\r\n Not in scope: data constructor ‘System.IO.NoBuffering’\r\n No module named ‘System.IO’ is imported.\r\n\r\n<interactive>:1:179: error:\r\n Not in scope: ‘System.IO.hSetBuffering’\r\n No module named ‘System.IO’ is imported.\r\n\r\n<interactive>:1:203: error:\r\n Not in scope: ‘System.IO.stderr’\r\n No module named ‘System.IO’ is imported.\r\n\r\n<interactive>:1:220: error:\r\n Not in scope: data constructor ‘System.IO.NoBuffering’\r\n No module named ‘System.IO’ is imported.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15338ghc-pkg misbehaves after possible miscompilation on m68k and sh42022-07-04T20:58:26Zglaubitzghc-pkg misbehaves after possible miscompilation on m68k and sh4We have observed in Debian that GHC can produce a erratically behaving version of ghc-pkg which causes issues when piping it's output to another program.
Example:
```
make_setup_recipe
Running ghc --make Setup.hs -o debian/hlibrary.set...We have observed in Debian that GHC can produce a erratically behaving version of ghc-pkg which causes issues when piping it's output to another program.
Example:
```
make_setup_recipe
Running ghc --make Setup.hs -o debian/hlibrary.setup
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking debian/hlibrary.setup ...
. /usr/share/haskell-devscripts/Dh_Haskell.sh && \
configure_recipe
Running debian/hlibrary.setup configure --ghc -v2 --package-db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro --haddockdir=/usr/lib/ghc-doc/haddock/base-prelude-/ --datasubdir=base-prelude --htmldir=/usr/share/doc/libghc-base-prelude-doc/html/ --enable-library-profiling
Configuring base-prelude-1.2.1...
Warning: cannot determine version of /usr/bin/ghc-pkg :
""
hlibrary.setup: The program 'ghc-pkg' is required but the version of
/usr/bin/ghc-pkg could not be determined.
```
(Full log: https://buildd.debian.org/status/fetch.php?pkg=haskell-base-prelude&arch=m68k&ver=1.2.1-1&stamp=1530588494&raw=0)
Examining the behavior of the affected ghc-pkg binary on m68k shows what's going on:
```
root@pacman:~# uname -a
Linux pacman 4.16.0-2-m68k #1 Debian 4.16.16-1 (2018-06-19) m68k GNU/Linux
root@pacman:~# ghc-pkg --version
GHC package manager version 8.2.2
root@pacman:~# ghc-pkg --version | cat
root@pacman:~#
```
Comparing that to an x86_64 machine shows that piping to cat should actually output something:
```
glaubitz@epyc:~$ uname -a
Linux epyc 4.16.0-2-amd64 #1 SMP Debian 4.16.12-1 (2018-05-27) x86_64 GNU/Linux
glaubitz@epyc:~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.2.2
glaubitz@epyc:~$ ghc --version | cat
The Glorious Glasgow Haskell Compilation System, version 8.2.2
glaubitz@epyc:~$
```
Further investigation shows that the problem is partially resolved when building GHC with reduced optimization:
```
echo "SRC_HC_OPTS += -O0 -H64m" >> mk/build.mk
echo "GhcStage1HcOpts = -O" >> mk/build.mk
echo "GhcStage2HcOpts = -O0" >> mk/build.mk
echo "GhcLibHcOpts = -O" >> mk/build.mk
```
The above issue goes away, but ghc-pkg itself still shows some strange behavior:
```
make_setup_recipe
Running ghc --make Setup.hs -o debian/hlibrary.setup
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking debian/hlibrary.setup ...
. /usr/share/haskell-devscripts/Dh_Haskell.sh && \
configure_recipe
Running debian/hlibrary.setup configure --ghc -v2 --package-db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro --haddockdir=/usr/lib/ghc-doc/haddock/microlens-ghc-0.4.8.0/ --datasubdir=microlens-ghc --htmldir=/usr/share/doc/libghc-microlens-ghc-doc/html/ --enable-library-profiling
Configuring microlens-ghc-0.4.8.0...
hlibrary.setup: ghc-pkg dump failed: dieVerbatim: user error (hlibrary.setup:
'/usr/bin/ghc-pkg' exited with an error:
ghc-pkg: <stdout>: commitBuffer: invalid argument (invalid character)
)
```
(Full log: https://buildd.debian.org/status/fetch.php?pkg=haskell-microlens-ghc&arch=m68k&ver=0.4.8.0-2&stamp=1529960552&raw=0)
To reproduce the issue, GHC can be tested using QEMU which has pretty good support for the m68k target these days.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-pkg misbehaves after possible miscompilation on m68k and sh4","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"We have observed in Debian that GHC can produce a erratically behaving version of ghc-pkg which causes issues when piping it's output to another program.\r\n\r\nExample:\r\n\r\n{{{\r\nmake_setup_recipe\r\nRunning ghc --make Setup.hs -o debian/hlibrary.setup\r\n[1 of 1] Compiling Main ( Setup.hs, Setup.o )\r\nLinking debian/hlibrary.setup ...\r\n. /usr/share/haskell-devscripts/Dh_Haskell.sh && \\\r\nconfigure_recipe\r\nRunning debian/hlibrary.setup configure --ghc -v2 --package-db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option=-optl-Wl\\,-z\\,relro --haddockdir=/usr/lib/ghc-doc/haddock/base-prelude-/ --datasubdir=base-prelude --htmldir=/usr/share/doc/libghc-base-prelude-doc/html/ --enable-library-profiling\r\nConfiguring base-prelude-1.2.1...\r\nWarning: cannot determine version of /usr/bin/ghc-pkg :\r\n\"\"\r\nhlibrary.setup: The program 'ghc-pkg' is required but the version of\r\n/usr/bin/ghc-pkg could not be determined.\r\n}}}\r\n\r\n(Full log: https://buildd.debian.org/status/fetch.php?pkg=haskell-base-prelude&arch=m68k&ver=1.2.1-1&stamp=1530588494&raw=0)\r\n\r\nExamining the behavior of the affected ghc-pkg binary on m68k shows what's going on:\r\n\r\n{{{\r\nroot@pacman:~# uname -a\r\nLinux pacman 4.16.0-2-m68k #1 Debian 4.16.16-1 (2018-06-19) m68k GNU/Linux\r\nroot@pacman:~# ghc-pkg --version\r\nGHC package manager version 8.2.2\r\nroot@pacman:~# ghc-pkg --version | cat\r\nroot@pacman:~#\r\n}}}\r\n\r\nComparing that to an x86_64 machine shows that piping to cat should actually output something:\r\n\r\n{{{\r\nglaubitz@epyc:~$ uname -a\r\nLinux epyc 4.16.0-2-amd64 #1 SMP Debian 4.16.12-1 (2018-05-27) x86_64 GNU/Linux\r\nglaubitz@epyc:~$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.2.2\r\nglaubitz@epyc:~$ ghc --version | cat\r\nThe Glorious Glasgow Haskell Compilation System, version 8.2.2\r\nglaubitz@epyc:~$\r\n}}}\r\n\r\nFurther investigation shows that the problem is partially resolved when building GHC with reduced optimization:\r\n\r\n{{{\r\n echo \"SRC_HC_OPTS += -O0 -H64m\" >> mk/build.mk\r\n echo \"GhcStage1HcOpts = -O\" >> mk/build.mk\r\n echo \"GhcStage2HcOpts = -O0\" >> mk/build.mk\r\n echo \"GhcLibHcOpts = -O\" >> mk/build.mk\r\n}}}\r\n\r\nThe above issue goes away, but ghc-pkg itself still shows some strange behavior:\r\n\r\n{{{\r\nmake_setup_recipe\r\nRunning ghc --make Setup.hs -o debian/hlibrary.setup\r\n[1 of 1] Compiling Main ( Setup.hs, Setup.o )\r\nLinking debian/hlibrary.setup ...\r\n. /usr/share/haskell-devscripts/Dh_Haskell.sh && \\\r\nconfigure_recipe\r\nRunning debian/hlibrary.setup configure --ghc -v2 --package-db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option=-optl-Wl\\,-z\\,relro --haddockdir=/usr/lib/ghc-doc/haddock/microlens-ghc-0.4.8.0/ --datasubdir=microlens-ghc --htmldir=/usr/share/doc/libghc-microlens-ghc-doc/html/ --enable-library-profiling\r\nConfiguring microlens-ghc-0.4.8.0...\r\nhlibrary.setup: ghc-pkg dump failed: dieVerbatim: user error (hlibrary.setup:\r\n'/usr/bin/ghc-pkg' exited with an error:\r\nghc-pkg: <stdout>: commitBuffer: invalid argument (invalid character)\r\n)\r\n}}}\r\n\r\n(Full log: https://buildd.debian.org/status/fetch.php?pkg=haskell-microlens-ghc&arch=m68k&ver=0.4.8.0-2&stamp=1529960552&raw=0)\r\n\r\nTo reproduce the issue, GHC can be tested using QEMU which has pretty good support for the m68k target these days.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15339Add function equality instance for finite functions to base2019-07-07T18:13:06ZmadgenAdd function equality instance for finite functions to baseIf the input type is bounded and enumerable and the result type can be compared for equality, functions can be checked for equality. Basically this instance:
```hs
instance (Bounded a, Enum a, Eq b) => Eq (a -> b) where
f == g = all (...If the input type is bounded and enumerable and the result type can be compared for equality, functions can be checked for equality. Basically this instance:
```hs
instance (Bounded a, Enum a, Eq b) => Eq (a -> b) where
f == g = all (\x -> f x == g x) [ minBound..maxBound ]
```
I often work with functions with finite domains and find \[(a,b)\] awkward. I thought this is generic enough that it might belong to base.
I'd also submit a patch, but I couldn't quite figure out where it should live. GHC.Base doesn't have Enum and Bounded; Enum is not where -\> or Eq are declared; Eq is not declared anywhere; and Data.Function is only for combinators.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add function equality instance for finite functions to base","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["base,","equality,","function"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"If the input type is bounded and enumerable and the result type can be compared for equality, functions can be checked for equality. Basically this instance:\r\n\r\n{{{#!hs\r\ninstance (Bounded a, Enum a, Eq b) => Eq (a -> b) where\r\n f == g = all (\\x -> f x == g x) [ minBound..maxBound ]\r\n}}}\r\n\r\nI often work with functions with finite domains and find [(a,b)] awkward. I thought this is generic enough that it might belong to base.\r\n\r\nI'd also submit a patch, but I couldn't quite figure out where it should live. GHC.Base doesn't have Enum and Bounded; Enum is not where -> or Eq are declared; Eq is not declared anywhere; and Data.Function is only for combinators.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15341:info prints kinds in closed type family equations without enabling -fprint-e...2019-07-07T18:13:05ZRyan Scott:info prints kinds in closed type family equations without enabling -fprint-explicit-kindsLoad this file into GHCi:
```hs
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
type family Foo (a :: k) :: k where
Foo a = a
```
And run `:info` on `Foo`:
```
$ /opt/ghc/8.4.3/bin/ghci Bug.hs
GHCi, versio...Load this file into GHCi:
```hs
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
type family Foo (a :: k) :: k where
Foo a = a
```
And run `:info` on `Foo`:
```
$ /opt/ghc/8.4.3/bin/ghci Bug.hs
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/ryanglscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Ok, one module loaded.
λ> :i Foo
type family Foo (a :: k) :: k
where Foo k a = a
-- Defined at Bug.hs:5:1
```
Note that when printing the equation for `Foo`, the kind `k` is treated as though it were the first visible argument to `Foo`, even though `-fprint-explicit-kinds` is not enabled. This is because `ppr_tc_args` in `IfaceType` does not take `-fprint-explicit-kinds` into account.
Patch incoming (pending a `./validate`).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":":info prints kinds in closed type family equations without enabling -fprint-explicit-kinds","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["TypeFamilies"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Load this file into GHCi:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule Bug where\r\n\r\ntype family Foo (a :: k) :: k where\r\n Foo a = a\r\n}}}\r\n\r\nAnd run `:info` on `Foo`:\r\n\r\n{{{\r\n$ /opt/ghc/8.4.3/bin/ghci Bug.hs\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/ryanglscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\nOk, one module loaded.\r\nλ> :i Foo\r\ntype family Foo (a :: k) :: k\r\n where Foo k a = a\r\n -- Defined at Bug.hs:5:1\r\n}}}\r\n\r\nNote that when printing the equation for `Foo`, the kind `k` is treated as though it were the first visible argument to `Foo`, even though `-fprint-explicit-kinds` is not enabled. This is because `ppr_tc_args` in `IfaceType` does not take `-fprint-explicit-kinds` into account.\r\n\r\nPatch incoming (pending a `./validate`).","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15342Mark -XAutoDeriveTypeable as deprecated2019-07-07T18:13:05ZKrzysztof GogolewskiMark -XAutoDeriveTypeable as deprecatedThe language extension `-XAutoDeriveTypeable` is not needed since #9858.
It was earlier marked as redundant in GHC documentation. I propose that GHC gives a clear deprecation message.
<details><summary>Trac metadata</summary>
| Trac f...The language extension `-XAutoDeriveTypeable` is not needed since #9858.
It was earlier marked as redundant in GHC documentation. I propose that GHC gives a clear deprecation message.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Mark -XAutoDeriveTypeable as deprecated","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The language extension `-XAutoDeriveTypeable` is not needed since #9858.\r\n\r\nIt was earlier marked as redundant in GHC documentation. I propose that GHC gives a clear deprecation message.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15343Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind)2019-07-07T18:13:05ZRyan ScottImplicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind)The following program panics on GHC 8.6 and later:
```hs
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeApplications #-}
{-# LANGUAGE TypeFam...The following program panics on GHC 8.6 and later:
```hs
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeApplications #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE TypeOperators #-}
module Bug where
import Data.Kind
import Data.Type.Equality
data family Sing :: forall k. k -> Type
data SomeSing :: Type -> Type where
SomeSing :: Sing (a :: k) -> SomeSing k
class SingKind k where
type Demote k :: Type
fromSing :: Sing (a :: k) -> Demote k
toSing :: Demote k -> SomeSing k
data instance Sing (z :: a :~~: b) where
SHRefl :: Sing HRefl
instance SingKind (a :~~: b) where
type Demote (a :~~: b) = a :~~: b
fromSing SHRefl = HRefl
toSing HRefl = SomeSing SHRefl
data TyFun :: Type -> Type -> Type
type a ~> b = TyFun a b -> Type
infixr 0 ~>
type family Apply (f :: k1 ~> k2) (x :: k1) :: k2
(~>:~~:) :: forall (j :: Type) (k :: Type) (a :: j) (b :: k)
(p :: forall (z :: Type) (y :: z). (a :~~: y) ~> Type)
(r :: a :~~: b).
Sing r
-> Apply p HRefl
-> Apply p r
(~>:~~:) SHRefl pHRefl = pHRefl
type family Why (a :: j) (e :: a :~~: (y :: z)) :: Type where
Why a (_ :: a :~~: y) = y :~~: a
data WhySym (a :: j) :: forall (y :: z). (a :~~: y) ~> Type
-- data WhySym (a :: j) :: forall z (y :: z). (a :~~: y) ~> Type
-- The version above does NOT panic
type instance Apply (WhySym a) e = Why a e
hsym :: forall (j :: Type) (k :: Type) (a :: j) (b :: k).
a :~~: b -> b :~~: a
hsym eq = case toSing eq of
SomeSing (singEq :: Sing r) ->
(~>:~~:) @j @k @a @b @(WhySym a) @r singEq HRefl
```
```
$ /opt/ghc/8.6.1/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.0.20180627 for x86_64-unknown-linux):
coercionKind
Nth:3
(Inst {co_a1jI} (Coh <k_a1js[sk:1]>_N (Nth:0 (Sym {co_a1jI}))))
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable
pprPanic, called at compiler/types/Coercion.hs:1887:9 in ghc:Coercion
```
As noted in the comments, replacing `WhySym` with a version that explicitly quantifies `z` avoids the panic.
This is a regression from GHC 8.4.3, in which the program simply errored:
```
$ /opt/ghc/8.4.3/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:56:38: error:
• Expected kind ‘forall z (y :: z). (a1 :~~: y) ~> *’,
but ‘WhySym a’ has kind ‘forall (y :: z0).
TyFun (a1 :~~: y) * -> *’
• In the type ‘(WhySym a)’
In the expression: (~>:~~:) @j @k @a @b @(WhySym a) @r singEq HRefl
In a case alternative:
SomeSing (singEq :: Sing r)
-> (~>:~~:) @j @k @a @b @(WhySym a) @r singEq HRefl
• Relevant bindings include
singEq :: Sing a2 (bound at Bug.hs:55:23)
eq :: a1 :~~: b (bound at Bug.hs:54:6)
hsym :: (a1 :~~: b) -> b :~~: a1 (bound at Bug.hs:54:1)
|
56 | (~>:~~:) @j @k @a @b @(WhySym a) @r singEq HRefl
| ^^^^^^^^
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind)","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program panics on GHC 8.6 and later:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE AllowAmbiguousTypes #-}\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE RankNTypes #-}\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n{-# LANGUAGE TypeApplications #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeInType #-}\r\n{-# LANGUAGE TypeOperators #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\nimport Data.Type.Equality\r\n\r\ndata family Sing :: forall k. k -> Type\r\ndata SomeSing :: Type -> Type where\r\n SomeSing :: Sing (a :: k) -> SomeSing k\r\n\r\nclass SingKind k where\r\n type Demote k :: Type\r\n fromSing :: Sing (a :: k) -> Demote k\r\n toSing :: Demote k -> SomeSing k\r\n\r\ndata instance Sing (z :: a :~~: b) where\r\n SHRefl :: Sing HRefl\r\n\r\ninstance SingKind (a :~~: b) where\r\n type Demote (a :~~: b) = a :~~: b\r\n fromSing SHRefl = HRefl\r\n toSing HRefl = SomeSing SHRefl\r\n\r\ndata TyFun :: Type -> Type -> Type\r\ntype a ~> b = TyFun a b -> Type\r\ninfixr 0 ~>\r\ntype family Apply (f :: k1 ~> k2) (x :: k1) :: k2\r\n\r\n(~>:~~:) :: forall (j :: Type) (k :: Type) (a :: j) (b :: k)\r\n (p :: forall (z :: Type) (y :: z). (a :~~: y) ~> Type)\r\n (r :: a :~~: b).\r\n Sing r\r\n -> Apply p HRefl\r\n -> Apply p r\r\n(~>:~~:) SHRefl pHRefl = pHRefl\r\n\r\ntype family Why (a :: j) (e :: a :~~: (y :: z)) :: Type where\r\n Why a (_ :: a :~~: y) = y :~~: a\r\n\r\ndata WhySym (a :: j) :: forall (y :: z). (a :~~: y) ~> Type\r\n-- data WhySym (a :: j) :: forall z (y :: z). (a :~~: y) ~> Type\r\n-- The version above does NOT panic\r\ntype instance Apply (WhySym a) e = Why a e\r\n\r\nhsym :: forall (j :: Type) (k :: Type) (a :: j) (b :: k).\r\n a :~~: b -> b :~~: a\r\nhsym eq = case toSing eq of\r\n SomeSing (singEq :: Sing r) ->\r\n (~>:~~:) @j @k @a @b @(WhySym a) @r singEq HRefl\r\n}}}\r\n\r\n{{{\r\n$ /opt/ghc/8.6.1/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.6.0.20180627 for x86_64-unknown-linux):\r\n coercionKind\r\n Nth:3\r\n (Inst {co_a1jI} (Coh <k_a1js[sk:1]>_N (Nth:0 (Sym {co_a1jI}))))\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable\r\n pprPanic, called at compiler/types/Coercion.hs:1887:9 in ghc:Coercion\r\n}}}\r\n\r\nAs noted in the comments, replacing `WhySym` with a version that explicitly quantifies `z` avoids the panic.\r\n\r\nThis is a regression from GHC 8.4.3, in which the program simply errored:\r\n\r\n{{{\r\n$ /opt/ghc/8.4.3/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:56:38: error:\r\n • Expected kind ‘forall z (y :: z). (a1 :~~: y) ~> *’,\r\n but ‘WhySym a’ has kind ‘forall (y :: z0).\r\n TyFun (a1 :~~: y) * -> *’\r\n • In the type ‘(WhySym a)’\r\n In the expression: (~>:~~:) @j @k @a @b @(WhySym a) @r singEq HRefl\r\n In a case alternative:\r\n SomeSing (singEq :: Sing r)\r\n -> (~>:~~:) @j @k @a @b @(WhySym a) @r singEq HRefl\r\n • Relevant bindings include\r\n singEq :: Sing a2 (bound at Bug.hs:55:23)\r\n eq :: a1 :~~: b (bound at Bug.hs:54:6)\r\n hsym :: (a1 :~~: b) -> b :~~: a1 (bound at Bug.hs:54:1)\r\n |\r\n56 | (~>:~~:) @j @k @a @b @(WhySym a) @r singEq HRefl\r\n | ^^^^^^^^\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15344ApplicativeDo seems to prevent the fail method from being used2020-04-08T07:45:03ZkccqzyApplicativeDo seems to prevent the fail method from being usedI am not sure if this is intended, but I came across this issue when debugging a runtime exception. It seems like an incomplete pattern match in a do-block with ApplicativeDo enabled will not use the fail method.
If I have a module like...I am not sure if this is intended, but I came across this issue when debugging a runtime exception. It seems like an incomplete pattern match in a do-block with ApplicativeDo enabled will not use the fail method.
If I have a module like this
```hs
{-# LANGUAGE ApplicativeDo #-}
{-# OPTIONS_ghc -ddump-simpl #-}
module M where
f :: Maybe (Maybe Int) -> Maybe Int -> Maybe Int
f mgs mid = do
_ <- mid
(Just moi) <- mgs
pure (moi + 42)
main :: IO ()
main = print (f (Just Nothing) (Just 2))
```
This will result in a runtime exception:
```
Just *** Exception: repro.hs:(6,13)-(9,17): Non-exhaustive patterns in lambda
```
But if I remove the ApplicativeDo extension, this code works as normal, producing Nothing as the output.
On a theoretical level I understand why this is happening, but I still find it quite unexpected, especially since the documentation at https://downloads.haskell.org/\~ghc/latest/docs/html/users_guide/glasgow_exts.html\#things-to-watch-out-for claims that
> Your code should just work as before when ApplicativeDo is enabled, provided you use conventional Applicative instances.
If this is not a defect in GHC itself, I'd say it is a defect in documentation in not pointing out this gotcha.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ApplicativeDo seems to prevent the fail method from being used","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I am not sure if this is intended, but I came across this issue when debugging a runtime exception. It seems like an incomplete pattern match in a do-block with ApplicativeDo enabled will not use the fail method.\r\n\r\nIf I have a module like this\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ApplicativeDo #-}\r\n{-# OPTIONS_ghc -ddump-simpl #-}\r\nmodule M where\r\n\r\nf :: Maybe (Maybe Int) -> Maybe Int -> Maybe Int\r\nf mgs mid = do\r\n _ <- mid\r\n (Just moi) <- mgs\r\n pure (moi + 42)\r\n\r\nmain :: IO ()\r\nmain = print (f (Just Nothing) (Just 2))\r\n\r\n}}}\r\n\r\nThis will result in a runtime exception:\r\n\r\n{{{\r\nJust *** Exception: repro.hs:(6,13)-(9,17): Non-exhaustive patterns in lambda\r\n}}}\r\n\r\nBut if I remove the ApplicativeDo extension, this code works as normal, producing Nothing as the output.\r\n\r\nOn a theoretical level I understand why this is happening, but I still find it quite unexpected, especially since the documentation at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#things-to-watch-out-for claims that \r\n\r\n> Your code should just work as before when ApplicativeDo is enabled, provided you use conventional Applicative instances.\r\n\r\nIf this is not a defect in GHC itself, I'd say it is a defect in documentation in not pointing out this gotcha.","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/15346Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed...2019-07-07T18:13:04ZRyan ScottCore Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expressionThe following program typechecks on GHC 8.6.1-alpha1:
```hs
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE EmptyCase #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE ScopedT...The following program typechecks on GHC 8.6.1-alpha1:
```hs
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE EmptyCase #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE TypeOperators #-}
module SGenerics where
import Data.Kind
import Data.Type.Equality
import Data.Void
-----
-- singletons machinery
-----
data family Sing :: forall k. k -> Type
data instance Sing :: () -> Type where
STuple0 :: Sing '()
type Refuted a = a -> Void
data Decision a = Proved a | Disproved (Refuted a)
-----
-- A stripped down version of GHC.Generics
-----
data U1 = MkU1
data instance Sing (z :: U1) where
SMkU1 :: Sing MkU1
-----
class Generic (a :: Type) where
type Rep a :: Type
from :: a -> Rep a
to :: Rep a -> a
class PGeneric (a :: Type) where
type PFrom (x :: a) :: Rep a
type PTo (x :: Rep a) :: a
class SGeneric k where
sFrom :: forall (a :: k). Sing a -> Sing (PFrom a)
sTo :: forall (a :: Rep k). Sing a -> Sing (PTo a :: k)
sTof :: forall (a :: k). Sing a -> PTo (PFrom a) :~: a
sFot :: forall (a :: Rep k). Sing a -> PFrom (PTo a :: k) :~: a
-----
instance Generic () where
type Rep () = U1
from () = MkU1
to MkU1 = ()
instance PGeneric () where
type PFrom '() = MkU1
type PTo 'MkU1 = '()
instance SGeneric () where
sFrom STuple0 = SMkU1
sTo SMkU1 = STuple0
sTof STuple0 = Refl
sFot SMkU1 = Refl
-----
class SDecide k where
-- | Compute a proof or disproof of equality, given two singletons.
(%~) :: forall (a :: k) (b :: k). Sing a -> Sing b -> Decision (a :~: b)
default (%~) :: forall (a :: k) (b :: k). (SGeneric k, SDecide (Rep k))
=> Sing a -> Sing b -> Decision (a :~: b)
s1 %~ s2 = case sFrom s1 %~ sFrom s2 of
Proved (Refl :: PFrom a :~: PFrom b) ->
let r :: PTo (PFrom a) :~: PTo (PFrom b)
r = Refl
sTof1 :: PTo (PFrom a) :~: a
sTof1 = sTof s1
sTof2 :: PTo (PFrom b) :~: b
sTof2 = sTof s2
in Proved (sym sTof1 `trans` r `trans` sTof2)
Disproved contra -> Disproved (\Refl -> contra Refl)
instance SDecide U1 where
SMkU1 %~ SMkU1 = Proved Refl
instance SDecide ()
```
However, it throws a Core Lint error with `-dcore-lint`. The full error is absolutely massive, so I'll attach it separately. Here is the top-level bit:
```
*** Core Lint errors : in result of Simplifier ***
<no location info>: warning:
In the expression: <elided>
From-type of Cast differs from type of enclosed expression
From-type: U1
Type of enclosed expr: Rep ()
Actual enclosed expr: PFrom a_a1Fm
Coercion used in cast: Sym (D:R:Rep()[0])
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program typechecks on GHC 8.6.1-alpha1:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE AllowAmbiguousTypes #-}\r\n{-# LANGUAGE DefaultSignatures #-}\r\n{-# LANGUAGE EmptyCase #-}\r\n{-# LANGUAGE FlexibleContexts #-}\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeInType #-}\r\n{-# LANGUAGE TypeOperators #-}\r\nmodule SGenerics where\r\n\r\nimport Data.Kind\r\nimport Data.Type.Equality\r\nimport Data.Void\r\n\r\n-----\r\n-- singletons machinery\r\n-----\r\n\r\ndata family Sing :: forall k. k -> Type\r\n\r\ndata instance Sing :: () -> Type where\r\n STuple0 :: Sing '()\r\n\r\ntype Refuted a = a -> Void\r\ndata Decision a = Proved a | Disproved (Refuted a)\r\n\r\n-----\r\n-- A stripped down version of GHC.Generics\r\n-----\r\n\r\ndata U1 = MkU1\r\ndata instance Sing (z :: U1) where\r\n SMkU1 :: Sing MkU1\r\n\r\n-----\r\n\r\nclass Generic (a :: Type) where\r\n type Rep a :: Type\r\n from :: a -> Rep a\r\n to :: Rep a -> a\r\n\r\nclass PGeneric (a :: Type) where\r\n type PFrom (x :: a) :: Rep a\r\n type PTo (x :: Rep a) :: a\r\n\r\nclass SGeneric k where\r\n sFrom :: forall (a :: k). Sing a -> Sing (PFrom a)\r\n sTo :: forall (a :: Rep k). Sing a -> Sing (PTo a :: k)\r\n sTof :: forall (a :: k). Sing a -> PTo (PFrom a) :~: a\r\n sFot :: forall (a :: Rep k). Sing a -> PFrom (PTo a :: k) :~: a\r\n\r\n-----\r\n\r\ninstance Generic () where\r\n type Rep () = U1\r\n from () = MkU1\r\n to MkU1 = ()\r\n\r\ninstance PGeneric () where\r\n type PFrom '() = MkU1\r\n type PTo 'MkU1 = '()\r\n\r\ninstance SGeneric () where\r\n sFrom STuple0 = SMkU1\r\n sTo SMkU1 = STuple0\r\n sTof STuple0 = Refl\r\n sFot SMkU1 = Refl\r\n\r\n-----\r\n\r\nclass SDecide k where\r\n -- | Compute a proof or disproof of equality, given two singletons.\r\n (%~) :: forall (a :: k) (b :: k). Sing a -> Sing b -> Decision (a :~: b)\r\n default (%~) :: forall (a :: k) (b :: k). (SGeneric k, SDecide (Rep k))\r\n => Sing a -> Sing b -> Decision (a :~: b)\r\n s1 %~ s2 = case sFrom s1 %~ sFrom s2 of\r\n Proved (Refl :: PFrom a :~: PFrom b) ->\r\n let r :: PTo (PFrom a) :~: PTo (PFrom b)\r\n r = Refl\r\n\r\n sTof1 :: PTo (PFrom a) :~: a\r\n sTof1 = sTof s1\r\n\r\n sTof2 :: PTo (PFrom b) :~: b\r\n sTof2 = sTof s2\r\n in Proved (sym sTof1 `trans` r `trans` sTof2)\r\n Disproved contra -> Disproved (\\Refl -> contra Refl)\r\n\r\ninstance SDecide U1 where\r\n SMkU1 %~ SMkU1 = Proved Refl\r\n\r\ninstance SDecide ()\r\n}}}\r\n\r\nHowever, it throws a Core Lint error with `-dcore-lint`. The full error is absolutely massive, so I'll attach it separately. Here is the top-level bit:\r\n\r\n{{{\r\n*** Core Lint errors : in result of Simplifier ***\r\n<no location info>: warning:\r\n In the expression: <elided>\r\n From-type of Cast differs from type of enclosed expression\r\n From-type: U1\r\n Type of enclosed expr: Rep ()\r\n Actual enclosed expr: PFrom a_a1Fm\r\n Coercion used in cast: Sym (D:R:Rep()[0])\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15348Enable two-step allocator on FreeBSD2019-07-07T18:13:03ZBen GamariEnable two-step allocator on FreeBSDCurrently the two-step allocator is disabled on FreeBSD as the `MEM_NORESERVE` macro is undefined. It seems that FreeBSD provided this macro until 2014, when it was [removed](https://reviews.freebsd.org/D848) as it wasn't implemented in ...Currently the two-step allocator is disabled on FreeBSD as the `MEM_NORESERVE` macro is undefined. It seems that FreeBSD provided this macro until 2014, when it was [removed](https://reviews.freebsd.org/D848) as it wasn't implemented in the kernel. Regardless, Viktor Dukhovni reports empirical evidence on `ghc-devs` that just plain `mmap` does what we want.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Enable two-step allocator on FreeBSD","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently the two-step allocator is disabled on FreeBSD as the `MEM_NORESERVE` macro is undefined. It seems that FreeBSD provided this macro until 2014, when it was [[https://reviews.freebsd.org/D848|removed]] as it wasn't implemented in the kernel. Regardless, Viktor Dukhovni reports empirical evidence on `ghc-devs` that just plain `mmap` does what we want.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15349fixST is a bit wrong2019-07-07T18:13:03ZDavid FeuerfixST is a bit wrongLazy blackholing lets some `ST` calculations complete that shouldn't.
```hs
import Control.Monad.ST.Strict
import Control.Monad.Fix
import Data.STRef
foo :: ST s Int
foo = do
ref <- newSTRef True
mfix $ \res -> do
x <- readSTRe...Lazy blackholing lets some `ST` calculations complete that shouldn't.
```hs
import Control.Monad.ST.Strict
import Control.Monad.Fix
import Data.STRef
foo :: ST s Int
foo = do
ref <- newSTRef True
mfix $ \res -> do
x <- readSTRef ref
if x
then do
writeSTRef ref False
return $! (res + 5)
else return 10
main = print $ runST foo
```
When this is compiled with `-O -feager-blackholing`, it produces a `<<loop>>` exception as expected. When it's compiled with `-O0` or with `-fno-eager-blackholing`, it prints `15`.
Should we reimplement `fixST` to do something like what `fixIO` does? Or should we consider this sometimes-lost bottom tolerable?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"fixST is a bit wrong","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"Lazy blackholing lets some `ST` calculations complete that shouldn't.\r\n\r\n{{{#!hs\r\nimport Control.Monad.ST.Strict\r\nimport Control.Monad.Fix\r\nimport Data.STRef\r\n\r\nfoo :: ST s Int\r\nfoo = do\r\n ref <- newSTRef True\r\n mfix $ \\res -> do\r\n x <- readSTRef ref\r\n if x\r\n then do\r\n writeSTRef ref False\r\n return $! (res + 5)\r\n else return 10\r\n\r\nmain = print $ runST foo\r\n}}}\r\n\r\nWhen this is compiled with `-O -feager-blackholing`, it produces a `<<loop>>` exception as expected. When it's compiled with `-O0` or with `-fno-eager-blackholing`, it prints `15`.\r\n\r\nShould we reimplement `fixST` to do something like what `fixIO` does? Or should we consider this sometimes-lost bottom tolerable?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1David FeuerDavid Feuerhttps://gitlab.haskell.org/ghc/ghc/-/issues/15350gcdExtInteger violates assertion2020-09-30T20:15:39ZBodigrimgcdExtInteger violates assertion```haskell
{-# LANGUAGE UnboxedTuples #-}
import GHC.Integer.GMP.Internals
main = let (# _, s #) = gcdExtInteger 2 (2^65 + 1) in print s
```
fails with
```haskell
Assertion failed: (sn <= mp_size_abs(xn)), function integer_gmp_gcdext,...```haskell
{-# LANGUAGE UnboxedTuples #-}
import GHC.Integer.GMP.Internals
main = let (# _, s #) = gcdExtInteger 2 (2^65 + 1) in print s
```
fails with
```haskell
Assertion failed: (sn <= mp_size_abs(xn)), function integer_gmp_gcdext, file libraries/integer-gmp/cbits/wrappers.c, line 316.
Abort trap: 6
```
It happens because `s = -2^64` and does not fit one-limbed `BigNat`. The implementation of `gcdExtInteger x y` (https://github.com/ghc/ghc/blob/master/libraries/integer-gmp/src/GHC/Integer/Type.hs\#L1392) allocates for `s` a buffer, equal to size of `x` (one limb in our case), but according to GMP manual (https://gmplib.org/manual/Number-Theoretic-Functions.html\#index-mpz_005fgcdext) it should be equal to size of `y` (two limbs in our case).
Hopefully, the diff is simple enough for a PR on GitHub (https://github.com/ghc/ghc/pull/163). Otherwise I'll be happy to prepare a patch for Phabricator.
```diff
- s@(MBN# s#) <- newBigNat# (absI# xn#)
+ s@(MBN# s#) <- newBigNat# (absI# yn#)
```
---
Reopening, because
```haskell
{-# LANGUAGE UnboxedTuples #-}
import GHC.Integer.GMP.Internals
main = let (# _, s #) = gcdExtInteger (- (2^63 - 1) * 2^63) 0 in print s
```
fails in GHC 8.6.1 with
```haskell
Assertion failed: (0 <= gn && gn <= gn0), function integer_gmp_gcdext, file libraries/integer-gmp/cbits/wrappers.c, line 309.
Abort trap: 6
```
I have not yet understood what is going on.8.6.1BodigrimBodigrimhttps://gitlab.haskell.org/ghc/ghc/-/issues/15352False kind errors with implicitly bound kinds in GHC 8.62019-07-07T18:13:02ZaaronvargoFalse kind errors with implicitly bound kinds in GHC 8.6This could be related to #15343.
The following code fails to compile with GHC 8.6.0.20180627, but does compile with 8.4:
```hs
{-# LANGUAGE TypeInType #-} -- or PolyKinds
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies...This could be related to #15343.
The following code fails to compile with GHC 8.6.0.20180627, but does compile with 8.4:
```hs
{-# LANGUAGE TypeInType #-} -- or PolyKinds
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
import Data.Kind
class C (x :: Type) (y :: k) where
type F y
```
```
• Expected a type, but ‘k’ has kind ‘k’
• In the kind ‘k’
|
7 | class C (x :: Type) (y :: k) where
| ^
```
Yet all of the following slightly different examples still do compile:
```hs
-- remove `x`
class C0 (y :: k) where type F0 y
-- remove `F`
class C1 (x :: Type) (y :: k)
-- remove the kind annotation from `x`
class C2 x (y :: k) where type F2 y
-- switch the order of `x` and `y`
class C3 (y :: k) (x :: Type) where type F3 y
-- make `k` an explicit parameter, with or without a kind annotation
class C4 k (x :: Type) (y :: k) where type F4 y
class C5 (k :: Type) (x :: Type) (y :: k) where type F5 y
-- add a new parameter *with no kind annotation*
class C6 z (x :: Type) (y :: k) where type F6 y
```
Here's also my original example which failed to compile:
```hs
type Hom k = k -> k -> Type
type family Ob (p :: Hom k) :: k -> Constraint
class ( obP ~ Ob p
, opP ~ Dom p
, obQ ~ Ob q
, opQ ~ Dom q
, p ~ Dom f
, q ~ Cod f
) => Functor' (obP :: i -> Constraint)
(opP :: Hom i)
(p :: Hom i)
(obQ :: j -> Constraint)
(opQ :: Hom j)
(q :: Hom j)
(f :: i -> j) where
type Dom f :: Hom i
type Cod f :: Hom j
```
```
• Expected a type, but ‘j’ has kind ‘k’
• In the first argument of ‘Hom’, namely ‘j’
In the kind ‘Hom j’
|
34 | type Cod f :: Hom j
| ^
```
The only way I can find to make this one compile is to make `i` and `j` explicit parameters with explicit kinds:
```hs
class ( obP ~ Ob p
, opP ~ Dom p
, obQ ~ Ob q
, opQ ~ Dom q
, p ~ Dom f
, q ~ Cod f
) => Functor' (i :: Type)
(j :: Type)
(obP :: i -> Constraint)
(opP :: Hom i)
(p :: Hom i)
(obQ :: j -> Constraint)
(opQ :: Hom j)
(q :: Hom j)
(f :: i -> j) where
type Dom f :: Hom i
type Cod f :: Hom j
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"False kind errors with implicitly bound kinds in GHC 8.6","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This could be related to #15343.\r\n\r\nThe following code fails to compile with GHC 8.6.0.20180627, but does compile with 8.4:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TypeInType #-} -- or PolyKinds\r\n{-# LANGUAGE MultiParamTypeClasses #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\nimport Data.Kind\r\n\r\nclass C (x :: Type) (y :: k) where\r\n type F y\r\n}}}\r\n\r\n{{{\r\n • Expected a type, but ‘k’ has kind ‘k’\r\n • In the kind ‘k’\r\n |\r\n7 | class C (x :: Type) (y :: k) where\r\n | ^\r\n}}}\r\n\r\nYet all of the following slightly different examples still do compile:\r\n\r\n{{{#!hs\r\n-- remove `x`\r\nclass C0 (y :: k) where type F0 y\r\n\r\n-- remove `F`\r\nclass C1 (x :: Type) (y :: k)\r\n\r\n-- remove the kind annotation from `x`\r\nclass C2 x (y :: k) where type F2 y\r\n\r\n-- switch the order of `x` and `y`\r\nclass C3 (y :: k) (x :: Type) where type F3 y\r\n\r\n-- make `k` an explicit parameter, with or without a kind annotation\r\nclass C4 k (x :: Type) (y :: k) where type F4 y\r\nclass C5 (k :: Type) (x :: Type) (y :: k) where type F5 y\r\n\r\n-- add a new parameter *with no kind annotation*\r\nclass C6 z (x :: Type) (y :: k) where type F6 y\r\n}}}\r\n\r\nHere's also my original example which failed to compile:\r\n\r\n{{{#!hs\r\ntype Hom k = k -> k -> Type\r\n\r\ntype family Ob (p :: Hom k) :: k -> Constraint\r\n\r\nclass ( obP ~ Ob p\r\n , opP ~ Dom p\r\n , obQ ~ Ob q\r\n , opQ ~ Dom q\r\n , p ~ Dom f\r\n , q ~ Cod f\r\n ) => Functor' (obP :: i -> Constraint)\r\n (opP :: Hom i)\r\n (p :: Hom i)\r\n (obQ :: j -> Constraint)\r\n (opQ :: Hom j)\r\n (q :: Hom j)\r\n (f :: i -> j) where\r\n type Dom f :: Hom i\r\n type Cod f :: Hom j\r\n}}}\r\n\r\n{{{\r\n • Expected a type, but ‘j’ has kind ‘k’\r\n • In the first argument of ‘Hom’, namely ‘j’\r\n In the kind ‘Hom j’\r\n |\r\n34 | type Cod f :: Hom j\r\n | ^\r\n}}}\r\n\r\nThe only way I can find to make this one compile is to make `i` and `j` explicit parameters with explicit kinds:\r\n\r\n{{{#!hs\r\nclass ( obP ~ Ob p\r\n , opP ~ Dom p\r\n , obQ ~ Ob q\r\n , opQ ~ Dom q\r\n , p ~ Dom f\r\n , q ~ Cod f\r\n ) => Functor' (i :: Type)\r\n (j :: Type)\r\n (obP :: i -> Constraint)\r\n (opP :: Hom i)\r\n (p :: Hom i)\r\n (obQ :: j -> Constraint)\r\n (opQ :: Hom j)\r\n (q :: Hom j)\r\n (f :: i -> j) where\r\n type Dom f :: Hom i\r\n type Cod f :: Hom j\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15353Another Cabal submodule bump2019-07-07T18:13:02ZquasicomputationalAnother Cabal submodule bumphttps://github.com/snowleopard/hadrian/issues/634 uncovered a bug in Cabal that bit Hadrian quite severely. The Hadrian people are working around it, but it'd be nice if they could rip out the hacks in CI and stop having to remember to p...https://github.com/snowleopard/hadrian/issues/634 uncovered a bug in Cabal that bit Hadrian quite severely. The Hadrian people are working around it, but it'd be nice if they could rip out the hacks in CI and stop having to remember to point the Cabal submodule to a fixed commit. The bug has been fixed in Cabal HEAD now, so the only thing needed is a submodule bump in GHC master, please.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Another Cabal submodule bump","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"https://github.com/snowleopard/hadrian/issues/634 uncovered a bug in Cabal that bit Hadrian quite severely. The Hadrian people are working around it, but it'd be nice if they could rip out the hacks in CI and stop having to remember to point the Cabal submodule to a fixed commit. The bug has been fixed in Cabal HEAD now, so the only thing needed is a submodule bump in GHC master, please.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15354QuantifiedConstraints not fully described in manual2020-09-25T20:00:01ZRichard Eisenbergrae@richarde.devQuantifiedConstraints not fully described in manualAs pointed out in [ticket:15351\#comment:156470](https://gitlab.haskell.org//ghc/ghc/issues/15351#note_156470), the section in the manual on `-XQuantifiedConstraints` says that an `=>` is essential in a quantified constraint. However, th...As pointed out in [ticket:15351\#comment:156470](https://gitlab.haskell.org//ghc/ghc/issues/15351#note_156470), the section in the manual on `-XQuantifiedConstraints` says that an `=>` is essential in a quantified constraint. However, the following is accepted:
```hs
class C a
foo :: (forall x. C x) => ()
foo = ()
```
Note that there is no `=>` in the quantified constraint. We need to update the manual accordingly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"QuantifiedConstraints not fully described in manual","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"As pointed out in comment:4:ticket:15351, the section in the manual on `-XQuantifiedConstraints` says that an `=>` is essential in a quantified constraint. However, the following is accepted:\r\n\r\n{{{#!hs\r\nclass C a\r\n\r\nfoo :: (forall x. C x) => ()\r\nfoo = ()\r\n}}}\r\n\r\nNote that there is no `=>` in the quantified constraint. We need to update the manual accordingly.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15355Functional dependencies can get GHC to print "UnkSkol"2019-07-07T18:13:02ZRichard Eisenbergrae@richarde.devFunctional dependencies can get GHC to print "UnkSkol"When I say
```hs
class C a b | a -> b where
foo :: a -> b
instance C Int Bool where
foo = (>0)
blah :: C Int Double => Int -> _a
blah = foo
```
I get
```
• Couldn't match type ‘Double’ with ‘Bool’
arising from a func...When I say
```hs
class C a b | a -> b where
foo :: a -> b
instance C Int Bool where
foo = (>0)
blah :: C Int Double => Int -> _a
blah = foo
```
I get
```
• Couldn't match type ‘Double’ with ‘Bool’
arising from a functional dependency between constraints:
‘C Int Bool’ arising from a use of ‘foo’ at Scratch.hs:51:8-10
‘C Int Double’ arising from UnkSkol at Scratch.hs:51:1-10
• In the expression: foo
In an equation for ‘blah’: blah = foo
```
There are actually two problems:
1. If we replace `_a` with `Double`, GHC accepts the program. I'm not sure it should. But that's a larger problem than...
1. ... when it prints the error, it says `UnkSkol`. It probably shouldn't.
This ticket is about the second problem, because the first one require more fundep love than is usually on offer around here.
Erroring here is reasonable enoug
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Functional dependencies can get GHC to print \"UnkSkol\"","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["FunctionalDependencies"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I say\r\n\r\n{{{#!hs\r\nclass C a b | a -> b where\r\n foo :: a -> b\r\n\r\ninstance C Int Bool where\r\n foo = (>0)\r\n\r\nblah :: C Int Double => Int -> _a\r\nblah = foo\r\n}}}\r\n\r\nI get\r\n\r\n{{{\r\n • Couldn't match type ‘Double’ with ‘Bool’\r\n arising from a functional dependency between constraints:\r\n ‘C Int Bool’ arising from a use of ‘foo’ at Scratch.hs:51:8-10\r\n ‘C Int Double’ arising from UnkSkol at Scratch.hs:51:1-10\r\n • In the expression: foo\r\n In an equation for ‘blah’: blah = foo\r\n}}}\r\n\r\nThere are actually two problems:\r\n\r\n1. If we replace `_a` with `Double`, GHC accepts the program. I'm not sure it should. But that's a larger problem than...\r\n\r\n2. ... when it prints the error, it says `UnkSkol`. It probably shouldn't.\r\n\r\nThis ticket is about the second problem, because the first one require more fundep love than is usually on offer around here.\r\n\r\nErroring here is reasonable enoug","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15357Make nofib suitable for runtime measurements.2019-07-07T18:13:01ZAndreas KlebingerMake nofib suitable for runtime measurements.Currently many benchmarks in a default nofib run have runtimes so low that they become meaningless.
This comes with a bunch of issues:
- It takes up build/runtime while not actually improving the accuracy of runtime measurements.
- It ...Currently many benchmarks in a default nofib run have runtimes so low that they become meaningless.
This comes with a bunch of issues:
- It takes up build/runtime while not actually improving the accuracy of runtime measurements.
- It skews results as the jump from 1ms to 2ms registers as a 200% change.
- It can hide regression which fall outside of the measured granularity.
- Higher number of runs per benchmark spend far too much time on the few slower benchmarks.
At the extreme end there are 9 benchmarks with runtimes shorter than the granularity of 1ms.
For some benchmarks changing this might be as easy as increasing the number of runs/iterations.
For others changing problem sizes is not as easy since they process more complex input data.
Below are the runtimes of a recent default nofib run.
<table><tr><th> benchmark </th>
<td> Time (ms) </td></tr>
<tr><td> ansi </td>
<td> 0 </td></tr>
<tr><td> awards </td>
<td> 0 </td></tr>
<tr><td> banner </td>
<td> 0 </td></tr>
<tr><td> calendar </td>
<td> 0 </td></tr>
<tr><td> expert </td>
<td> 0 </td></tr>
<tr><td> gen_regexps </td>
<td> 0 </td></tr>
<tr><td> grep </td>
<td> 0 </td></tr>
<tr><td> pretty </td>
<td> 0 </td></tr>
<tr><td> scc </td>
<td> 0 </td></tr>
<tr><td> cse </td>
<td> 1 </td></tr>
<tr><td> eliza </td>
<td> 1 </td></tr>
<tr><td> lift </td>
<td> 1 </td></tr>
<tr><td> mkhprog </td>
<td> 1 </td></tr>
<tr><td> prolog </td>
<td> 1 </td></tr>
<tr><td> sorting </td>
<td> 1 </td></tr>
<tr><td> veritas </td>
<td> 1 </td></tr>
<tr><td> knights </td>
<td> 2 </td></tr>
<tr><td> minimax </td>
<td> 2 </td></tr>
<tr><td> x2n1 </td>
<td> 2 </td></tr>
<tr><td> mandel2 </td>
<td> 3 </td></tr>
<tr><td> parstof </td>
<td> 3 </td></tr>
<tr><td> fluid </td>
<td> 4 </td></tr>
<tr><td> pic </td>
<td> 4 </td></tr>
<tr><td> boyer2 </td>
<td> 5 </td></tr>
<tr><td> bspt </td>
<td> 5 </td></tr>
<tr><td> cryptarithm2 </td>
<td> 5 </td></tr>
<tr><td> fish </td>
<td> 6 </td></tr>
<tr><td> gg </td>
<td> 6 </td></tr>
<tr><td> reptile </td>
<td> 6 </td></tr>
<tr><td> symalg </td>
<td> 6 </td></tr>
<tr><td> tak </td>
<td> 6 </td></tr>
<tr><td> VSD </td>
<td> 7 </td></tr>
<tr><td> rfib </td>
<td> 7 </td></tr>
<tr><td> queens </td>
<td> 9 </td></tr>
<tr><td> rewrite </td>
<td> 9 </td></tr>
<tr><td> sched </td>
<td> 11 </td></tr>
<tr><td> fem </td>
<td> 12 </td></tr>
<tr><td> fibheaps </td>
<td> 13 </td></tr>
<tr><td> parser </td>
<td> 14 </td></tr>
<tr><td> rsa </td>
<td> 14 </td></tr>
<tr><td> genfft </td>
<td> 15 </td></tr>
<tr><td> clausify </td>
<td> 17 </td></tr>
<tr><td> gamteb </td>
<td> 17 </td></tr>
<tr><td> fft </td>
<td> 18 </td></tr>
<tr><td> boyer </td>
<td> 20 </td></tr>
<tr><td> gcd </td>
<td> 20 </td></tr>
<tr><td> sphere </td>
<td> 21 </td></tr>
<tr><td> fft2 </td>
<td> 23 </td></tr>
<tr><td> infer </td>
<td> 25 </td></tr>
<tr><td> maillist </td>
<td> 25 </td></tr>
<tr><td> mandel </td>
<td> 27 </td></tr>
<tr><td> nucleic2 </td>
<td> 30 </td></tr>
<tr><td> primes </td>
<td> 34 </td></tr>
<tr><td> cichelli </td>
<td> 35 </td></tr>
<tr><td> ida </td>
<td> 39 </td></tr>
<tr><td> listcompr </td>
<td> 41 </td></tr>
<tr><td> listcopy </td>
<td> 43 </td></tr>
<tr><td> multiplier </td>
<td> 43 </td></tr>
<tr><td> wang </td>
<td> 43 </td></tr>
<tr><td> hpg </td>
<td> 45 </td></tr>
<tr><td> anna </td>
<td> 46 </td></tr>
<tr><td> reverse-complem </td>
<td> 46 </td></tr>
<tr><td> integrate </td>
<td> 48 </td></tr>
<tr><td> primetest </td>
<td> 50 </td></tr>
<tr><td> paraffins </td>
<td> 54 </td></tr>
<tr><td> solid </td>
<td> 54 </td></tr>
<tr><td> puzzle </td>
<td> 55 </td></tr>
<tr><td> treejoin </td>
<td> 61 </td></tr>
<tr><td> compress2 </td>
<td> 64 </td></tr>
<tr><td> compress </td>
<td> 65 </td></tr>
<tr><td> event </td>
<td> 65 </td></tr>
<tr><td> bernouilli </td>
<td> 74 </td></tr>
<tr><td> comp_lab_zift </td>
<td> 78 </td></tr>
<tr><td> simple </td>
<td> 86 </td></tr>
<tr><td> wheel-sieve2 </td>
<td> 91 </td></tr>
<tr><td> life </td>
<td> 100 </td></tr>
<tr><td> exp3_8 </td>
<td> 102 </td></tr>
<tr><td> wave4main </td>
<td> 103 </td></tr>
<tr><td> typecheck </td>
<td> 106 </td></tr>
<tr><td> atom </td>
<td> 110 </td></tr>
<tr><td> fulsom </td>
<td> 112 </td></tr>
<tr><td> CS </td>
<td> 116 </td></tr>
<tr><td> para </td>
<td> 120 </td></tr>
<tr><td> kahan </td>
<td> 138 </td></tr>
<tr><td> transform </td>
<td> 145 </td></tr>
<tr><td> power </td>
<td> 150 </td></tr>
<tr><td> cacheprof </td>
<td> 151 </td></tr>
<tr><td> hidden </td>
<td> 160 </td></tr>
<tr><td> scs </td>
<td> 168 </td></tr>
<tr><td> lcss </td>
<td> 175 </td></tr>
<tr><td> wheel-sieve1 </td>
<td> 199 </td></tr>
<tr><td> VS </td>
<td> 204 </td></tr>
<tr><td> pidigits </td>
<td> 216 </td></tr>
<tr><td> FS </td>
<td> 222 </td></tr>
<tr><td> last-piece </td>
<td> 230 </td></tr>
<tr><td> fasta </td>
<td> 263 </td></tr>
<tr><td> cryptarithm1 </td>
<td> 264 </td></tr>
<tr><td> CSD </td>
<td> 272 </td></tr>
<tr><td> digits-of-e1 </td>
<td> 273 </td></tr>
<tr><td> binary-trees </td>
<td> 342 </td></tr>
<tr><td> digits-of-e2 </td>
<td> 381 </td></tr>
<tr><td> circsim </td>
<td> 418 </td></tr>
<tr><td> S </td>
<td> 451 </td></tr>
<tr><td> VSM </td>
<td> 497 </td></tr>
<tr><td> lambda </td>
<td> 617 </td></tr>
<tr><td> integer </td>
<td> 905 </td></tr>
<tr><td> n-body </td>
<td> 1043 </td></tr>
<tr><td> linear </td>
<td> 1070 </td></tr>
<tr><td> spectral-norm </td>
<td> 1132 </td></tr>
<tr><td> constraints </td>
<td> 1171 </td></tr>
<tr><td> exact-reals </td>
<td> 1289 </td></tr>
<tr><td> mate </td>
<td> 1955 </td></tr>
<tr><td> fannkuch-redux </td>
<td> 2185 </td></tr>
<tr><td> k-nucleotide </td>
<td> 2989 </td></tr></table>
8.8.1Andreas KlebingerAndreas Klebinger