GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-25T17:23:20Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24585GHC master fails to build with alex 3.5.1.02024-03-25T17:23:20ZRodrigo MesquitaGHC master fails to build with alex 3.5.1.0## Summary
Upgrading to Alex 3.5.1.0 makes compilation of GHC on master fail because of 7dfdf3d9fbc216653fe2cf95cc52c35900bdc8b4 (cc @hsyl20)
```
compiler/GHC/Parser/Lexer.x:2871:20: error: [GHC-88464]
Data constructor not in scope...## Summary
Upgrading to Alex 3.5.1.0 makes compilation of GHC on master fail because of 7dfdf3d9fbc216653fe2cf95cc52c35900bdc8b4 (cc @hsyl20)
```
compiler/GHC/Parser/Lexer.x:2871:20: error: [GHC-88464]
Data constructor not in scope: C# :: t0 -> Char
Suggested fixes:
• Perhaps use one of these:
‘GHC.Exts.C#’ (imported from GHC.Exts),
‘GHC.Exts.D#’ (imported from GHC.Exts),
‘GHC.Exts.F#’ (imported from GHC.Exts)
• Add ‘C#’ to the import list in the import of ‘GHC.Exts’
(at _build/stage0/compiler/build/GHC/Parser/Lexer.hs:100:1-202).
|
2871 |
| ^^
compiler/GHC/Parser/Lexer.x:2871:24: error: [GHC-88464]
Variable not in scope: chr# :: Int# -> t0
Suggested fixes:
• Perhaps use one of these:
‘GHC.Exts.chr#’ (imported from GHC.Exts),
‘chr’ (imported from Data.Char)
• Add ‘chr#’ to the import list in the import of ‘GHC.Exts’
(at _build/stage0/compiler/build/GHC/Parser/Lexer.hs:100:1-202).
|
2871 |
| ^^^^
```
## Steps to reproduce
Try building master with alex 3.5.1.0
## Environment
* GHC version used: 9.8.2, alex 3.5.1.0
## Solution
It seems to be sufficient to qualify the names with GHC.Extshttps://gitlab.haskell.org/ghc/ghc/-/issues/22497Frequent "bus errors" on macOS Ventura / aarch64 / GHC 9.4.32024-03-25T14:04:50ZJonathan DaughertyFrequent "bus errors" on macOS Ventura / aarch64 / GHC 9.4.3An application that I use and maintain, [matterhorn](https://github.com/matterhorn-chat/matterhorn), is crashing somewhat frequently on macOS Ventura in what appears to be GMP code. Here are the platform details:
* macOS version: Ventur...An application that I use and maintain, [matterhorn](https://github.com/matterhorn-chat/matterhorn), is crashing somewhat frequently on macOS Ventura in what appears to be GMP code. Here are the platform details:
* macOS version: Ventura 13.0.1
* `uname -a`: `Darwin 000642-jtd.local 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct 9 20:15:09 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T6000 arm64`
* Chipset: Apple M1 Max
* GHC version: 9.4.3
* Cabal and `cabal-install` versions: 3.8.1.0
I don't know for sure, but this might be a duplicate of #22408. These crashes occur seemingly at random. Sometimes the program almost immediately fails to start; at other times it runs for a while before crashing. In all cases, `Bus error: 10` is reported to the console.
Here are some crashes recorded from `lldb` along with some additional information in a few cases. Please let me know if there's any additional testing or information that would be helpful!
```
* thread #4, stop reason = EXC_BAD_ACCESS (code=2, address=0x6ffffffff0)
frame #0: 0x00000001081da380 matterhorn`__gmpn_lshift + 176
matterhorn`:
-> 0x1081da380 <+176>: ldp x4, x5, [x1, #-0x10]
0x1081da384 <+180>: orr x10, x10, x13
0x1081da388 <+184>: orr x11, x12, x2
0x1081da38c <+188>: stp x10, x11, [x16, #-0x10]
Target 0: (matterhorn) stopped.
```
```
* thread #10, name = 'ghc_worker', stop reason = EXC_BAD_ACCESS (code=2, address=0x16bf24000)
frame #0: 0x0000000108213174 matterhorn`__gmpn_sub_n + 156
matterhorn`:
-> 0x108213174 <+156>: stp x12, x13, [x0], #0x10
0x108213178 <+160>: sub x18, x18, #0x1
0x10821317c <+164>: cbnz x18, 0x108213150 ; <+120>
0x108213180 <+168>: sbcs x12, x6, x10
Target 0: (matterhorn) stopped.
```
```
* thread #9, name = 'ghc_worker', stop reason = EXC_BAD_ACCESS (code=2, address=0x16db34000)
frame #0: 0x0000000106575f30 matterhorn`__gmpn_sqr_diag_addlsh1 + 80
matterhorn`:
-> 0x106575f30 <+80>: ldp x4, x5, [x1, #-0x10]
0x106575f34 <+84>: umulh x11, x17, x17
0x106575f38 <+88>: extr x8, x7, x6, #0x3f
0x106575f3c <+92>: stp x12, x13, [x0], #0x10
Target 0: (matterhorn) stopped.
```
```
* thread #4, stop reason = EXC_BAD_ACCESS (code=2, address=0x6ffffffff0)
frame #0: 0x0000000108cfa0a0 matterhorn`__gmpn_lshift + 176
matterhorn`:
-> 0x108cfa0a0 <+176>: ldp x4, x5, [x1, #-0x10]
0x108cfa0a4 <+180>: orr x10, x10, x13
0x108cfa0a8 <+184>: orr x11, x12, x2
0x108cfa0ac <+188>: stp x10, x11, [x16, #-0x10]
Target 0: (matterhorn) stopped.
(lldb) bt
* thread #4, stop reason = EXC_BAD_ACCESS (code=2, address=0x6ffffffff0)
* frame #0: 0x0000000108cfa0a0 matterhorn`__gmpn_lshift + 176
frame #1: 0x0000000108cee590 matterhorn`integer_gmp_mpn_lshift + 80
frame #2: 0x0000000108d2e598 matterhorn`Lc6z8_info + 52
frame #3: 0x0000000108de0584 matterhorn`schedule(initialCapability=<unavailable>, task=0x0000000109a25898) at Schedule.c:482:13 [opt]
```
```
* thread #7, name = 'ghc_worker', stop reason = EXC_BAD_ACCESS (code=2, address=0x16d550000)
frame #0: 0x0000000106acc3c4 matterhorn`__gmpn_mul_1 + 156
matterhorn`:
-> 0x106acc3c4 <+156>: stp x12, x13, [x0, #-0x10]
0x106acc3c8 <+160>: adcs x12, x8, x11
0x106acc3cc <+164>: umulh x11, x5, x3
0x106acc3d0 <+168>: mul x8, x6, x3
Target 0: (matterhorn) stopped.
(lldb) bt
* thread #7, name = 'ghc_worker', stop reason = EXC_BAD_ACCESS (code=2, address=0x16d550000)
* frame #0: 0x0000000106acc3c4 matterhorn`__gmpn_mul_1 + 156
frame #1: 0x0000000106ad3cf4 matterhorn`__gmpn_sqr_basecase + 160
frame #2: 0x0000000106ad5e4c matterhorn`__gmpn_toom2_sqr + 552
frame #3: 0x0000000106ad39e8 matterhorn`__gmpn_sqr + 112
frame #4: 0x0000000106ac175c matterhorn`__gmpn_powm + 3464
frame #5: 0x0000000106ad11a4 matterhorn`__gmpz_powm + 2260
(lldb) thread list
Process 91041 stopped
thread #1: tid = 0xaf9997, 0x000000019c7225e4 libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'ghc_worker', queue = 'com.apple.main-thread'
thread #2: tid = 0xaf99a3, 0x000000019c7223e0 libsystem_kernel.dylib`__semwait_signal + 8
thread #3: tid = 0xaf99a4, 0x000000019c727334 libsystem_kernel.dylib`poll + 8
thread #4: tid = 0xaf99a5, 0x000000019c7225e4 libsystem_kernel.dylib`__psynch_cvwait + 8
thread #5: tid = 0xaf99a6, 0x000000019c724e98 libsystem_kernel.dylib`kevent + 8, name = 'ghc_worker'
thread #6: tid = 0xaf99a7, 0x000000019c724e98 libsystem_kernel.dylib`kevent + 8, name = 'ghc_worker'
* thread #7: tid = 0xaf99a8, 0x0000000106acc3c4 matterhorn`__gmpn_mul_1 + 156, name = 'ghc_worker', stop reason = EXC_BAD_ACCESS (code=2, address=0x16d550000)
thread #8: tid = 0xaf99a9, 0x000000019c7225e4 libsystem_kernel.dylib`__psynch_cvwait + 8
thread #9: tid = 0xaf9e12, 0x000000019c7225e4 libsystem_kernel.dylib`__psynch_cvwait + 8
thread #10: tid = 0xaf9e17, 0x000000019c7225e4 libsystem_kernel.dylib`__psynch_cvwait + 8
```9.6.1Ben GamariZubinBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24135Implement Call-by-value convention via `ArgRep`/`LambdaFormInfo`2024-03-25T08:07:12ZSebastian GrafImplement Call-by-value convention via `ArgRep`/`LambdaFormInfo`## Summary
This ticket tracks a proposal to retire tag inference in favor of a mechanism integrating levity into the calling convention.
## Motivation
In #23848 we were investigating ways in which we could prevent tag inference from ...## Summary
This ticket tracks a proposal to retire tag inference in favor of a mechanism integrating levity into the calling convention.
## Motivation
In #23848 we were investigating ways in which we could prevent tag inference from generating thunks to insert field seqs on strictly used binders. The workaround to pass `-fworker-wrapper-cbv` could generally lead to regressions because of rules https://gitlab.haskell.org/ghc/ghc/-/issues/20364 and is generally an unsatisfying mechanism.
Furthermore, "Tag inference" is not some kind of analysis run with -O1, but at this point *it is an integral part of the code generation pipeline*, even with `-O0`. Compile a client module without running tag inference and you get crashes. In light of this, it should better be named `StgPrep` or some such.
## Clarification: CbV, levity and types
Note that when a function is call-by-value, that expresses a *precondition*: Callers of the function are *required* to evaluate lifted arguments before calling the function, and the callee is *permitted* to assume that the argument has been evaluated.
Evaluating a lifted argument before passing it is effectively like passing an *unlifted* pointer as argument.
We ultimately hope to make this precondition precise in STG's and Core's type system (#19530, #19767, #23890), but it is not a concern of this issue. Rather what we discuss here is necessary ground work to work around the annoyances in our current tag inference situation, because unlifted pointers are always properly tagged.
## Proposal
@simonpj and I came to the conclusion (see https://gitlab.haskell.org/ghc/ghc/-/issues/23848#note_531525) that a holistic solution would be to treat call-by-value as the calling convention it really is; as part of GHC's ABI it must be manifest in interface files through exported `LambdaFormInfo` (not `IdDetails` like the current CbV mechanism) and any client must adhere to it (-O0 or not, GHC or ... the next version of GHC). Essentially, we want to do the same for levity mismatch of arguments as we do for arity mismatches: Whenever we encounter a mismatch, generate a slow call that will do the necessary PAP'ing/eval'ing.
From my very rough understanding of everything in `StgTo*` and below, this is the minimum number of steps required to integrate call-by-value/unlifted arg reps:
1. Change `GHC.StgToCmm.ArgRep.ArgRep`: Split `P` into `L` and `U` for lifted and unlifted GCd pointers, respectively.
2. That directly prompts a change for `slowCallPattern`, which is the interface between GHC and the generic apply functions generated by `utils/genapply`.
3. Change `utils/genapply/Main.hs:ArgRep` in the same way as (1). The entry code for a `U` should simply seq the argument.
4. Find the right adjustment to `utils/genapply/Main.hs:applyTypes` and `utils/genapply/Main.hs:stackApplyTypes` that catches 99% of all call sites in reasonable space. To get things running, no change should be needed (but the resulting code will either be huge or slow). Fine-tuning the exact set of apply patterns informed by benchmarks is the bulk of the change, I think, and deserves its own section below.
5. Fill in `slowCallPattern` so that it matches `applyTypes`. Also fix other functions in `GHC.StgToCmm.ArgRep`, the most important being `toArgRep` which turns a `PrimRep` into an `ArgRep`. We must split the `BoxedRep` case in two: One for `Just Lifted` and one for `Just Unlifted`. Furthermore, it is no longer enough to look at
6. Follow references of today's `P` and see which need fixes. `GHC.StgToCmm.Layout`: `argBits` (`U` is also GCd), `stdPattern`. Also some in the ByteCode interpreter.
7. Now I'd work from `GHC.StgToCmm.Expr.cgIdApp` downwards. Specifically, we need a new `LambdaFormInfo` concept of CbV to communicate the information to `GHC.StgToCmm.Closure.getCallMethod`. The latter needs to emit a slow call not only on arity mismatch, but also when one of the args is not unlifted but goes into an unlifted parameter of the callee. Slow call will go through genapply funs IIRC which will do the proper seqs.
We can tell whether an arg is unlifted by looking at the `idDemandInfo` of the `StgArg`.
We must be able to tell whether a parameter of the callee is expected unlifted by means of its `ReEntrant :: ... -> LambdaFormInfo`.
Just as that constructor lists the callee's arity, we must augment it with the function's "CbV marks". A good place to do so would the `ArgDescr`; in fact, for usual apply patterns, the info is already present in `ArgSpec`. For the `ArgGen` case, instead of a `type Liveness = [Bool]` bitmap, we must embed `data Stuff = LiftedP | UnliftedP | Dead; type Liveness = [Stuff]` (TODO: better name).
## Effect
With these changes, we will generate a slow call for a function like this:
```
module A where
data T a = T !a
g :: T Int -> Int
g (T n) = n -- g is strict, hence expects its arg unlifted
module B where
f :: T Int -> Bool -> Int
f a True = g a -- a is not used strictly, hence it is lifted. This will generate a slow call to g
f _ False = 0
```
Compiling `A` with -O1, `g` is detected strict and expects its argument unlifted.
Compiling `B` with -O0, we see that the caller `f` is not strict in `a` (even with `-O1`) but that it passes `a` on to `g`.
Since `a` is lifted, there is an levity mismatch with the `LambdaFormInfo` of `g` (the exact info is in the imported `ArgSpec ARG_U :: ArgDescr`, presumably) -- just like an arity mismatch, this forces a slow call to `g`.
Now, tag inference would simply insert a seq prior to calling `g`, thus guaranteeing compatible unliftedness and eliminating the slow call.
~~Note that there are no thunks involved whatsoever! No #23848.~~ (Edit: This is actually untrue in case `g` is a strict DataCon worker like `T` and let bound. However there are no avoidable thunks such as in #23848.) In fact this transformation is so simple that it could be carried out in CorePrep already, or perhaps as part of `cgIdApp`. Kind of like eta expansion, but for levity (and without introducing new closures).
## Generating generic apply functions
As outlined in (5) above, we need to re-run benchmarks to find a good set of generic apply patterns.
What a generic apply function is and the process to find good candidates has been described in Section 6.2 and 8.2 of https://www.microsoft.com/en-us/research/publication/make-fast-curry-pushenter-vs-evalapply/. Perhaps it's a good idea to extend the benchmark suite beyond NoFib for this purpose, as it displays a relative poverty of unboxed and unlifted types.https://gitlab.haskell.org/ghc/ghc/-/issues/24507Unsound optimization breaks pattern matching on sum type2024-03-23T22:14:54ZStefano DebenedettiUnsound optimization breaks pattern matching on sum type## Summary
Enabling `-O2` makes a case expression pattern match pick the 7th constructor of a sum type also when called with any constructor from the 2nd to the 6th.
The following factors seem to concur in triggering this behaviour (se...## Summary
Enabling `-O2` makes a case expression pattern match pick the 7th constructor of a sum type also when called with any constructor from the 2nd to the 6th.
The following factors seem to concur in triggering this behaviour (see the Expected behaviour section below for more details):
* `-O2`
* usage of the `streamly-core` library (I could not reproduce without it)
* a strictness annotation on the type used to hold the constructor to pass to the buggy function
* splitting the code into separate modules
On the other hand, using `Debug.Trace.trace` to examine the constructor before feeding it into the case expression fixes the issue, making it a Heisenbug.
## Steps to reproduce
```
$ git clone https://github.com/demaledetti/test-bug
$ cd test-bug
$ cabal clean && cabal build --ghc-options -v > cabal.log.ko 2>&1 && for i in {A..J}; do cabal run testbug -- $i; done
parser: A
testbug: src/TestBug/Parser.hs:(15,18)-(25,34): Non-exhaustive patterns in case
parser: B
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: C
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: D
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: E
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: F
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: G
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: H
OK
parser: I
OK
parser: J
testbug: src/TestBug/Parser.hs:(15,18)-(25,34): Non-exhaustive patterns in case
```
## Expected behaviour
With `-O1`:
```
$ cabal clean && cabal build -O1 --ghc-options -v > cabal.log.ok 2>&1 && for i in {A..J}; do cabal run -O1 testbug -- $i; done
parser: A
testbug: src/TestBug/Parser.hs:(15,18)-(25,34): Non-exhaustive patterns in case
parser: B
OK
parser: C
OK
parser: D
OK
parser: E
OK
parser: F
OK
parser: G
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: H
OK
parser: I
OK
parser: J
testbug: src/TestBug/Parser.hs:(15,18)-(25,34): Non-exhaustive patterns in case
```
For other ways to get the correct behaviour without lowering the optimization level, including the ones mentioned in the Summary section above, see these comments in the source code:
```
$ grep -rnI "the bug" src/ testbug/
src/TestBug/Data.hs:12: -- simplifying it away makes the bug disappear
src/TestBug/Parser.hs:5:-- makes the bug go away (making it a Heisenbug)
src/TestBug/Parser.hs:16: -- uncommenting the next line makes the bug disappear
src/TestBug/Parser.hs:26: -- uncommenting the next line makes the bug disappear
testbug/Main.hs:13:-- makes the bug go away
```
## Environment
* GHC version used: 9.8.2
Optional:
* Operating System:
* System Architecture:
```
$ uname -a
Linux eppere 6.7.5-gentoo #1 SMP Mon Feb 19 15:51:31 CET 2024 x86_64 Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz GenuineIntel GNU/Linux
```
Logs mentioned above:
[cabal.log.ko](/uploads/5c86dcaaac0efe1a297a3534d2e6b3a4/cabal.log.ko)
[cabal.log.ok](/uploads/aa5c0a45405cbf6e9fad05b1219dcd07/cabal.log.ok)
Log of build with `-O2` but removing the strictness annotation in `Main.hs` (commenting line 14, uncommenting line 15):
[cabal.log.lazy](/uploads/b63f0ae3c422538bb04ed7b623c49c50/cabal.log.lazy)
(easier to diff vs cabal.log.ko)9.8.3Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/24553Expected and actual kinds in "Couldn't match kind" error appear identical2024-03-23T17:28:30ZJoseph C. SibleExpected and actual kinds in "Couldn't match kind" error appear identical## Summary
When a "Couldn't match kind" error occurs because of a difference in the position of a `forall.`, the expected and actual kinds printed will be identical and provide no indication of what the problem is.
## Steps to reproduc...## Summary
When a "Couldn't match kind" error occurs because of a difference in the position of a `forall.`, the expected and actual kinds printed will be identical and provide no indication of what the problem is.
## Steps to reproduce
Try to compile this code:
```
import GHC.Exts (TYPE)
type Foo :: * -> forall r. TYPE r -> *
newtype Foo m a = MkFoo ()
type Bar = Foo :: forall r. * -> TYPE r -> *
```
You'll receive the following error:
```
error: [GHC-83865]
• Expected kind ‘* -> * -> *’, but ‘Foo’ has kind ‘* -> * -> *’
• In the type ‘Foo :: forall r. * -> TYPE r -> *’
In the type declaration for ‘Bar’
```
## Expected behavior
I expect the expected kind and actual kind printed in the error to be different, specifically to indicate the difference in where the `forall.` is.
## Environment
* GHC version used: Tested on both 9.8.2 and 9.10.0.20240313
Optional:
* Operating System: Ubuntu 22.04
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/24552pattern synonyms changed semantics from 9.8 to 9.10?2024-03-23T12:12:44Zjwaldmannpattern synonyms changed semantics from 9.8 to 9.10?## Summary
For a simple program with pattern synonyms, code generated by ghc-9.10.1 (alpha-1) behaves differently (throws exception) than code from ghc-9.8.2 (no exception, which seems correct to me).
Also, the exception's name is conf...## Summary
For a simple program with pattern synonyms, code generated by ghc-9.10.1 (alpha-1) behaves differently (throws exception) than code from ghc-9.8.2 (no exception, which seems correct to me).
Also, the exception's name is confusing (mentions "lambda" but there is none)
I checked 9.10 release notes (file ghc-9.10.0.20240313/docs/users_guide/9.10.1-notes.rst) they did not mention any change w.r.t. semantics of pattern synonyms.
## Reproduce
the following (silly) example is minimized from real code
```
{-# language PatternSynonyms #-}
import Prelude hiding (Maybe, Nothing,Just)
import qualified Prelude as P
data Maybe a = Nothing_ | Just_ a
pattern Nothing :: Maybe a
pattern Nothing <- Nothing_ where Nothing = Nothing_
pattern Just :: a -> Maybe a
pattern Just x <- Just_ x where Just = Just_
main = print $ do Just x <- [Nothing, Just ()] ; return x
```
## Actual Behaviour
```
$ /opt/ghc/ghc-9.10.0.20240313/bin/runhaskell ps.hs
ps.hs: ps.hs:14:19-24: Non-exhaustive patterns in lambda
HasCallStack backtrace:
collectBacktraces, called at libraries/ghc-internal/src/GHC/Internal/Exception.hs:92:13 in ghc-internal:GHC.Internal.Exception
...
```
## Expected behavior
```
$ /opt/ghc/ghc-9.8.2/bin/runhaskell ps.hs
[()]
```9.10.1Apoorv IngleApoorv Inglehttps://gitlab.haskell.org/ghc/ghc/-/issues/18324Impredicative types and do-notation2024-03-23T04:21:47ZSimon Peyton JonesImpredicative types and do-notationThis ticket is about the interaction of Quick Look impredicativity and do-notation.
Consider these definitions
```
t :: IO (forall a. a -> a)
t = return id
p :: (forall a. a -> a) -> (Bool, Int)
p f = (f True, f 3)
-- This typechecks ...This ticket is about the interaction of Quick Look impredicativity and do-notation.
Consider these definitions
```
t :: IO (forall a. a -> a)
t = return id
p :: (forall a. a -> a) -> (Bool, Int)
p f = (f True, f 3)
-- This typechecks (with QL)
foo1 = t >>= \x -> return (p x)
-- But this does *not* type check:
foo2 = do { x <- t ; return (p x) }
```
Remember `(>>=) :: forall m a b. Monad m => m a -> (a -> m b) -> m b`. Now, `foo1` works because Quick Look can work out how to instantiate `m` and `a` from the first argument `t`. Easy.
We just need to do the same for do-notation, `foo2`. When #17582 finally lands (work in progress is !2960), this will happen automatically.Apoorv IngleApoorv Inglehttps://gitlab.haskell.org/ghc/ghc/-/issues/24566Default types vs deriving2024-03-22T13:39:10ZSylvain HenryDefault types vs deriving## Summary
In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12179#note_551772 we added the following code:
```haskell
default ()
data Maybe a = Nothing | Just a
deriving ( Eq -- ^ @since base-2.01
--, Ord -- ^ ...## Summary
In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12179#note_551772 we added the following code:
```haskell
default ()
data Maybe a = Nothing | Just a
deriving ( Eq -- ^ @since base-2.01
--, Ord -- ^ @since base-2.01
)
-- ???
-- A non-standalone instance will slurp the interface file for GHC.Num.Integer.
-- During simplifyInstanceContexts, a call to GHC.Tc.Utils.Env.tcGetDefaultTys
-- apparently sees mb_defaults = Nothing and thus tries to bring in the
-- default "default" types, including Integer. This seems wrong.
deriving instance Ord a => Ord (Maybe a) -- ^ @since base-2.01
```
Both standalone and non-standalone instance declarations should "see" the same default types (none here because of the `default ()`).
## Steps to reproduce
Reproduce with:
```haskell
{-# LANGUAGE NoImplicitPrelude #-}
module M where
import GHC.Classes
default ()
data Foo a = Nothing | Just a
deriving (Eq, Ord)
-- deriving instance Eq a => Eq (Foo a)
-- deriving instance Ord a => Ord (Foo a)
```
Build with:
```
strace -f -e trace=file ghc M.hs -fforce-recomp -fno-code 2>&1 | grep ghc-bignum
```
We use `-fno-code` because the bignum interfaces seem to be loaded during codegen.
Result with standalone deriving:
```
❯ strace -f -e trace=file ghc-9.8 M.hs -fforce-recomp -fno-code 2>&1 | grep ghc-bignum
openat(AT_FDCWD, "/home/hsyl20/.ghcup/ghc/9.8.1-alpha1/lib/ghc-9.8.0.20230727/bin/../lib/x86_64-linux-ghc-9.8.0.20230727/libHSghc-bignum-1.3-0df6-ghc9.8.0.20230727.so", O_RDONLY|O_CLOEXEC) = 3
```
Result with non-standalone deriving:
```
❯ strace -f -e trace=file ghc-9.8 M.hs -fforce-recomp -fno-code 2>&1 | grep ghc-bignum
openat(AT_FDCWD, "/home/hsyl20/.ghcup/ghc/9.8.1-alpha1/lib/ghc-9.8.0.20230727/bin/../lib/x86_64-linux-ghc-9.8.0.20230727/libHSghc-bignum-1.3-0df6-ghc9.8.0.20230727.so", O_RDONLY|O_CLOEXEC) = 3
[pid 172062] stat("/home/hsyl20/.ghcup/ghc/9.8.1-alpha1/lib/ghc-9.8.0.20230727/lib/../lib/x86_64-linux-ghc-9.8.0.20230727/ghc-bignum-1.3-0df6/GHC/Num/Integer.hi", {st_mode=S_IFREG|0644, st_size=47534, ...}) = 0
[pid 172062] openat(AT_FDCWD, "/home/hsyl20/.ghcup/ghc/9.8.1-alpha1/lib/ghc-9.8.0.20230727/lib/../lib/x86_64-linux-ghc-9.8.0.20230727/ghc-bignum-1.3-0df6/GHC/Num/Integer.hi", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 13
```
## Expected behavior
Bignum interfaces shouldn't be loaded with non-standalone deriving.
## Environment
* GHC version used: 9.6, 9.8https://gitlab.haskell.org/ghc/ghc/-/issues/24551Literal string redundantly abstracted over a type variable2024-03-22T12:12:35ZjwaldmannLiteral string redundantly abstracted over a type variable## Summary
(I have no idea what's happening, but GHC asks me to report a bug)
## Steps to reproduce
sorry, didn't have time to minimize
```
git clone https://git.imn.htwk-leipzig.de/waldmann/autotool.git
cd autotool
git submodule ini...## Summary
(I have no idea what's happening, but GHC asks me to report a bug)
## Steps to reproduce
sorry, didn't have time to minimize
```
git clone https://git.imn.htwk-leipzig.de/waldmann/autotool.git
cd autotool
git submodule init
git submodule update
curl https://ghc.gitlab.haskell.org/head.hackage/cabal.project >> cabal.project.local
cabal update
cabal build -w /opt/ghc/ghc-9.10.0.20240313/bin/ghc transport
```
## Observed behaviour
```
...
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.10.0.20240313:
corePrepPgm
Case lzy-ctx _x_r3oD :: forall {atom}. Addr#
[GblId, Unf=OtherCon []]
_x_r3oD = \ (@atom_a2ge) -> "missing"#
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:190:37 in ghc-9.10.0.20240313-inplace:GHC.Utils.Panic
pprPanic, called at compiler/GHC/CoreToStg/Prep.hs:2050:16 in ghc-9.10.0.20240313-inplace:GHC.CoreToStg.Prep
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:507:29 in ghc-9.10.0.20240313-inplace:GHC.Utils.Error
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
## Note
error does NOT happen with `-O0`, or `-O2`, but DOES appear with `-O1` (which is cabal's default?)9.10.1Sebastian GrafSebastian Grafhttps://gitlab.haskell.org/ghc/ghc/-/issues/22429MacOS ld warning: -undefined dynamic_lookup may not work with chained fixups2024-03-22T10:44:17ZBrandon ChinnMacOS ld warning: -undefined dynamic_lookup may not work with chained fixupsGetting a linker warning after upgrading to MacOS Monterey (12.6). Repro steps:
1. Create empty `Bar.hs` module (`module Bar where`)
2. Run `ghc -shared Bar.hs`
```
[1 of 1] Compiling Bar ( Bar.hs, Bar.o )
Linking a.out .....Getting a linker warning after upgrading to MacOS Monterey (12.6). Repro steps:
1. Create empty `Bar.hs` module (`module Bar where`)
2. Run `ghc -shared Bar.hs`
```
[1 of 1] Compiling Bar ( Bar.hs, Bar.o )
Linking a.out ...
ld: warning: -undefined dynamic_lookup may not work with chained fixups
```
Artifacts still seem to work, but it would be nice to resolve (or hide?) the warning.
From the man page:
```
-undefined treatment
Specifies how undefined symbols are to be treated. Options are: error, warning,
suppress, or dynamic_lookup. The default is error. Note: dynamic_lookup that
depends on lazy binding will not work with chained fixups.
```9.6.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/21680Consider migration strategy for !81422024-03-21T17:37:34ZDouglas Wilsondouglas@well-typed.comConsider migration strategy for !8142In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8142 we started adding printing to stderr when weak pointer finalizers throw unhandled exceptions.
I've just run `ghc-events` (the cli tool) built with master and am seeing:
```
Ex...In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8142 we started adding printing to stderr when weak pointer finalizers throw unhandled exceptions.
I've just run `ghc-events` (the cli tool) built with master and am seeing:
```
Exception during Weak# finalization (ignored): <stdout>: hFlush: resource vanished (Broken pipe)
```
intermittently when I "Ctrl-C" the ghc-events process.
It's clear the new behaviour is correct, and is highlighting a previously invisible error.
We should consider whether we want to impose this new behaviour on haskell programs. I imagine it would be very annoying to have my program begin to emit this to my users when my program has been working fine for years. Users will reasonably ask for a way to silence this.9.6.1sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/21336File flush failures during program deinitialization aren't indicated2024-03-21T17:37:33ZBrandon S. Allberyallbery.b@gmail.comFile flush failures during program deinitialization aren't indicated## Summary
If a flush/close of a `Handle` fails during RTS deinitialization, there is no indication of a failure. Even if `stderr` has already been closed, at minimum the exit status can be set to indicate a failure.
## Steps to reprod...## Summary
If a flush/close of a `Handle` fails during RTS deinitialization, there is no indication of a failure. Even if `stderr` has already been closed, at minimum the exit status can be set to indicate a failure.
## Steps to reproduce
The program
```
main = putStrLn "Hello, world!"
```
invoked as
```
./hello >/dev/full
```
will correctly report
```
<stdout>: commitBuffer: resource exhausted (No space left on device)
```
if run from `ghci` or `runghc`, which default `stdout` to `LineBuffering`. In a compiled program, `stdout` is set to `BlockBuffering Nothing` and the final `hFlush` is done by the RTS at a time when no exceptions can be thrown and `stderr` may already be closed, so nothing is reported and the program exits with status 0 (no error).
I suspect the same thing may happen with a `Handle` that is garbage collected, since it may be unsafe to throw an exception at that point.
## Expected behavior
Preferably report the same exception as with `ghci` or `runghc`, but at minimum report a non-zero exit status.
## Environment
* GHC version used: 8.10.7 and 9.2.1
Optional:
* Operating System: Linux (Ubuntu 20.04)
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/24567Missing preamble from 9.10 release notes2024-03-21T16:32:24ZTeo CamarasuMissing preamble from 9.10 release notes9.8 has a paragraph that goes:
```
The significant changes to the various parts of the compiler are listed in the
following sections. See the `migration guide
<https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.8>`_ on the GHC Wiki
f...9.8 has a paragraph that goes:
```
The significant changes to the various parts of the compiler are listed in the
following sections. See the `migration guide
<https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.8>`_ on the GHC Wiki
for specific guidance on migrating programs to this release.
```
It would be good to have something similar for 9.10https://gitlab.haskell.org/ghc/ghc/-/issues/24545GHC 9.10.1-alpha1 .tar.gz download does not extract properly2024-03-21T15:50:12ZRyan ScottGHC 9.10.1-alpha1 .tar.gz download does not extract properlyAfter downloading https://downloads.haskell.org/ghc/9.10.1-alpha1/ghc-9.10.0.20240313-x86_64-fedora33-linux.tar.gz, I attempted to extract it, only to be thwarted by this error:
```
$ tar -xvf ghc-9.10.0.20240313-x86_64-fedora33-linux.t...After downloading https://downloads.haskell.org/ghc/9.10.1-alpha1/ghc-9.10.0.20240313-x86_64-fedora33-linux.tar.gz, I attempted to extract it, only to be thwarted by this error:
```
$ tar -xvf ghc-9.10.0.20240313-x86_64-fedora33-linux.tar.gz
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
```
Curiously, this only affects the `.tar.gz` download, as the [`.tar.xz` version](https://downloads.haskell.org/ghc/9.10.1-alpha1/ghc-9.10.0.20240313-x86_64-fedora33-linux.tar.xz) extracts without issue. I haven't tried any other variants of GHC 9.10.1-alpha1.9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/24525Windows bindists are quite broken2024-03-20T10:46:50ZBen GamariWindows bindists are quite brokenmingw32 binary distributions are currently quite broken:
```bash
$ wget https://gitlab.haskell.org/ghc/ghc/-/jobs/1805153/artifacts/raw/ghc-x86_64-windows-release.tar.xz
$ tar -xf ../ghc-x86_64-windows-release.tar.xz
$ cd ghc-9.10.0.2024...mingw32 binary distributions are currently quite broken:
```bash
$ wget https://gitlab.haskell.org/ghc/ghc/-/jobs/1805153/artifacts/raw/ghc-x86_64-windows-release.tar.xz
$ tar -xf ../ghc-x86_64-windows-release.tar.xz
$ cd ghc-9.10.0.20240310-x86_64-unknown-mingw32/
$ bin/ghc --info
ghc-9.10.0.20240310.exe: could not detect mingw toolchain in the following paths: ["C:\\msys64\\home\\ben\\tmp\\ghc-9.10.0.20240310-x86_64-unknown-mingw32\\lib\\..\\mingw","C:\\msys64\\home\\ben\\tmp\\ghc-9.10.0.20240310-x86_64-unknown-mingw32\\lib\\..\\..\\mingw","C:\\msys64\\home\\ben\\tmp\\ghc-9.10.0.20240310-x86_64-unknown-mingw32\\lib\\..\\..\\..\\mingw"]
```
It appears that many things that should be in the root of the binary distribution are instead now in `lib` (including `mingw/`):
```bash
$ ls lib/
a.exe config.guess config.status default.host.target.in doc ghc-usage.txt install-sh llvm-targets mk README x86_64-windows-ghc-9.10.0.20240310
bin config.log config.sub default.target docs-utils html latex Makefile package.conf.d settings
build.mk config.mk configure default.target.ghc-toolchain ghc-interp.js include lib manpage post-link.mjs template-hsc.h
completion config.mk.in default.host.target default.target.in ghci-usage.txt INSTALL llvm-passes mingw prelude.js wrappers
```
Moving `lib/mingw` to the root of the distribution appears to be sufficient to make the compiler functional.9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/24265On Windows, is GHC 9.4.8 passing paths with spaces to `clang.exe` without enc...2024-03-20T09:13:51ZMike PilgremOn Windows, is GHC 9.4.8 passing paths with spaces to `clang.exe` without enclosing quotes?## Summary
See Stack [issue #6380](https://github.com/commercialhaskell/stack/issues/6380). A Windows user, with user name `Peter Job` is experiencing an error with GHC 9.4.8 which is (extracts):
~~~text
2023-12-15 21:57:28.661476: [de...## Summary
See Stack [issue #6380](https://github.com/commercialhaskell/stack/issues/6380). A Windows user, with user name `Peter Job` is experiencing an error with GHC 9.4.8 which is (extracts):
~~~text
2023-12-15 21:57:28.661476: [debug] Run process within C:\Users\Peter Job\AppData\Local\Temp\stack-3c77eb37934e8913\: C:\Users\Peter Job\AppData\Local\Programs\stack\x86_64-windows\ghc-9.4.8\bin\ghc-9.4.8.exe ...
clang: error: no such file or directory: 'Job\AppData\Local\Programs\stack\x86_64-windows\ghc-9.4.8\lib\../mingw/include'
C:\Users\Peter Job\AppData\Roaming\stack\setup-exe-src\setup-shim-9p6GVs8J.hs:1:1: error:
`clang.exe' failed in phase `C pre-processor'. (Exit code: 1)
|
1 | {-# LANGUAGE CPP #-}
| ^
~~~
It looks to me likely that GHC has passed a path to `clang.exe` (a) that contains a space and (b) has not been surrounded with quotation marks. (I am assuming that `clang.exe` can handle paths with spaces as long as they are surrounded with quotation marks; I do not know that for a fact.)
## Environment
* GHC version used: 9.4.8
Optional:
* Operating System: Windows 11
* System Architecture: x86_649.10.1ZubinHannes SiebenhandlZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24516Thunks in `IfaceTyCon` retain a large amount of memory2024-03-20T09:09:45ZHannes SiebenhandlThunks in `IfaceTyCon` retain a large amount of memory## Summary
In heap analysis, the `IfaceTyCon` constructor in `mi_extra_decls` retains a thunk to `IfaceTyConInfo`. This added indirection seems to defeat sharing for the two most common instances of `IfaceTyConInfo` which aims to reduce...## Summary
In heap analysis, the `IfaceTyCon` constructor in `mi_extra_decls` retains a thunk to `IfaceTyConInfo`. This added indirection seems to defeat sharing for the two most common instances of `IfaceTyConInfo` which aims to reduce memory usage quite considerably.
All numbers and pictures have been obtained running `ghci -fbyte-code-and-object-code` using `ghc-debug` and `-hT` profiling. GHC itself has been compiled with the flavour `perf+ipe`.
In a two-level census heap traversal, we have the following lines (just an excerpt):
```
key;total;count;max;avg
ghc-9.9-inplace:GHC.Iface.Type:IfaceTyConInfo[ghc-9.9-inplace:Language.Haskell.Syntax.Type:NotPromoted,ghc-9.9-inplace:GHC.Iface.Type:IfaceNormalTyCon];141466584;5894441;24;24.0
ghc-9.9-inplace:GHC.Iface.Type:IfaceTyConInfo[ghc-9.9-inplace:Language.Haskell.Syntax.Type:IsPromoted,ghc-9.9-inplace:GHC.Iface.Type:IfaceNormalTyCon];64949568;2706232;24;24.0
```
Which hints that we have 5894441 occurrences of `IfaceTyConInfo NotPromoted IfaceNormalTyCon` and 2706232 of `IfaceTyConInfo IsPromoted IfaceNormalTyCon` on the heap.
Further, we can observe the thunk existing in `ghc-debug-brick`.
![image](/uploads/a33a234c35f4dba307143a9dc6799c23/image.png)
For reference, this the space behaviour of loading agda into ghci, where the bytecode has been serialised into the interface file:
![image](/uploads/014ee4373bbfc7c5b7f892312cf51929/image.png)
and `ghci +RTS -s -i0.1`
```
5,839,944,688 bytes allocated in the heap
7,203,898,048 bytes copied during GC
1,963,423,488 bytes maximum residency (12 sample(s))
14,932,224 bytes maximum slop
3786 MiB total memory in use (0 MiB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 275 colls, 0 par 3.503s 3.514s 0.0128s 0.2590s
Gen 1 12 colls, 0 par 4.976s 4.995s 0.4162s 2.4095s
TASKS: 6 (1 bound, 5 peak workers (5 total), using -N1)
SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
INIT time 0.009s ( 0.009s elapsed)
MUT time 3.265s ( 5.421s elapsed)
GC time 8.479s ( 8.509s elapsed)
EXIT time 0.001s ( 0.000s elapsed)
Total time 11.754s ( 13.940s elapsed)
Alloc rate 1,788,578,842 bytes per MUT second
Productivity 27.8% of total user, 38.9% of total elapsed
```
While it is a little bit unclear why only this field is a thunk, adding the bangs to `IfaceTyCon`
```haskell
data IfaceTyCon = IfaceTyCon { ifaceTyConName :: !IfExtName
, ifaceTyConInfo :: !IfaceTyConInfo }
```
gives the following results for the two level census:
```
key;total;count;max;avg
ghc-9.9-inplace:GHC.Iface.Type:IfaceTyConInfo[ghc-9.9-inplace:Language.Haskell.Syntax.Type:IsPromoted,ghc-9.9-inplace:GHC.Iface.Type:IfaceNormalTyCon];24;1;24;24.0
ghc-9.9-inplace:GHC.Iface.Type:IfaceTyConInfo[ghc-9.9-inplace:Language.Haskell.Syntax.Type:NotPromoted,ghc-9.9-inplace:GHC.Iface.Type:IfaceNormalTyCon];24;1;24;24.0
```
This indicates that we now have only exactly one instance for the two common cases.
and more importantly:
![image](/uploads/0ced1a2bf8318273600e426d734574f5/image.png)
``ghci +RTS -s -i0.1`` output:
```
6,114,619,032 bytes allocated in the heap
6,458,988,440 bytes copied during GC
1,330,672,456 bytes maximum residency (12 sample(s))
10,910,904 bytes maximum slop
2689 MiB total memory in use (0 MiB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 275 colls, 0 par 3.933s 3.945s 0.0143s 0.2844s
Gen 1 12 colls, 0 par 3.840s 3.854s 0.3212s 1.6629s
TASKS: 6 (1 bound, 5 peak workers (5 total), using -N1)
SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
INIT time 0.010s ( 0.010s elapsed)
MUT time 3.235s ( 3.728s elapsed)
GC time 7.773s ( 7.799s elapsed)
EXIT time 0.000s ( 0.000s elapsed)
Total time 11.018s ( 11.537s elapsed)
Alloc rate 1,890,406,998 bytes per MUT second
Productivity 29.4% of total user, 32.3% of total elapsed
```
## Environment
* GHC version used: HEAD
Optional:
* Operating System: Arch Linux
* System Architecture: x86_64Hannes SiebenhandlHannes Siebenhandlhttps://gitlab.haskell.org/ghc/ghc/-/issues/24530Remove duplication of `IfaceTyConInfo` when writing bytecode to .hi files2024-03-20T09:09:08ZHannes SiebenhandlRemove duplication of `IfaceTyConInfo` when writing bytecode to .hi filesIn heap analysis, we noticed there is a high amount of duplication of `IfaceTyConInfo` constructors when we persist `mi_extra_decls` to the respective `ModIface`. Note, this duplication only occurs when you write `mi_extra_decls` to the ...In heap analysis, we noticed there is a high amount of duplication of `IfaceTyConInfo` constructors when we persist `mi_extra_decls` to the respective `ModIface`. Note, this duplication only occurs when you write `mi_extra_decls` to the interface files.
On the agda codebase, with a ghc compiled with `--flavour=perf+ipe`, we gathered the following numbers with ghc-debug (census2LevelClosureType):
```
key; total; count; max; avg
ghc-9.9-inplace:GHC.Iface.Type:IfaceTyCon[ghc-9.9-inplace:GHC.Types.Name:Name,ghc-9.9-inplace:GHC.Iface.Type:IfaceTyConInfo]:206635176:8609799:24:24.0
ghc-9.9-inplace:GHC.Iface.Type:IfaceTyConInfo[ghc-9.9-inplace:Language.Haskell.Syntax.Type:NotPromoted,ghc-9.9-inplace:GHC.Iface.Type:IfaceNormalTyCon];141466584;5894441;24;24.0
ghc-9.9-inplace:GHC.Iface.Type:IfaceTyConInfo[ghc-9.9-inplace:Language.Haskell.Syntax.Type:IsPromoted,ghc-9.9-inplace:GHC.Iface.Type:IfaceNormalTyCon];64949568;2706232;24;24.0
```
We omitted several other lines to focus on the duplication of `IfaceTyConInfo`.
There are 5894441 occurrences of `IfaceTyConInfo NotPromoted IfaceNormalTyCon` and 2706232 instances of `IfaceTyConInfo IsPromoted IfaceNormalTyCon`, resulting in an 200MB overhead.
Note, this duplication does not occur if the `mi_extra_decls` are read from `ModIface`. However, in #24516, we identify a different issue with `IfaceTyConInfo`.Hannes SiebenhandlHannes Siebenhandlhttps://gitlab.haskell.org/ghc/ghc/-/issues/23942Untracked implicit dependencies on GHC.Num.BigNat2024-03-19T19:52:38ZMatthew Cravenclyring@gmail.comUntracked implicit dependencies on GHC.Num.BigNat## Summary
Occasionally one of my local builds fails with an error message like this one:
<details>
```
ghc: panic! (the 'impossible' happened)
GHC version 9.9.20230906:
lookupGlobal
ErrorWithoutFlag
Failed to load int...## Summary
Occasionally one of my local builds fails with an error message like this one:
<details>
```
ghc: panic! (the 'impossible' happened)
GHC version 9.9.20230906:
lookupGlobal
ErrorWithoutFlag
Failed to load interface for ‘GHC.Num.BigNat’.
There are files missing in the ‘ghc-bignum-1.3’ package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:186:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Tc/Utils/Env.hs:154:18 in ghc:GHC.Tc.Utils.Env
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:511:29 in ghc:GHC.Utils.Error
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
</details>
At first report, the failing command was always building `GHC.Utils.Containers.Internal.StrictPair`. But since then, some other modules have become problematic, including `base:GHC.IO.Encoding.Iconv`, `Data.Sum.Experimental`, and `Data.Tuple.Experimental`.
## Steps to reproduce
Check out a clean ghc master. Boot, configure, then run `hadrian/build _build/stage1/compiler/build/GHC/Utils/Containers/Internal/StrictPair.o`.
This will fail with a smaller "Failed to load interface" message, mentioning `GHC.Tuple.Prim` instead of `GHC.Num.BigNat`.
## Diagnosis
Whenever GHC compiles a module, it tries to read the interface file for `ghc-bignum:GHC.Num.BigNat` so that it can use `bigNatFromWordList#` to generate code for any bigint literals the module may contain. It does this regardless of whether the module actually contains any such literals; only modules in the packages `ghc-prim` and `ghc-bignum` do not implicitly depend on `ghc-bignum:GHC.Num.BigNat`. The relevant compiler code is [here](https://gitlab.haskell.org/ghc/ghc/-/blob/9b74845f740785744ea5a22e2b0677d1bab2a92c/compiler/GHC/CoreToStg/Prep.hs?page=3#L2463). (This mechanism is an annoying hack, working around the fact that we do not currently have `ByteArray#` literals in Stg.)
The [`Note [Depend on GHC.Num.Integer]` in `GHC.Internal.Base`](https://gitlab.haskell.org/ghc/ghc/-/blob/9b74845f740785744ea5a22e2b0677d1bab2a92c/libraries/ghc-internal/src/GHC/Internal/Base.hs#L351) describes the situation as well, and suggests that boot library modules should generally import `GHC.Internal.Base` or `Prelude` to avoid these build order problems. And that's a fine temporary workaround! But enforcement is spotty, especially since the build system problems from untracked dependencies tend to be intermittent. It would be much better to either make hadrian+ghc aware of this implicit dependency or to remove the need for this implicit dependency, so that GHC and boot library developers to add them manually.
(Of course, better still would be getting proper support for `ByteArray#` literals! Then we could remove the hacky implicit dependency entirely.)
There are a couple of other related untracked implicit dependencies; see also #24520.9.8.2Matthew Cravenclyring@gmail.comMatthew Cravenclyring@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/24146Constraint could not be deduced, although it is there GHC-39999 (GHC-9.8.1)2024-03-19T19:51:16ZLemmingConstraint could not be deduced, although it is there GHC-39999 (GHC-9.8.1)## Summary
The GHC error reads:
~~~~
src/LLVM/DSL/Expression/Vector.hs:101:19: error: [GHC-39999]
• Could not deduce ‘LLVM.Positive n’
arising from a use of ‘MultiValueVec.take’
from the context: (LLVM.Positive n, LLV...## Summary
The GHC error reads:
~~~~
src/LLVM/DSL/Expression/Vector.hs:101:19: error: [GHC-39999]
• Could not deduce ‘LLVM.Positive n’
arising from a use of ‘MultiValueVec.take’
from the context: (LLVM.Positive n, LLVM.Positive m,
MultiVector.Select a)
~~~~
## Steps to reproduce
~~~~
$ cabal unpack llvm-dsl-0.1.1
$ cd llvm-dsl-0.1.1
llvm-dsl-0.1.1$ nix-shell -p llvmPackages_16.libllvm gmp
[nix-shell:llvm-dsl-0.1.1]$ PATH=/usr/local/ghc/9.8.1/bin:$PATH cabal-3.10 build
~~~~
I need to specify "gmp" for the `nix-shell`, maybe you do not need that.
I can try to minimize that example, but maybe you already have an idea what the problem might be.
## Environment
* GHC version used: 9.8.1
* Operating System: GNU-Linux
* System Architecture: amd649.8.3