GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:01:33Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/16091arith011 broken with integer-simple2019-07-07T18:01:33ZBen Gamariarith011 broken with integer-simpleThe `arith011` test fails unexpected when using `integer-simple`.
The test output is [quite long](https://gitlab.haskell.org/ghc/ghc/-/jobs/4892/raw) but here is the end:
```
#
negate 0 = 0
#
testReal
toRational 0 = 0 % 1
toRational 1 ...The `arith011` test fails unexpected when using `integer-simple`.
The test output is [quite long](https://gitlab.haskell.org/ghc/ghc/-/jobs/4892/raw) but here is the end:
```
#
negate 0 = 0
#
testReal
toRational 0 = 0 % 1
toRational 1 = 1 % 1
toRational 2 = 2 % 1
toRational 3 = 3 % 1
#
testIntegral
Stderr ( arith011 ):
arith011: divide by zero
*** unexpected failure for arith011(normal)
```
This is concerning since it suggests a behavioral difference between `integer-simple` and `integer-gmp`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"arith011 broken with integer-simple","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The `arith011` test fails unexpected when using `integer-simple`. \r\n\r\nThe test output is [[https://gitlab.haskell.org/ghc/ghc/-/jobs/4892/raw|quite long]] but here is the end:\r\n{{{\r\n#\r\nnegate 0 = 0\r\n#\r\ntestReal\r\ntoRational 0 = 0 % 1\r\ntoRational 1 = 1 % 1\r\ntoRational 2 = 2 % 1\r\ntoRational 3 = 3 % 1\r\n#\r\ntestIntegral\r\nStderr ( arith011 ):\r\narith011: divide by zero\r\n*** unexpected failure for arith011(normal)\r\n}}}\r\nThis is concerning since it suggests a behavioral difference between `integer-simple` and `integer-gmp`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16090Typeset Big-O complexities with TeX-style notation in libraries/base2019-07-07T18:01:33ZSven TennieTypeset Big-O complexities with TeX-style notation in libraries/baseIn the code review of #15003, \@hvr proposed to typeset Big-Os in TeX-style instead of using italic (1). This will lead to a more idiomatic typesetting.
See 2 for an example.
- \*Task:\*\* Replace all italic Big-Os in libraries/base wi...In the code review of #15003, \@hvr proposed to typeset Big-Os in TeX-style instead of using italic (1). This will lead to a more idiomatic typesetting.
See 2 for an example.
- \*Task:\*\* Replace all italic Big-Os in libraries/base with TeX-style notation.
1. - https://github.com/ghc/ghc/pull/239
1. - https://hackage.haskell.org/package/text-containers-0.1.0.0/docs/Data-TextSet-Unboxed.html\#v:size
Please Note: I'm creating this ticket in trac, because the GitLab migration doesn't seem to be finished, yet.
If this leads to any troubles: Please don't care about this ticket - When I see that this ticket isn't migrated, I'll simply re-create it in GitLab.Sven TennieSven Tenniehttps://gitlab.haskell.org/ghc/ghc/-/issues/16089seq is not cooperating with :sprint in GHCi as expected2023-08-29T00:32:45Zradrowseq is not cooperating with :sprint in GHCi as expectedI was playing around with strictness and performed following test:
```hs
Prelude> x = [True, False]
Prelude> :sprint x
x = _
Prelude> x `seq` True
True
Prelude> :sprint x
x = _
```
I completely don't understand why `x = _` at this mome...I was playing around with strictness and performed following test:
```hs
Prelude> x = [True, False]
Prelude> :sprint x
x = _
Prelude> x `seq` True
True
Prelude> :sprint x
x = _
```
I completely don't understand why `x = _` at this moment. `seq` must evaluate one level of `x` achieving `x = True : _` to ensure that it is not `undefined`, so why is this information lost?
I am testing it on GHCi version 8.6.3, but it is not reproducible on other versions (checked on 8.4.4, 8.2.2 and 7._._).
I have asked about it on SO, so if this behavior is intended I kindly ask for explaination here [https://stackoverflow.com/questions/53898220/sprint-and-seq-together-missing-evaluation](https://stackoverflow.com/questions/53898220/sprint-and-seq-together-missing-evaluation) to let others know.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"seq is not cooperating with :sprint in GHCi as expected","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":["seq","sprint","strictness"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was playing around with strictness and performed following test:\r\n\r\n{{{#!hs\r\nPrelude> x = [True, False]\r\nPrelude> :sprint x\r\nx = _\r\nPrelude> x `seq` True\r\nTrue\r\nPrelude> :sprint x\r\nx = _\r\n}}}\r\n\r\nI completely don't understand why `x = _` at this moment. `seq` must evaluate one level of `x` achieving `x = True : _` to ensure that it is not `undefined`, so why is this information lost? \r\n\r\nI am testing it on GHCi version 8.6.3, but it is not reproducible on other versions (checked on 8.4.4, 8.2.2 and 7._._). \r\n\r\nI have asked about it on SO, so if this behavior is intended I kindly ask for explaination here [https://stackoverflow.com/questions/53898220/sprint-and-seq-together-missing-evaluation] to let others know.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16088The 'impossible' happened when I was trying to use getCurrentDirectory in rep...2019-07-07T18:01:34ZhanraiThe 'impossible' happened when I was trying to use getCurrentDirectory in repl in spacemacs.I got this message when I type 'getCurrentDirectory' in repl in spacemacs.
ghc.exe: panic! (the 'impossible' happened)
> (GHC version 8.4.4 for x86_64-unknown-mingw32):
nameModule
system $dShow_adyn
Call stack:
CallStack (from ...I got this message when I type 'getCurrentDirectory' in repl in spacemacs.
ghc.exe: panic! (the 'impossible' happened)
> (GHC version 8.4.4 for x86_64-unknown-mingw32):
nameModule
system $dShow_adyn
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler\\utils\\Outputable.hs:1150:37 in ghc:Outputable
> pprPanic, called at compiler\\basicTypes\\Name.hs:241:3 in ghc:Name
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.4 |
| 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":"The 'impossible' happened when I was trying to use getCurrentDirectory in repl in spacemacs.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I got this message when I type 'getCurrentDirectory' in repl in spacemacs.\r\n\r\nghc.exe: panic! (the 'impossible' happened)\r\n (GHC version 8.4.4 for x86_64-unknown-mingw32):\r\n\tnameModule\r\n system $dShow_adyn\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\\basicTypes\\Name.hs:241:3 in ghc:Name\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16087TH tests fail in ext-interp way when ghc-stage2 is built using LLVM2021-05-24T14:15:07ZBen GamariTH tests fail in ext-interp way when ghc-stage2 is built using LLVMThis is a continuation of #15274.
Currently the testsuite fails with around 40 test failures, all in `th/` in the `ext-interp` way when building GHC with `BUILD_FLAVOUR=perf-llvm`:
```
Unexpected results from:
TEST="ClosedFam1TH T10620...This is a continuation of #15274.
Currently the testsuite fails with around 40 test failures, all in `th/` in the `ext-interp` way when building GHC with `BUILD_FLAVOUR=perf-llvm`:
```
Unexpected results from:
TEST="ClosedFam1TH T10620 T10828 T11721_TH T11797 T12478_1 T12646 T13642 T14060 T15502 T15738 T15792 T15845 T1835 T3920 T4135 T4188 T5037 T5362 T7477 T8761 T8884 T8953 T9262 T9692 T9738 TH_RichKinds TH_RichKinds2 TH_Roles3 TH_TyInstWhere2 TH_implicitParams TH_reifyDecl1 TH_reifyExplicitForAllFams TH_reifyInstances TH_reifyMkName TH_repE2 TH_repGuard TH_repPrim TH_repPrim2 TH_repUnboxedTuples"
SUMMARY for test run started at Sun Dec 23 06:01:39 2018 UTC
0:10:09 spent to go through
6745 total tests, which gave rise to
26266 test cases, of which
19055 were skipped
42 had missing libraries
7040 expected passes
89 expected failures
0 caused framework failures
0 caused framework warnings
0 unexpected passes
40 unexpected failures
0 unexpected stat failures
Unexpected failures:
th/TH_repE2.run TH_repE2 [exit code non-0] (ext-interp)
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_reifyDecl1.run TH_reifyDecl1 [exit code non-0] (ext-interp)
th/TH_reifyMkName.run TH_reifyMkName [exit code non-0] (ext-interp)
th/TH_reifyInstances.run TH_reifyInstances [exit code non-0] (ext-interp)
th/TH_reifyExplicitForAllFams.run TH_reifyExplicitForAllFams [exit code non-0] (ext-interp)
th/T3920.run T3920 [exit code non-0] (ext-interp)
th/T4188.run T4188 [exit code non-0] (ext-interp)
th/T1835.run T1835 [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/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/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/T9738.run T9738 [exit code non-0] (ext-interp)
th/T10620.run T10620 [exit code non-0] (ext-interp)
th/T10828.run T10828 [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/T8761.run T8761 [exit code non-0] (ext-interp)
th/T12478_1.run T12478_1 [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/T14060.run T14060 [exit code non-0] (ext-interp)
th/T15502.run T15502 [exit code non-0] (ext-interp)
th/TH_implicitParams.run TH_implicitParams [exit code non-0] (ext-interp)
th/T15738.run T15738 [exit code non-0] (ext-interp)
th/T15792.run T15792 [exit code non-0] (ext-interp)
th/T15845.run T15845 [exit code non-0] (ext-interp)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (LLVM) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TH tests fail in ext-interp way when ghc-stage2 is built using LLVM","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is a continuation of #15274.\r\n\r\nCurrently the testsuite fails with around 40 test failures, all in `th/` in the `ext-interp` way when building GHC with `BUILD_FLAVOUR=perf-llvm`:\r\n{{{\r\n\r\nUnexpected results from:\r\nTEST=\"ClosedFam1TH T10620 T10828 T11721_TH T11797 T12478_1 T12646 T13642 T14060 T15502 T15738 T15792 T15845 T1835 T3920 T4135 T4188 T5037 T5362 T7477 T8761 T8884 T8953 T9262 T9692 T9738 TH_RichKinds TH_RichKinds2 TH_Roles3 TH_TyInstWhere2 TH_implicitParams TH_reifyDecl1 TH_reifyExplicitForAllFams TH_reifyInstances TH_reifyMkName TH_repE2 TH_repGuard TH_repPrim TH_repPrim2 TH_repUnboxedTuples\"\r\n\r\nSUMMARY for test run started at Sun Dec 23 06:01:39 2018 UTC\r\n 0:10:09 spent to go through\r\n 6745 total tests, which gave rise to\r\n 26266 test cases, of which\r\n 19055 were skipped\r\n\r\n 42 had missing libraries\r\n 7040 expected passes\r\n 89 expected failures\r\n\r\n 0 caused framework failures\r\n 0 caused framework warnings\r\n 0 unexpected passes\r\n 40 unexpected failures\r\n 0 unexpected stat failures\r\n\r\nUnexpected failures:\r\n th/TH_repE2.run TH_repE2 [exit code non-0] (ext-interp)\r\n th/TH_repPrim.run TH_repPrim [exit code non-0] (ext-interp)\r\n th/TH_repPrim2.run TH_repPrim2 [exit code non-0] (ext-interp)\r\n th/TH_repUnboxedTuples.run TH_repUnboxedTuples [exit code non-0] (ext-interp)\r\n th/TH_repGuard.run TH_repGuard [exit code non-0] (ext-interp)\r\n th/TH_reifyDecl1.run TH_reifyDecl1 [exit code non-0] (ext-interp)\r\n th/TH_reifyMkName.run TH_reifyMkName [exit code non-0] (ext-interp)\r\n th/TH_reifyInstances.run TH_reifyInstances [exit code non-0] (ext-interp)\r\n th/TH_reifyExplicitForAllFams.run TH_reifyExplicitForAllFams [exit code non-0] (ext-interp)\r\n th/T3920.run T3920 [exit code non-0] (ext-interp)\r\n th/T4188.run T4188 [exit code non-0] (ext-interp)\r\n th/T1835.run T1835 [exit code non-0] (ext-interp)\r\n th/T5037.run T5037 [exit code non-0] (ext-interp)\r\n th/T5362.run T5362 [exit code non-0] (ext-interp)\r\n th/TH_RichKinds.run TH_RichKinds [exit code non-0] (ext-interp)\r\n th/TH_RichKinds2.run TH_RichKinds2 [exit code non-0] (ext-interp)\r\n th/T4135.run T4135 [exit code non-0] (ext-interp)\r\n th/TH_TyInstWhere2.run TH_TyInstWhere2 [exit code non-0] (ext-interp)\r\n th/ClosedFam1TH.run ClosedFam1TH [exit code non-0] (ext-interp)\r\n th/TH_Roles3.run TH_Roles3 [exit code non-0] (ext-interp)\r\n th/T7477.run T7477 [exit code non-0] (ext-interp)\r\n th/T8884.run T8884 [exit code non-0] (ext-interp)\r\n th/T9262.run T9262 [exit code non-0] (ext-interp)\r\n th/T9692.run T9692 [exit code non-0] (ext-interp)\r\n th/T8953.run T8953 [exit code non-0] (ext-interp)\r\n th/T9738.run T9738 [exit code non-0] (ext-interp)\r\n th/T10620.run T10620 [exit code non-0] (ext-interp)\r\n th/T10828.run T10828 [exit code non-0] (ext-interp)\r\n th/T11721_TH.run T11721_TH [exit code non-0] (ext-interp)\r\n th/T11797.run T11797 [exit code non-0] (ext-interp)\r\n th/T8761.run T8761 [exit code non-0] (ext-interp)\r\n th/T12478_1.run T12478_1 [exit code non-0] (ext-interp)\r\n th/T12646.run T12646 [exit code non-0] (ext-interp)\r\n th/T13642.run T13642 [exit code non-0] (ext-interp)\r\n th/T14060.run T14060 [exit code non-0] (ext-interp)\r\n th/T15502.run T15502 [exit code non-0] (ext-interp)\r\n th/TH_implicitParams.run TH_implicitParams [exit code non-0] (ext-interp)\r\n th/T15738.run T15738 [exit code non-0] (ext-interp)\r\n th/T15792.run T15792 [exit code non-0] (ext-interp)\r\n th/T15845.run T15845 [exit code non-0] (ext-interp)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/16086Compile countLeadingZeros to lzcnt if -mbmi2 is set2019-07-07T18:01:34ZDmitry IvanovCompile countLeadingZeros to lzcnt if -mbmi2 is setI started implementing this in https://gitlab.haskell.org/ghc/ghc/merge_requests/27
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version ...I started implementing this in https://gitlab.haskell.org/ghc/ghc/merge_requests/27
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Compile countLeadingZeros to lzcnt if -mbmi2 is set","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I started implementing this in https://gitlab.haskell.org/ghc/ghc/merge_requests/27","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1Dmitry IvanovDmitry Ivanovhttps://gitlab.haskell.org/ghc/ghc/-/issues/16085ffi018_ghci fails when unregisterised2021-09-07T16:26:15ZBen Gamariffi018_ghci fails when unregisterised```patch
--- /dev/null 2018-12-22 16:25:47.047680317 +0000
+++ ffi/should_run/ffi018_ghci.run/ffi018_ghci.run.stderr.normalised 2018-12-22 17:31:34.178826693 +0000
@@ -0,0 +1,4 @@
+
+ffi018_ghci:6:30:
+ Not in scope: ‘Main.main’
+ ...```patch
--- /dev/null 2018-12-22 16:25:47.047680317 +0000
+++ ffi/should_run/ffi018_ghci.run/ffi018_ghci.run.stderr.normalised 2018-12-22 17:31:34.178826693 +0000
@@ -0,0 +1,4 @@
+
+ffi018_ghci:6:30:
+ Not in scope: ‘Main.main’
+ No module named ‘Main’ is imported.
```
I suspect the testsuite driver is hiding the interesting part of the failure.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"ffi018_ghci fails when unregisterised","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!patch\r\n--- /dev/null\t2018-12-22 16:25:47.047680317 +0000\r\n+++ ffi/should_run/ffi018_ghci.run/ffi018_ghci.run.stderr.normalised\t2018-12-22 17:31:34.178826693 +0000\r\n@@ -0,0 +1,4 @@\r\n+\r\n+ffi018_ghci:6:30:\r\n+ Not in scope: ‘Main.main’\r\n+ No module named ‘Main’ is imported.\r\n}}}\r\n\r\nI suspect the testsuite driver is hiding the interesting part of the failure.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16084Improve link times on Windows by using LLD for linking2022-04-08T15:01:19ZBen GamariImprove link times on Windows by using LLD for linkingCurrently the Windows CI builds are typically lasting over 3 hours. The primary cause of this appears to be poor performance in `ld.bfd`, especially when linking testsuite tests.
One option to fix this is to try using LLD for linking. U...Currently the Windows CI builds are typically lasting over 3 hours. The primary cause of this appears to be poor performance in `ld.bfd`, especially when linking testsuite tests.
One option to fix this is to try using LLD for linking. Unfortunately the msys2 `gcc` does not support `-fuse-ld=lld`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"Improve link times on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently the Windows CI builds are typically lasting over 3 hours. The primary cause of this appears to be poor performance in `ld.bfd`, especially when linking testsuite tests.\r\n\r\nOne option to fix this is to try using LLD for linking. Unfortunately the msys2 `gcc` does not support `-fuse-ld=lld`.","type_of_failure":"OtherFailure","blocking":[]} -->9.4.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16083tests relying on <iostream> are broken on Mojave builder2021-11-19T10:07:10ZBen Gamaritests relying on <iostream> are broken on Mojave builderIt appears that something has changed in the Darwin toolchain such that `<iostream>` is no longer found by default:
```
cd "driver/recomp001/recomp001.run" && $MAKE -s --no-print-directory recomp001
Compile failed (exit code 1) errors...It appears that something has changed in the Darwin toolchain such that `<iostream>` is no longer found by default:
```
cd "driver/recomp001/recomp001.run" && $MAKE -s --no-print-directory recomp001
Compile failed (exit code 1) errors were:
warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
objcpp-hi.mm:2:9: error: fatal error: 'iostream' file not found
#import <iostream>
^~~~~~~~~~
1 warning and 1 error generated.
`gcc' failed in phase `C Compiler'. (Exit code: 1)
*** unexpected failure for objcpp-hi(normal)
Compile failed (exit code 1) errors were:
warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
/var/folders/pb/c3dc08v12yzc536lnrnngvd40000gq/T/ghc56064_0/ghc_2.cpp:1:10: error:
fatal error: 'iostream' file not found
#include <iostream>
^~~~~~~~~~
1 warning and 1 error generated.
`gcc' failed in phase `C Compiler'. (Exit code: 1)
*** unexpected failure for T13366(normal)
```
Marking as broken.https://gitlab.haskell.org/ghc/ghc/-/issues/16082Sort out treatment of underscores in types2020-06-05T13:27:57ZRichard Eisenbergrae@richarde.devSort out treatment of underscores in typesI can count 4 different meanings for underscores in Haskell programs:
1. A pattern for which we don't care to write a name. (This dates back to antiquity.)
Example:
```hs
const x _ = x
```
1. An expression for which we want GHC to te...I can count 4 different meanings for underscores in Haskell programs:
1. A pattern for which we don't care to write a name. (This dates back to antiquity.)
Example:
```hs
const x _ = x
```
1. An expression for which we want GHC to tell us what its expected type should be. (Relatively new: these are typed holes.)
Example:
```hs
plus x y = x + _
```
1. A type which we want GHC to infer, by looking at the expression. (Relatively new: these are wild cards in partial type signatures.)
Example:
```hs
plus :: forall a. Num a => a -> a -> _
plus x y = x + y
```
1. A type which we want GHC to infer, by looking at the underscore's context. (Relatively new: these are wild cards in type applications.)
Example:
```hs
x = const @_ @Bool 'x' -- the _ is inferred to mean Char
```
Problems arise with the advent of visible kind application (#12045): In type signatures, 3 of these meanings make sense (2, 3, and 4). In type/data family patterns, 3 of these meanings make sense (1, 2, and 4). Ideally, the user should have the opportunity to choose which meaning they want. In contrast, right now we use heuristics: in visible type/kind applications, we always use (4); otherwise, we use (1) (in patterns) or (3) (in types).
This is a mess, for at least three reasons:
A. Users might conceivably want different behavior than what we provide. For example, perhaps a user is writing an intricate pattern (at either term or type level) and wants to know the type (resp. kind) of the next bit of pattern. Or maybe the user wants to do this in a visible type application. Right now, there's just no way to do this.
B. It causes trouble for pretty-printing. Aside from term-level patterns, all the uses of underscores above are stored identically in the AST. This means that they are printed identically. But that's strange. For example, uses (3) and (4) might have different underscores meaning different variables. Should we number the underscores? But that would be silly for usage (1). It's all a bit muddy.
C. This causes awkwardness in the implementation. #12045 has to twiddle DynFlags to get its desired behavior, and that's sad.
This ticket is to track resolutions to these problems.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.7 |
| 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":"Sort out treatment of underscores in types","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I can count 4 different meanings for underscores in Haskell programs:\r\n\r\n1. A pattern for which we don't care to write a name. (This dates back to antiquity.)\r\nExample: \r\n{{{#!hs\r\nconst x _ = x\r\n}}}\r\n\r\n2. An expression for which we want GHC to tell us what its expected type should be. (Relatively new: these are typed holes.)\r\nExample: \r\n{{{#!hs\r\nplus x y = x + _\r\n}}}\r\n\r\n3. A type which we want GHC to infer, by looking at the expression. (Relatively new: these are wild cards in partial type signatures.)\r\nExample: \r\n{{{#!hs\r\nplus :: forall a. Num a => a -> a -> _\r\nplus x y = x + y\r\n}}}\r\n\r\n4. A type which we want GHC to infer, by looking at the underscore's context. (Relatively new: these are wild cards in type applications.)\r\nExample:\r\n{{{#!hs\r\nx = const @_ @Bool 'x' -- the _ is inferred to mean Char\r\n}}}\r\n\r\nProblems arise with the advent of visible kind application (#12045): In type signatures, 3 of these meanings make sense (2, 3, and 4). In type/data family patterns, 3 of these meanings make sense (1, 2, and 4). Ideally, the user should have the opportunity to choose which meaning they want. In contrast, right now we use heuristics: in visible type/kind applications, we always use (4); otherwise, we use (1) (in patterns) or (3) (in types).\r\n\r\nThis is a mess, for at least three reasons:\r\n\r\nA. Users might conceivably want different behavior than what we provide. For example, perhaps a user is writing an intricate pattern (at either term or type level) and wants to know the type (resp. kind) of the next bit of pattern. Or maybe the user wants to do this in a visible type application. Right now, there's just no way to do this.\r\n\r\nB. It causes trouble for pretty-printing. Aside from term-level patterns, all the uses of underscores above are stored identically in the AST. This means that they are printed identically. But that's strange. For example, uses (3) and (4) might have different underscores meaning different variables. Should we number the underscores? But that would be silly for usage (1). It's all a bit muddy.\r\n\r\nC. This causes awkwardness in the implementation. #12045 has to twiddle DynFlags to get its desired behavior, and that's sad.\r\n\r\nThis ticket is to track resolutions to these problems.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16081Clean up family instance consistency checking2022-06-02T02:56:09ZSimon Peyton JonesClean up family instance consistency checkingThere is a big mess concerning consistency checking for family instances. It's described in `Note [The type family instance consistency story]` in `FamInst`, which is reproduced below.
Note in particular the "four subtle points that hav...There is a big mess concerning consistency checking for family instances. It's described in `Note [The type family instance consistency story]` in `FamInst`, which is reproduced below.
Note in particular the "four subtle points that have not been addressed yet". The fourth one bit me today, and forced me to introduce a new hack into `loadIface`, described in `Note [Loading your own hi-boot file]` in `LoadIface`.
Somehow we should be able to do better!
```
{- Note [The type family instance consistency story]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To preserve type safety we must ensure that for any given module, all
the type family instances used either in that module or in any module
it directly or indirectly imports are consistent. For example, consider
module F where
type family F a
module A where
import F( F )
type instance F Int = Bool
f :: F Int -> Bool
f x = x
module B where
import F( F )
type instance F Int = Char
g :: Char -> F Int
g x = x
module Bad where
import A( f )
import B( g )
bad :: Char -> Int
bad c = f (g c)
Even though module Bad never mentions the type family F at all, by
combining the functions f and g that were type checked in contradictory
type family instance environments, the function bad is able to coerce
from one type to another. So when we type check Bad we must verify that
the type family instances defined in module A are consistent with those
defined in module B.
How do we ensure that we maintain the necessary consistency?
* Call a module which defines at least one type family instance a
"family instance module". This flag `mi_finsts` is recorded in the
interface file.
* For every module we calculate the set of all of its direct and
indirect dependencies that are family instance modules. This list
`dep_finsts` is also recorded in the interface file so we can compute
this list for a module from the lists for its direct dependencies.
* When type checking a module M we check consistency of all the type
family instances that are either provided by its `dep_finsts` or
defined in the module M itself. This is a pairwise check, i.e., for
every pair of instances we must check that they are consistent.
- For family instances coming from `dep_finsts`, this is checked in
checkFamInstConsistency, called from tcRnImports. See Note
[Checking family instance consistency] for details on this check
(and in particular how we avoid having to do all these checks for
every module we compile).
- That leaves checking the family instances defined in M itself
against instances defined in either M or its `dep_finsts`. This is
checked in `tcExtendLocalFamInstEnv'.
There are four subtle points in this scheme which have not been
addressed yet.
* We have checked consistency of the family instances *defined* by M
or its imports, but this is not by definition the same thing as the
family instances *used* by M or its imports. Specifically, we need to
ensure when we use a type family instance while compiling M that this
instance was really defined from either M or one of its imports,
rather than being an instance that we happened to know about from
reading an interface file in the course of compiling an unrelated
module. Otherwise, we'll end up with no record of the fact that M
depends on this family instance and type safety will be compromised.
See #13102.
* It can also happen that M uses a function defined in another module
which is not transitively imported by M. Examples include the
desugaring of various overloaded constructs, and references inserted
by Template Haskell splices. If that function's definition makes use
of type family instances which are not checked against those visible
from M, type safety can again be compromised. See #13251.
* When a module C imports a boot module B.hs-boot, we check that C's
type family instances are compatible with those visible from
B.hs-boot. However, C will eventually be linked against a different
module B.hs, which might define additional type family instances which
are inconsistent with C's. This can also lead to loss of type safety.
See #9562.
* The call to checkFamConsistency for imported functions occurs very
early (in tcRnImports) and that causes problems if the imported
instances use type declared in the module being compiled.
See Note [Loading your own hi-boot file] in LoadIface.
-}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ezyang |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Clean up family instance consistency checking","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ezyang"],"type":"Bug","description":"There is a big mess concerning consistency checking for family instances. It's described in `Note [The type family instance consistency story]` in `FamInst`, which is reproduced below.\r\n\r\nNote in particular the \"four subtle points that have not been addressed yet\". The fourth one bit me today, and forced me to introduce a new hack into `loadIface`, described in `Note [Loading your own hi-boot file]` in `LoadIface`.\r\n\r\nSomehow we should be able to do better!\r\n{{{\r\n{- Note [The type family instance consistency story]\r\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n\r\nTo preserve type safety we must ensure that for any given module, all\r\nthe type family instances used either in that module or in any module\r\nit directly or indirectly imports are consistent. For example, consider\r\n\r\n module F where\r\n type family F a\r\n\r\n module A where\r\n import F( F )\r\n type instance F Int = Bool\r\n f :: F Int -> Bool\r\n f x = x\r\n\r\n module B where\r\n import F( F )\r\n type instance F Int = Char\r\n g :: Char -> F Int\r\n g x = x\r\n\r\n module Bad where\r\n import A( f )\r\n import B( g )\r\n bad :: Char -> Int\r\n bad c = f (g c)\r\n\r\nEven though module Bad never mentions the type family F at all, by\r\ncombining the functions f and g that were type checked in contradictory\r\ntype family instance environments, the function bad is able to coerce\r\nfrom one type to another. So when we type check Bad we must verify that\r\nthe type family instances defined in module A are consistent with those\r\ndefined in module B.\r\n\r\nHow do we ensure that we maintain the necessary consistency?\r\n\r\n* Call a module which defines at least one type family instance a\r\n \"family instance module\". This flag `mi_finsts` is recorded in the\r\n interface file.\r\n\r\n* For every module we calculate the set of all of its direct and\r\n indirect dependencies that are family instance modules. This list\r\n `dep_finsts` is also recorded in the interface file so we can compute\r\n this list for a module from the lists for its direct dependencies.\r\n\r\n* When type checking a module M we check consistency of all the type\r\n family instances that are either provided by its `dep_finsts` or\r\n defined in the module M itself. This is a pairwise check, i.e., for\r\n every pair of instances we must check that they are consistent.\r\n\r\n - For family instances coming from `dep_finsts`, this is checked in\r\n checkFamInstConsistency, called from tcRnImports. See Note\r\n [Checking family instance consistency] for details on this check\r\n (and in particular how we avoid having to do all these checks for\r\n every module we compile).\r\n\r\n - That leaves checking the family instances defined in M itself\r\n against instances defined in either M or its `dep_finsts`. This is\r\n checked in `tcExtendLocalFamInstEnv'.\r\n\r\nThere are four subtle points in this scheme which have not been\r\naddressed yet.\r\n\r\n* We have checked consistency of the family instances *defined* by M\r\n or its imports, but this is not by definition the same thing as the\r\n family instances *used* by M or its imports. Specifically, we need to\r\n ensure when we use a type family instance while compiling M that this\r\n instance was really defined from either M or one of its imports,\r\n rather than being an instance that we happened to know about from\r\n reading an interface file in the course of compiling an unrelated\r\n module. Otherwise, we'll end up with no record of the fact that M\r\n depends on this family instance and type safety will be compromised.\r\n See #13102.\r\n\r\n* It can also happen that M uses a function defined in another module\r\n which is not transitively imported by M. Examples include the\r\n desugaring of various overloaded constructs, and references inserted\r\n by Template Haskell splices. If that function's definition makes use\r\n of type family instances which are not checked against those visible\r\n from M, type safety can again be compromised. See #13251.\r\n\r\n* When a module C imports a boot module B.hs-boot, we check that C's\r\n type family instances are compatible with those visible from\r\n B.hs-boot. However, C will eventually be linked against a different\r\n module B.hs, which might define additional type family instances which\r\n are inconsistent with C's. This can also lead to loss of type safety.\r\n See #9562.\r\n\r\n* The call to checkFamConsistency for imported functions occurs very\r\n early (in tcRnImports) and that causes problems if the imported\r\n instances use type declared in the module being compiled.\r\n See Note [Loading your own hi-boot file] in LoadIface.\r\n-}\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16080runTestTT from ghci caused a panic.2019-07-07T18:01:36ZemacsthevikingrunTestTT from ghci caused a panic.Inside a REPL within Emacs+Intero-mode, running a stack project. I am writing a simple lexer for fun and I decided to try to see why I wasn't getting expected behaviour from an HUnit function.
```
runTestTT classificationTests
ghc: pan...Inside a REPL within Emacs+Intero-mode, running a stack project. I am writing a simple lexer for fun and I decided to try to see why I wasn't getting expected behaviour from an HUnit function.
```
runTestTT classificationTests
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.4 for x86_64-unknown-linux):
nameModule
system $dShow_a5Xw
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.4 |
| 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":"runTestTT from ghci caused a panic.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Inside a REPL within Emacs+Intero-mode, running a stack project. I am writing a simple lexer for fun and I decided to try to see why I wasn't getting expected behaviour from an HUnit function.\r\n\r\n\r\n{{{\r\n runTestTT classificationTests\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.4 for x86_64-unknown-linux):\r\n\tnameModule\r\n system $dShow_a5Xw\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/basicTypes/Name.hs:241:3 in ghc:Name\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16079runTestTT from ghci caused a panic.2019-07-07T18:01:36ZemacsthevikingrunTestTT from ghci caused a panic.Inside a REPL within Emacs+Intero-mode, running a stack project. I am writing a simple lexer for fun and I decided to try to see why I wasn't getting expected behaviour from an HUnit function.
I have attached the tar-balled stack projec...Inside a REPL within Emacs+Intero-mode, running a stack project. I am writing a simple lexer for fun and I decided to try to see why I wasn't getting expected behaviour from an HUnit function.
I have attached the tar-balled stack project for completeness, apologies for the size but I didn't want to risk omiotting anything important to you guys if this ever gets looked at in the melee!
```
runTestTT classificationTests
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.4 for x86_64-unknown-linux):
nameModule
system $dShow_a5Xw
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.4 |
| 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":"runTestTT from ghci caused a panic.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Inside a REPL within Emacs+Intero-mode, running a stack project. I am writing a simple lexer for fun and I decided to try to see why I wasn't getting expected behaviour from an HUnit function.\r\n\r\nI have attached the tar-balled stack project for completeness, apologies for the size but I didn't want to risk omiotting anything important to you guys if this ever gets looked at in the melee!\r\n\r\n{{{\r\n runTestTT classificationTests\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.4 for x86_64-unknown-linux):\r\n\tnameModule\r\n system $dShow_a5Xw\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/basicTypes/Name.hs:241:3 in ghc:Name\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16077AvailTC Invariant being violated2019-07-07T18:01:37ZAlec TheriaultAvailTC Invariant being violatedThe `AvailTC Invariant` (from `basicTypes/Avail.hs`) states that:
```
If the type or class is itself
to be in scope, it must be
*first* in this list. Thus,
typically: @AvailTC Eq [Eq, ==, \/=]@
```
Here is a case where this invariant ...The `AvailTC Invariant` (from `basicTypes/Avail.hs`) states that:
```
If the type or class is itself
to be in scope, it must be
*first* in this list. Thus,
typically: @AvailTC Eq [Eq, ==, \/=]@
```
Here is a case where this invariant is not upheld:
- `pkgA/pkgA.cabal`:
```
name: pkgA
version: 1.0.0
build-type: Simple
cabal-version: >= 1.2
library
exposed-modules: A
build-depends: base
```
- `pkgA/A.hs`
```
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeFamilies #-}
module A
( C(..)
, T(TI)
, error
) where
class C a where
data T a
instance C Int where
data T Int = TI { ti :: Int }
```
- `pkgB/pkgB.cabal`
```
name: pkgB
version: 1.0.0
build-type: Simple
cabal-version: >= 1.2
library
exposed-modules: B
build-depends: base, pkgA
```
- `pkgB/B.hs`
```
module B
( module A
) where
import A hiding (error)
```
Now, check out the exports for `A` vs. `B`:
```
$ cabal new-build pkgA pkgB --ghc-options -ddump-rn-trace | grep rnExports
Warning: The package list for 'hackage.haskell.org' is 38 days old.
Run 'cabal update' to get the latest list of available packages.
rnExports: Exports: [error, C{C, T;}, T{T, TI;}]
rnExports: Exports: [C{C, T;}, T{TI;}]
```
Why is `T{TI;}` in the second line not `T{T, TI;}`? Shouldn't the exports for `B` be identical to those for `A` (except for `error`)?
This is causing a crash in Haddock: https://github.com/haskell/haddock/issues/979.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"AvailTC Invariant being violated","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The `AvailTC Invariant` (from `basicTypes/Avail.hs`) states that:\r\n\r\n{{{\r\nIf the type or class is itself\r\nto be in scope, it must be\r\n*first* in this list. Thus,\r\ntypically: @AvailTC Eq [Eq, ==, \\/=]@\r\n}}}\r\n\r\nHere is a case where this invariant is not upheld:\r\n\r\n * `pkgA/pkgA.cabal`:\r\n{{{\r\nname: pkgA\r\nversion: 1.0.0\r\nbuild-type: Simple\r\ncabal-version: >= 1.2\r\n\r\nlibrary\r\n exposed-modules: A\r\n build-depends: base\r\n}}}\r\n\r\n * `pkgA/A.hs`\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule A\r\n ( C(..)\r\n , T(TI)\r\n , error\r\n ) where\r\n\r\nclass C a where\r\n data T a\r\n\r\ninstance C Int where\r\n data T Int = TI { ti :: Int }\r\n}}}\r\n\r\n * `pkgB/pkgB.cabal`\r\n{{{\r\nname: pkgB\r\nversion: 1.0.0\r\nbuild-type: Simple\r\ncabal-version: >= 1.2\r\n\r\nlibrary\r\n exposed-modules: B\r\n build-depends: base, pkgA\r\n}}}\r\n\r\n * `pkgB/B.hs`\r\n{{{\r\nmodule B\r\n ( module A\r\n ) where\r\n\r\nimport A hiding (error)\r\n}}}\r\n\r\nNow, check out the exports for `A` vs. `B`:\r\n\r\n{{{\r\n$ cabal new-build pkgA pkgB --ghc-options -ddump-rn-trace | grep rnExports\r\nWarning: The package list for 'hackage.haskell.org' is 38 days old.\r\nRun 'cabal update' to get the latest list of available packages.\r\nrnExports: Exports: [error, C{C, T;}, T{T, TI;}]\r\nrnExports: Exports: [C{C, T;}, T{TI;}]\r\n}}}\r\n\r\nWhy is `T{TI;}` in the second line not `T{T, TI;}`? Shouldn't the exports for `B` be identical to those for `A` (except for `error`)? \r\n\r\nThis is causing a crash in Haddock: https://github.com/haskell/haddock/issues/979.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16076Internal compiler error when instance uses FFI function and defining other in...2022-08-09T14:03:36ZradekchannableInternal compiler error when instance uses FFI function and defining other instance of the same class through Template HaskellWhen one module defines an FFI function and uses it in an instance, and a Template Haskell function to derive an instance of the same class, using the function in another module causes GHC to crash, complaining it cannot find the FFI fun...When one module defines an FFI function and uses it in an instance, and a Template Haskell function to derive an instance of the same class, using the function in another module causes GHC to crash, complaining it cannot find the FFI function.
See the attached modules for an example. Use the following command to trigger the bug (ensure template-haskell is available):
```
$ ghc Bar.hs
[1 of 2] Compiling Foo ( Foo.hs, Foo.o )
[2 of 2] Compiling Bar ( Bar.hs, Bar.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.4 for x86_64-unknown-linux):
Loading temp shared object failed: /tmp/ghc13955_0/libghc_6.so: undefined symbol: showFoo
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.4 |
| 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":"Internal compiler error when instance uses FFI function and defining other instance of the same class through Template Haskell","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When one module defines an FFI function and uses it in an instance, and a Template Haskell function to derive an instance of the same class, using the function in another module causes GHC to crash, complaining it cannot find the FFI function.\r\n\r\nSee the attached modules for an example. Use the following command to trigger the bug (ensure template-haskell is available):\r\n\r\n{{{\r\n$ ghc Bar.hs\r\n[1 of 2] Compiling Foo ( Foo.hs, Foo.o )\r\n[2 of 2] Compiling Bar ( Bar.hs, Bar.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.4 for x86_64-unknown-linux):\r\n\tLoading temp shared object failed: /tmp/ghc13955_0/libghc_6.so: undefined symbol: showFoo\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16075Weverything ignores some OPTIONS_GHC flags2019-07-07T18:01:37ZEric CrockettWeverything ignores some OPTIONS_GHC flagsWhen I enable `-Weverything`, some `OPTIONS_GHC` pragmas are respected, while others are ignored. For example, with `-Weverything`, this file
```
main = print "hello"
foo :: (Num a, Show a) => a -> IO ()
foo = print . show
```
generat...When I enable `-Weverything`, some `OPTIONS_GHC` pragmas are respected, while others are ignored. For example, with `-Weverything`, this file
```
main = print "hello"
foo :: (Num a, Show a) => a -> IO ()
foo = print . show
```
generates warnings about:
1. missing an export list
1. top-level binding \[main\] with no type sig
1. redundant constraint \[Num a\]
If I add `{-# OPTIONS_GHC -fno-warn-missing-signatures -fno-warn-missing-export-lists -fno-warn-redundant-constraints #-}` to the top of the file and recompile, I expect all warnings to go away. But GHC still reports that `main` has no signature.
Note that this problem doesn't occur with `-Wall`. With `-Wall`, the code snippet warns about the missing signature on `main`, but when I add the `OPTIONS_GHC`, the warning goes away. Thus this problem appears to be unique to `Weverything`.https://gitlab.haskell.org/ghc/ghc/-/issues/16074Hopelessly confusing error involving runtime-reps2021-08-06T19:06:52ZSimon Peyton JonesHopelessly confusing error involving runtime-repsConsider
```
{-# LANGUAGE GADTs, TypeOperators, PolyKinds #-}
import GHC.Types
data a :~: b where Refl :: a :~: a
foo :: TYPE a :~: TYPE b
foo = Refl
```
We get
```
• Couldn't match type ‘'LiftedRep’ with ‘'LiftedRep’
‘a’...Consider
```
{-# LANGUAGE GADTs, TypeOperators, PolyKinds #-}
import GHC.Types
data a :~: b where Refl :: a :~: a
foo :: TYPE a :~: TYPE b
foo = Refl
```
We get
```
• Couldn't match type ‘'LiftedRep’ with ‘'LiftedRep’
‘a’ is a rigid type variable bound by
the type signature for:
foo :: * :~: *
at Repr.hs:7:1-24
‘b’ is a rigid type variable bound by
the type signature for:
foo :: * :~: *
at Repr.hs:7:1-24
```
That's a ridiculous message. But if you asdd `-fprint-explicit-runtime-reps` we get
```
• Couldn't match type ‘a’ with ‘b’
‘a’ is a rigid type variable bound by
the type signature for:
foo :: forall (a :: RuntimeRep) (b :: RuntimeRep).
TYPE a :~: TYPE b
at T16050.hs:9:1-24
‘b’ is a rigid type variable bound by
the type signature for:
foo :: forall (a :: RuntimeRep) (b :: RuntimeRep).
TYPE a :~: TYPE b
at T16050.hs:9:1-24
Expected type: TYPE a :~: TYPE b
Actual type: TYPE a :~: TYPE a
• In the expression: Refl
In an equation for ‘foo’: foo = Refl
• Relevant bindings include
foo :: TYPE a :~: TYPE b (bound at T16050.hs:10:1)
```
which is the right error.
Reported in #16074 of #16050https://gitlab.haskell.org/ghc/ghc/-/issues/16073Hadrian build fails on Windows2019-07-07T18:01:38ZBen GamariHadrian build fails on Windows```
/---------------------------------------------------\
| Successfully built library 'rts' (Stage1, way v). |
| Library: _build/stage1/rts/build/libHSrts-1.0.a |
\---------------------------------------------------/
| Run Ld Stage1: ...```
/---------------------------------------------------\
| Successfully built library 'rts' (Stage1, way v). |
| Library: _build/stage1/rts/build/libHSrts-1.0.a |
\---------------------------------------------------/
| Run Ld Stage1: _build/stage1/rts/build/c/Adjustor.o (and 117 more) => _build/stage1/rts/build/HSrts-1.0.o
copyFile: does not exist (The system cannot find the file specified.)
shakeArgsWith 0.001s 0%
Function shake 0.017s 0%
Database read 0.337s 0%
With database 0.033s 0%
Running rules 4047.874s 99% =========================
Total 4048.261s 100%
Error when running Shake build system:
at src/Main.hs:58:30-42:
* Depends on: binary-dist
at src/Rules/BinaryDist.hs:97:9-21:
* Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf
* Raised the exception:
ExitFailure 1
```
See https://gitlab.haskell.org/ghc/ghc/-/jobs/2838.8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16072All dependencies of packages must be explicitly listed when defining flavour ...2021-05-11T10:04:14ZMatthew PickeringAll dependencies of packages must be explicitly listed when defining flavour packagesIn the Hadrian user guide, it explains that you can use the `packages` variable in order to describe what is built. However, unless you list all the dependencies of what you want to build also in `packages` then it will fail to build.
F...In the Hadrian user guide, it explains that you can use the `packages` variable in order to describe what is built. However, unless you list all the dependencies of what you want to build also in `packages` then it will fail to build.
For example, if I want to just build `ghctags` then I might try to modify `packages` to
```
ghcTagsPackages stage = case stage of
Stage2 -> [ghcTags]
_ -> []
```
but this will fail as I haven't listed any dependencies of `ghcTags` at all.
The culprit here is the `contextDependencies` function.
```
contextDependencies :: Context -> Action [Context]
contextDependencies Context {..} = do
depPkgs <- go [package]
return [ Context depStage pkg way | pkg <- depPkgs, pkg /= package ]
where
depStage = min stage Stage1
go pkgs = do
deps <- concatMapM step pkgs
let newPkgs = nubOrd $ sort (deps ++ pkgs)
if pkgs == newPkgs then return pkgs else go newPkgs
step pkg = do
deps <- pkgDependencies pkg
active <- sort <$> stagePackages depStage
return $ intersectOrd (compare . pkgName) active deps
```
Notice in the definition of `step`, the actual package dependencies are intersected with `stagePackages`.
It is also unclear to me why this function is defined recursively as surely when we `need` one dependency, that will in turn `need` its dependencies and so on.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | alpmestan, snowleopard |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"All dependencies of packages must be explicitly listed when defining flavour packages","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["alpmestan","snowleopard"],"type":"Bug","description":"In the Hadrian user guide, it explains that you can use the `packages` variable in order to describe what is built. However, unless you list all the dependencies of what you want to build also in `packages` then it will fail to build.\r\n\r\nFor example, if I want to just build `ghctags` then I might try to modify `packages` to \r\n\r\n{{{\r\nghcTagsPackages stage = case stage of\r\n Stage2 -> [ghcTags]\r\n _ -> []\r\n}}}\r\n\r\nbut this will fail as I haven't listed any dependencies of `ghcTags` at all.\r\n\r\nThe culprit here is the `contextDependencies` function.\r\n\r\n{{{\r\ncontextDependencies :: Context -> Action [Context]\r\ncontextDependencies Context {..} = do\r\n depPkgs <- go [package]\r\n return [ Context depStage pkg way | pkg <- depPkgs, pkg /= package ]\r\n where\r\n depStage = min stage Stage1\r\n go pkgs = do\r\n deps <- concatMapM step pkgs\r\n let newPkgs = nubOrd $ sort (deps ++ pkgs)\r\n if pkgs == newPkgs then return pkgs else go newPkgs\r\n step pkg = do\r\n deps <- pkgDependencies pkg\r\n active <- sort <$> stagePackages depStage\r\nreturn $ intersectOrd (compare . pkgName) active deps\r\n}}}\r\n\r\nNotice in the definition of `step`, the actual package dependencies are intersected with `stagePackages`.\r\n\r\n\r\nIt is also unclear to me why this function is defined recursively as surely when we `need` one dependency, that will in turn `need` its dependencies and so on.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16071GHC is stuck (runs indefinitely) compiling a module2019-07-07T18:01:38ZdirtypawGHC is stuck (runs indefinitely) compiling a moduleCompiling [Agda](https://github.com/agda/agda/commit/e68360b16af7865519bef77c21c66ff88139ea7e) with ghc-8.6.3 using stack, ghc is stuck at [this module](https://github.com/agda/agda/blob/master/src/full/Agda/Syntax/Internal.hs) (runs for...Compiling [Agda](https://github.com/agda/agda/commit/e68360b16af7865519bef77c21c66ff88139ea7e) with ghc-8.6.3 using stack, ghc is stuck at [this module](https://github.com/agda/agda/blob/master/src/full/Agda/Syntax/Internal.hs) (runs for 20+ min with no progress).
It looks like a regression in ghc-8.6.3 on Windows as Agda is successfully built with ghc-8.6.2 on the same machine, and Agda build with ghc-8.6.3 is generally supported (see [this issue](https://github.com/agda/agda/issues/3442)).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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 is stuck (runs indefinitely) compiling a module","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compiling [https://github.com/agda/agda/commit/e68360b16af7865519bef77c21c66ff88139ea7e Agda] with ghc-8.6.3 using stack, ghc is stuck at [https://github.com/agda/agda/blob/master/src/full/Agda/Syntax/Internal.hs this module] (runs for 20+ min with no progress).\r\n\r\nIt looks like a regression in ghc-8.6.3 on Windows as Agda is successfully built with ghc-8.6.2 on the same machine, and Agda build with ghc-8.6.3 is generally supported (see [https://github.com/agda/agda/issues/3442 this issue]).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->