GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-02-27T15:58:39Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24456Exception when reading interface files2024-02-27T15:58:39ZArtin Ghasivandghasivand.artin@gmail.comException when reading interface files![Screenshot 2024-02-20 at 11.46.15 at night.jpg](/uploads/f360bec23daa21e30789471dc10459aa/Screenshot_2024-02-20_at_11.46.15_at_night.jpg)
I did a `cabal build` in one of my projects, and then I encountered this error. `cabal clean && ...![Screenshot 2024-02-20 at 11.46.15 at night.jpg](/uploads/f360bec23daa21e30789471dc10459aa/Screenshot_2024-02-20_at_11.46.15_at_night.jpg)
I did a `cabal build` in one of my projects, and then I encountered this error. `cabal clean && cabal build` fixed the issue.
GHC version: 9.8.1
Operating System: macOS 14.3.1
System Architecture: Armhttps://gitlab.haskell.org/ghc/ghc/-/issues/24449T23540 is fragile on i3862024-03-25T19:13:15ZCheng ShaoT23540 is fragile on i386Over the past few weeks, T23540 has been fragile on i386, failing on multiple MRs and relevant marge pipelines. An incomplete list of victims:
- https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11530
- https://gitlab.haskell.org/ghc/...Over the past few weeks, T23540 has been fragile on i386, failing on multiple MRs and relevant marge pipelines. An incomplete list of victims:
- https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11530
- https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11973
- https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11983
It is unclear at this point why T23540 worked on i386 in the past but starts failing only on i386 when you change some ghc frontend internals. It may be related to the unique fragility again (another instance of #24261), and while 615eb855416ce536e02ed935ecc5a6f25519ae16 was sufficient to prevent T23540 regression on !11530 !11973, it wasn't sufficient to prevent the error from surfacing in !11983.
This issue tracks the T23540 fragility on i386. To avoid blocking work on other fronts, while we look into it further, I'll land a patch that marks it fragile.https://gitlab.haskell.org/ghc/ghc/-/issues/24445Programs built with certain ghc flags, and run with certain RTS flags segfaul...2024-02-21T13:53:40ZAndreas KlebingerPrograms built with certain ghc flags, and run with certain RTS flags segfault immediately on startup.
## Steps to reproduce
```
echo "main = print 42" >> HelloWorld.hs
/opt/ghc-9.8.1/bin/ghc HelloWorld.hs -O -debug -threaded -rtsopts
./HelloWorld +RTS -N2 -l -Ds
Segmentation fault (core dumped)
```
## Environment
* GHC version used:...
## Steps to reproduce
```
echo "main = print 42" >> HelloWorld.hs
/opt/ghc-9.8.1/bin/ghc HelloWorld.hs -O -debug -threaded -rtsopts
./HelloWorld +RTS -N2 -l -Ds
Segmentation fault (core dumped)
```
## Environment
* GHC version used: 9.8/HEAD, works in 9.6
Optional:
* Operating System:
* System Architecture:Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/24435Out of range index error when bytecode generation with profiled interpreter2024-02-15T17:10:39ZIan-Woo KimOut of range index error when bytecode generation with profiled interpreter## Summary
When using profiled_ghc flavoured GHC for a repl session for a big private project, I encountered this out of array index error when interpreting some modules:
```
ghci> :load (...)
[... of ...] Compiling ... ( src/....hs, in...## Summary
When using profiled_ghc flavoured GHC for a repl session for a big private project, I encountered this out of array index error when interpreting some modules:
```
ghci> :load (...)
[... of ...] Compiling ... ( src/....hs, interpreted )
<no location info>: error:
Ix{Int}.index: Index (52) out of range ((0,39))
```
Fortunately, I could patch `indexError` to show the stack trace in profiled mode:
```
<no location info>: error:
Ix{Int}.index: Index (52) out of range ((0,39))
CallStack (from HasCallStack):
error, called at libraries/base/src/GHC/Ix.hs:169:5 in base:GHC.Ix
CallStack (from -prof):
GHC.Stack.CCS.currentCallStack1 (<no location info>)
GHC.Stack.CCS.currentCallStack (libraries/base/src/GHC/Stack/CCS.hsc:126:1-16)
GHC.Exception.errorCallWithCallStackException (libraries/base/src/GHC/Exception.hs:102:1-31)
GHC.Err.error (libraries/base/src/GHC/Err.hs:36:1-5)
GHC.Ix.$w$sindexError (libraries/base/src/GHC/Ix.hs:168:1-10)
GHC.StgToByteCode.lvl295 (<no location info>)
GHC.StgToByteCode.schemeER_wrk (compiler/GHC/StgToByteCode.hs:(387,1)-(409,40))
GHC.StgToByteCode.thenBc (compiler/GHC/StgToByteCode.hs:(2210,1)-(2214,17))
GHC.StgToByteCode.$fApplicativeBcM7 (<no location info>)
GHC.StgToByteCode.schemeR_wrk (compiler/GHC/StgToByteCode.hs:(358,1)-(382,60))
GHC.StgToByteCode.schemeR (compiler/GHC/StgToByteCode.hs:(341,1)-(342,41))
GHC.StgToByteCode.$wschemeR (compiler/GHC/StgToByteCode.hs:341:1-7)
GHC.StgToByteCode.schemeTopBind (compiler/GHC/StgToByteCode.hs:(306,1)-(322,55))
GHC.StgToByteCode.c (<no location info>)
GHC.StgToByteCode.go11 (<no location info>)
GHC.StgToByteCode.runBc (compiler/GHC/StgToByteCode.hs:(2206,1)-(2207,63))
GHC.Utils.Error.$w$swithTiming' (<no location info>)
GHC.StgToByteCode.byteCodeGen (compiler/GHC/StgToByteCode.hs:(105,1)-(150,38))
GHC.StgToByteCode.byteCodeGen1 (<no location info>)
GHC.Driver.Main.hscInteractive (compiler/GHC/Driver/Main.hs:(1963,1)-(2004,49))
GHC.Driver.Main.generateByteCode2 (<no location info>)
GHC.Driver.Main.generateByteCode (compiler/GHC/Driver/Main.hs:(2010,1)-(2020,32))
GHC.Driver.Main.generateByteCode1 (<no location info>)
GHC.Driver.Main.generateFreshByteCode (compiler/GHC/Driver/Main.hs:(2027,1)-(2031,17))
GHC.Driver.Main.generateFreshByteCode1 (<no location info>)
GHC.Driver.Pipeline.Execute.$wrunHscBackendPhase (<no location info>)
GHC.Driver.Pipeline.Execute.runHscBackendPhase1 (<no location info>)
GHC.Driver.Pipeline.Execute.runPhase1 (<no location info>)
GHC.Driver.Pipeline.$w$shscGenBackendPipeline (<no location info>)
GHC.Driver.Pipeline.fullPipeline2 (<no location info>)
GHC.Driver.Pipeline.$w$shscPipeline (<no location info>)
GHC.Driver.Pipeline.$wcompileOne' (<no location info>)
GHC.Driver.Make.upsweep_mod (compiler/GHC/Driver/Make.hs:(1303,1)-(1315,12))
GHC.Driver.Make.executeCompileNode.\ (compiler/GHC/Driver/Make.hs:(2518,81)-(2531,16))
GHC.Driver.Make.withLoggerHsc.\ (compiler/GHC/Driver/Make.hs:(2481,35)-(2485,17))
GHC.Driver.Make.runSeqPipelines.env.\ (compiler/GHC/Driver/Make.hs:2871:44-47)
GHC.Driver.Make.runSeqPipelines.env (compiler/GHC/Driver/Make.hs:(2870,7)-(2875,21))
GHC.Driver.Make.lvl83 (<no location info>)
GHC.Driver.Make.withLoggerHsc (compiler/GHC/Driver/Make.hs:(2480,1)-(2485,17))
GHC.Driver.Make.executeCompileNode (compiler/GHC/Driver/Make.hs:(2515,1)-(2540,35))
GHC.Driver.Make.interpretBuildPlan.buildSingleModule.build_action (compiler/GHC/Driver/Make.hs:(1137,11)-(1161,42))
GHC.Driver.Make.interpretBuildPlan.buildSingleModule (compiler/GHC/Driver/Make.hs:(1127,5)-(1167,49))
GHC.Driver.Make.interpretBuildPlan.buildLoop (compiler/GHC/Driver/Make.hs:(1103,5)-(1121,50))
GHC.Driver.Make.interpretBuildPlan (compiler/GHC/Driver/Make.hs:(1085,1)-(1240,73))
GHC.Driver.Make.withLocalTmpFS.\ (compiler/GHC/Driver/Make.hs:2949:54-101)
Control.Monad.Catch.$fMonadMaskMaybeT_$cgeneralBracket (libraries/exceptions/src/Control/Monad/Catch.hs:659:3-16)
GHC.Driver.Make.withLocalTmpFS (compiler/GHC/Driver/Make.hs:(2938,1)-(2949,101))
GHC.Driver.Make.runLoop.run_pipeline (compiler/GHC/Driver/Make.hs:2980:7-51)
GHC.Driver.Make.runLoop.\ (compiler/GHC/Driver/Make.hs:(2972,30)-(2975,33))
GHC.Driver.Make.runAllPipelines.spawn_actions.\.\ (compiler/GHC/Driver/Make.hs:2957:78-86)
GHC.Driver.Make.runLoop (compiler/GHC/Driver/Make.hs:(2969,1)-(2980,51))
GHC.Driver.Make.$srunLoop (<no location info>)
GHC.Driver.Make.runAllPipelines.spawn_actions.\ (compiler/GHC/Driver/Make.hs:2957:55-96)
GHC.Driver.Make.runAllPipelines.spawn_actions (compiler/GHC/Driver/Make.hs:(2956,7)-(2958,46))
GHC.Driver.Make.runAllPipelines (compiler/GHC/Driver/Make.hs:(2953,1)-(2964,29))
GHC.Driver.Make.runAllPipelines (<no location info>)
GHC.Driver.Make.runSeqPipelines (compiler/GHC/Driver/Make.hs:(2869,1)-(2876,61))
GHC.Driver.Make.runPipelines (compiler/GHC/Driver/Make.hs:(2862,1)-(2866,79))
GHC.Driver.Make.upsweep (compiler/GHC/Driver/Make.hs:(1256,1)-(1272,42))
Control.Monad.IO.Class.liftIO (libraries/base/src/Control/Monad/IO/Class.hs:66:5-25)
GHCi.UI.Monad.$fApplicativeGHCi4 (<no location info>)
GHC.Base.<*> (libraries/base/src/GHC/Base.hs:841:5-37)
GHC.Driver.Make.load' (compiler/GHC/Driver/Make.hs:(690,1)-(781,31))
GHC.Driver.Make.load' (compiler/GHC/Driver/Make.hs:690:1-5)
GHCi.UI.Monad.$fMonadGHCi2 (<no location info>)
GHC.Driver.Make.loadWithCache (compiler/GHC/Driver/Make.hs:(494,1)-(500,51))
GHC.Driver.Make.loadWithCache (compiler/GHC/Driver/Make.hs:494:1-13)
GHCi.UI.$strySuccess (<no location info>)
GHCi.UI.lvl819 (<no location info>)
Control.Monad.Catch.$w$cgeneralBracket1 (<no location info>)
Control.Monad.Catch.$fMonadMaskIO1 (<no location info>)
Control.Monad.Catch.$fMonadMaskReaderT1 (<no location info>)
GHC.Driver.Monad.$fMonadMaskGhc1 (<no location info>)
Control.Monad.Catch.generalBracket (libraries/exceptions/src/Control/Monad/Catch.hs:(342,3)-(350,15))
Control.Monad.Catch.bracket (libraries/exceptions/src/Control/Monad/Catch.hs:890:1-7)
Control.Monad.Catch.finally (libraries/exceptions/src/Control/Monad/Catch.hs:902:1-7)
GHC.withCleanupSession (compiler/GHC.hs:(531,1)-(542,51))
GHC.Driver.Monad.$fMonadGhc_$s$fMonadReaderT_$c>>= (<no location info>)
GHC.Base.>>= (libraries/base/src/GHC/Base.hs:1031:5-55)
GHC.Utils.Panic.withSignalHandlers (compiler/GHC/Utils/Panic.hs:241:1-18)
GHC.runGhc (compiler/GHC.hs:(506,1)-(511,26))
GHC.runGhc1 (<no location info>)
Main.main2 (<no location info>)
GHC.IO.catch1 (<no location info>)
Control.Monad.Catch.$fMonadCatchIO1 (<no location info>)
Control.Monad.Catch.catch (libraries/exceptions/src/Control/Monad/Catch.hs:201:3-66)
GHC.defaultErrorHandler (compiler/GHC.hs:(443,1)-(478,7))
GHC.$wdefaultErrorHandler (compiler/GHC.hs:443:1-19)
Main.main1 (<no location info>)
GHC.TopHandler.runMainIO1 (<no location info>)
Main.main3 (<no location info>)
Main.main (ghc/Main.hs:117:1-4)
```
so the bug is here: GHC.StgToByteCode.schemeER_wrk (compiler/GHC/StgToByteCode.hs:(387,1)-(409,40))
https://gitlab.haskell.org/wavewave/ghc/-/blob/T24435/compiler/GHC/StgToByteCode.hs?ref_type=heads#L405
`tick_no` is out of range.
## Environment
* GHC version used: a custom GHC for prof+dyn flavour (i.e `--flavour=perf+profiled_ghc` ). https://gitlab.haskell.org/wavewave/ghc/-/tree/wavewave/ghc_p_dyn?ref_type=heads
it's based on GHC 9.9.20240131
* Operating System: macOS 14.3, Ubuntu 23.10
* System Architecture: Apple M1 Max, x86_64 linuxhttps://gitlab.haskell.org/ghc/ghc/-/issues/24428Check that GHC.Types.Builtin.Names builds unique Uniques2024-02-13T15:33:51ZSebastian GrafCheck that GHC.Types.Builtin.Names builds unique UniquesI was wary of duplicate occurrences of the same decimal number in GHC.Types.Builtin.Names, so I let ChatGPT help me in defining the following useful `awk` script:
```sh
$ awk '{
# Iterate over each field
for (i=1; i<=NF; i++) {
...I was wary of duplicate occurrences of the same decimal number in GHC.Types.Builtin.Names, so I let ChatGPT help me in defining the following useful `awk` script:
```sh
$ awk '{
# Iterate over each field
for (i=1; i<=NF; i++) {
# If the field is a decimal number, add it to the count
if ($i ~ /^[0-9]+$/) {
count[$(i-1)][$i]++
}
}
}
END {
# Print the decimal numbers and their counts
for (s in count) {
for (num in count[s]) {
if (count[s][num] > 1) { print s, num, count[s][num] }
}
}
}' compiler/GHC/Builtin/Names.hs
```
This will print out duplicate calls of the the form `mkPreludeMiscIdUnique 135`, e.g.,
```
mkPreludeMiscIdUnique 135 2
```
The last number is the number of occurrences. Perhaps that's helpful to someone or even worth a test in CI.https://gitlab.haskell.org/ghc/ghc/-/issues/24423Sporadic segfaults at pustCostCentre with prof+dyn GHC2024-02-28T00:32:14ZIan-Woo KimSporadic segfaults at pustCostCentre with prof+dyn GHC## Summary
On an experimental branch: https://gitlab.haskell.org/wavewave/ghc/-/tree/wavewave/ghc_p_dyn?ref_type=heads (both GHC and Cabal modified)
I am testing `profiled_ghc` flavour without `no_dynamic_ghc`, i.e. GHC with `p_dyn` fl...## Summary
On an experimental branch: https://gitlab.haskell.org/wavewave/ghc/-/tree/wavewave/ghc_p_dyn?ref_type=heads (both GHC and Cabal modified)
I am testing `profiled_ghc` flavour without `no_dynamic_ghc`, i.e. GHC with `p_dyn` flavour. and it was successful in building a private mega-project.
But sometimes, sporadically, segfaults happened with the following backtrace (from macOS diagnostics report). Until now, I experienced this only with `-j` option on, so it's probably a concurrency bug.
Note: The change made in the experimental branch is mainly about building and linking, and RTS is as is except GHC built with both profiling and dynamic on.
```
...
Thread 13 Crashed:: ghc_worker
0 ??? 0x103a7186c pushCostCentre + 56
1 ??? 0x103a7c8b4 schedule + 1164
2 ??? 0x103a7c8b4 schedule + 1164
3 libsystem_pthread.dylib 0x18be2ce3c thread_start + 8
...
Thread 13 crashed with ARM Thread State (64-bit):
x0: 0x00000070c576f800 x1: 0x000000010c0b74e0 x2: 0x0000007130520120 x3: 0x0000000000000000
x4: 0x0000000000000000 x5: 0x00000000000000a0 x6: 0x0000000000000000 x7: 0x0000007026f1e888
x8: 0x0000000000617265 x9: 0x0000000000000000 x10: 0x000000000000000a x11: 0x0000000000000000
x12: 0x0000000000000000 x13: 0x0000000000000000 x14: 0x0000000000000000 x15: 0x0000007026f1e9a2
x16: 0x0000000103a71834 x17: 0x000000010c0b74e0 x18: 0x0000000000000000 x19: 0x000000010c0b74e0
x20: 0x0000007115499e10 x21: 0x00000070c576f800 x22: 0x0000007026f1e9a2 x23: 0x00000070c576f8e0
x24: 0x0000000000000000 x25: 0x00000070021b8a99 x26: 0x00000070021b8a99 x27: 0x0000007122f80903
x28: 0x00000071154920d0 fp: 0x000000016d722d80 lr: 0x000000010af4a768
sp: 0x000000016d722d20 pc: 0x0000000103a7186c cpsr: 0x80001000
far: 0x0000000000617265 esr: 0x92000006 (Data Abort) byte read Translation fault
```
Although this is not a current GHC HEAD problem (as `p_dyn` is not supported), but it probably revealed a bug in profiling code and that may happen in static profiling, so I report it to track this issue.
## Steps to reproduce
Use https://gitlab.haskell.org/wavewave/ghc/-/tree/wavewave/ghc_p_dyn?ref_type=heads , build GHC with `--flavour=perf+profiled_ghc`
and build a big project and wait for this happening. The chances are not very high though, and probably correlated to the size of the target project.
I will update this if I can find a minimal example.
## Expected behavior
Segfault should not happen in any case.
## Environment
* GHC version used: custom GHC version (`wavewave/ghc_p_dyn` branch `50b4995`), on top of GHC 9.9.20240131 (38c3afb)
Optional:
* Operating System: macOS Sonoma 14.3
* System Architecture: Apple M1 Max9.10.1Ian-Woo KimIan-Woo Kimhttps://gitlab.haskell.org/ghc/ghc/-/issues/24421The user guide should specify which heap profiling flags need -prof2024-02-13T01:10:50ZTeo CamarasuThe user guide should specify which heap profiling flags need -profSome of the flags for restricting heap profiling censuses require `-prof` but that isn't stated in the documentation.
For instance the `-hc ⟨name⟩` flag restricts to a specific cost centre. That clearly requires `-prof` but it's missing...Some of the flags for restricting heap profiling censuses require `-prof` but that isn't stated in the documentation.
For instance the `-hc ⟨name⟩` flag restricts to a specific cost centre. That clearly requires `-prof` but it's missing the "requires -prof` annotation. We should add that annotation for all the flags in this section that require it.Teo CamarasuTeo Camarasuhttps://gitlab.haskell.org/ghc/ghc/-/issues/24415WASM reactor module crashes after garbage collection2024-02-06T23:47:56ZVladislav LagunovWASM reactor module crashes after garbage collection## Summary
I've been building a [Frontend library](https://github.com/lagunoff/htmlt-wasm) for Haskell and stumbled upon this bug where my examples crashed randomly when I built them as WASI reactor modules. I created a [separate repo](...## Summary
I've been building a [Frontend library](https://github.com/lagunoff/htmlt-wasm) for Haskell and stumbled upon this bug where my examples crashed randomly when I built them as WASI reactor modules. I created a [separate repo](https://github.com/lagunoff/wasi-reactor-gc-counterexample) with minimal reproducible counterexample, You can open deployed version [here](https://lagunoff.github.io/wasi-reactor-gc-counterexample) and observe the bug in your browser console.
It seems this problem only occurs when program is compiled as WASI reactor with `-optl-mexec-model=reactor` option. It crashes on next re-entry after a garbage collection operation. Following is contents of stderr, when I enable `-dlink` `-debug` `+RTS -DS -RTS`
```
uknown.wasm: internal error: Evaluated a CAF (0x13b2a0) that was GC'd!
(GHC version 9.9.20231020 for wasm32_unknown_wasi)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
## Steps to reproduce
- Open [counterexample](https://lagunoff.github.io/wasi-reactor-gc-counterexample), turn on browser console and follow instructions on the page
- Take a look at [sources](https://github.com/lagunoff/wasi-reactor-gc-counterexample) for the counterexample if you interested
## Expected behavior
WASI reactor doesn't crash
## Environment
* ghc-wasm-meta (master) c0aa3bb7d88bb6ec809210e17658dd1ed64ba66chttps://gitlab.haskell.org/ghc/ghc/-/issues/24414darwin: `-target` not present in C linker options2024-02-22T13:02:35ZMatthew Pickeringdarwin: `-target` not present in C linker optionsThere is a typo in the `distrib/configure.ac` file which means we are not passing `--target` when using `GHC` as a linker.There is a typo in the `distrib/configure.ac` file which means we are not passing `--target` when using `GHC` as a linker.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/24411mdo should use HsExpansion Route2024-02-08T11:43:17ZApoorv Inglemdo should use HsExpansion Route## Summary
mdo (recursive do statements) should follow the same flow of vanilla do statements and not depend on `tcSyntaxOp`
## Steps to reproduce
```haskell
{-# LANGUAGE ImpredicativeTypes, RecursiveDo #-}
type Id = forall a. a -> ...## Summary
mdo (recursive do statements) should follow the same flow of vanilla do statements and not depend on `tcSyntaxOp`
## Steps to reproduce
```haskell
{-# LANGUAGE ImpredicativeTypes, RecursiveDo #-}
type Id = forall a. a -> a
t :: IO (forall a. a -> a)
t = return id
p :: (forall a. a -> a) -> (Bool, Int)
p f = (f True, f 3)
-- This does *not* type check:
foo2 = mdo { x <- t ; return (p x) }
```
Fails with:
```
testsuite/tests/typecheck/should_run/T18324.hs:13:19: error: [GHC-91028]
• Couldn't match type ‘a0’ with ‘Id’
Expected: IO a0
Actual: IO Id
Cannot instantiate unification variable ‘a0’
with a type involving polytypes: Id
• In a stmt of an 'mdo' block: x <- t
In the expression:
mdo x <- t
return (p x)
In an equation for ‘foo2’:
foo2
= mdo x <- t
return (p x)
|
13 | foo2 = mdo { x <- t ; return (p x) }
| ^
testsuite/tests/typecheck/should_run/T18324.hs:13:33: error: [GHC-46956]
• Couldn't match expected type ‘a -> a’ with actual type ‘a0’
because type variable ‘a’ would escape its scope
This (rigid, skolem) type variable is bound by
a type expected by the context:
Id
at testsuite/tests/typecheck/should_run/T18324.hs:13:33
• In the first argument of ‘p’, namely ‘x’
In the first argument of ‘return’, namely ‘(p x)’
In a stmt of an 'mdo' block: return (p x)
• Relevant bindings include
x :: a0
(bound at testsuite/tests/typecheck/should_run/T18324.hs:13:14)
|
13 | foo2 = mdo { x <- t ; return (p x) }
```
## Expected behavior
Should typecheck and run without errors
## Environment
* GHC version used: 9.6.4Apoorv IngleApoorv Inglehttps://gitlab.haskell.org/ghc/ghc/-/issues/24409JavaScript Backend has no codeowners2024-02-12T17:06:51Zdoyougnujmy6342@gmail.comJavaScript Backend has no codeownersLooks like we missed owning the code we merged into GHC in !9133. Just need to update the `CODEOWNERS` file.Looks like we missed owning the code we merged into GHC in !9133. Just need to update the `CODEOWNERS` file.Sylvain HenryLuite StegemanJosh Meredithdoyougnujmy6342@gmail.comSylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/24408bytestring submodule points to potentially non-stable branch2024-02-13T15:09:29ZMatthew Pickeringbytestring submodule points to potentially non-stable branchIn !11576 the bytestring branch is bumped to a commit on the `draft-0.12.1-for-testing-with-ghc` branch, are the some guarantees that this branch won't be deleted?
Typically we only want to bump the submodules to commits which are on st...In !11576 the bytestring branch is bumped to a commit on the `draft-0.12.1-for-testing-with-ghc` branch, are the some guarantees that this branch won't be deleted?
Typically we only want to bump the submodules to commits which are on stable branches (such as master, or ghc-head in haddock's case) which are never going to be deleted and leave dangling references which would render portions of the tree unbuildable.
Could we please change the bytestring commit to something which has a guarantee that it won't become dangling in future? Probably another commit on the master branch is appropriate, or `bytestring` could introduce a branch similar to how haddock has `ghc-head` which stages changes before they make it into the main branch.
cc @clyringhttps://gitlab.haskell.org/ghc/ghc/-/issues/24404Template Haskell allows breaking encapsulation2024-03-19T15:12:42ZTeo CamarasuTemplate Haskell allows breaking encapsulation## Summary
Use of `reify` from `template-haskell` allows one to trivially break encapsulation by accessing un-exported constructors/fields.
This is distinct from uses of `template-haskell` that make use of `unsafeCoerce` to access inte...## Summary
Use of `reify` from `template-haskell` allows one to trivially break encapsulation by accessing un-exported constructors/fields.
This is distinct from uses of `template-haskell` that make use of `unsafeCoerce` to access internal compiler state.
This happens through the normal `reify` interface.
`reify` allows us to see all constructors/fields whether they are exported or not.
This, I think, is fine. The issue is that these `Name`s can then end up in code generated using TH.
I'd suggest that emitting code that refers to `Name`s that aren't imported in the module should at least lead to a warning if not an error.
We discovered this at work years ago by moving a call to `makeLenses` into another module, and found that un-exported fields were still being given lenses, and that they still worked.
## Steps to reproduce
Take the following two modules:
```haskell
❯ cat A.hs
module A (Foo) where
data Foo = MkFoo { unexported :: Int }
deriving (Show)
```
```haskell
❯ cat B.hs
{-# LANGUAGE TemplateHaskell #-}
module B where
import A (Foo)
import Language.Haskell.TH.Syntax
import Language.Haskell.TH.Lib
foo :: Foo
foo = $(do {
TyConI (DataD _ _ _ _ [RecC constrName _ ] _) <- reify ''Foo;
[| $(conE constrName) 100 |]
})
main = print foo
```
Then compile and run with:
```
❯ ghc --make A.hs B.hs -main-is B
❯ ./B
MkFoo {unexported = 100}
```
## Expected behavior
The compiler should at least warn us that TH is producing code that refers to values that aren't imported, and can't be imported in this module.
## Environment
* GHC version used: 9.4, but I'm pretty sure it happens with any recent version of GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/24400ghc-toolchain: Backwards compatibility for target descriptions2024-02-06T15:16:41ZRodrigo Mesquitaghc-toolchain: Backwards compatibility for target descriptionsI realize now that we don't have a compatibility story for target description files yet. Scenario:
1. Configure a toolchain with ghc-toolchain 0.1
2. Update compiler/ghc-toolchain
3. Read an existing toolchain using a program linked aga...I realize now that we don't have a compatibility story for target description files yet. Scenario:
1. Configure a toolchain with ghc-toolchain 0.1
2. Update compiler/ghc-toolchain
3. Read an existing toolchain using a program linked against ghc-toolchain 0.2, which has additional fields.
4. The existing toolchain will fail to parse.
We already read from a serialized version of the datatype, so I suppose we could either assume some defaults, or ask to reconfigure.https://gitlab.haskell.org/ghc/ghc/-/issues/24394`-Dn` is missing from user guide2024-02-08T17:32:08ZTeo Camarasu`-Dn` is missing from user guideThe `-Dn` debug flag for non-moving collector information is missing from the user guide.
It should be listed along with the other `-D*` flags here: https://downloads.haskell.org/ghc/latest/docs/users_guide/runtime_control.html#rts-flag-...The `-Dn` debug flag for non-moving collector information is missing from the user guide.
It should be listed along with the other `-D*` flags here: https://downloads.haskell.org/ghc/latest/docs/users_guide/runtime_control.html#rts-flag--Dk%20%20DEBUG:%20continuation
The corresponding `-ln` flag is documentedBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24393Using `-Dn` can lead to segfaults2024-02-21T13:53:40ZTeo CamarasuUsing `-Dn` can lead to segfaults## Summary
When using the debug RTS, we can use the `-Dn` flag to print non-moving debug info.
One of the things this does is print non-moving segment occupancy statistics.
This code is also called when using the eventlog when the `-ln...## Summary
When using the debug RTS, we can use the `-Dn` flag to print non-moving debug info.
One of the things this does is print non-moving segment occupancy statistics.
This code is also called when using the eventlog when the `-ln` flag is enabled.
In that codepath, we make sure not to collect information about live words when the mutator is running, as this can lead to issues.
But it looks like this doesn't happen when going via the debug codepath.
In that case collecting live word data seems to be enabled unconditionally.
I'm seeing some segmentation faults when running `-Dn` like the following:
```
Thread 3 "nonmoving-mark" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 170171]
0x00000000004f006a in closure_sizeW_ (p=0x42203a7fd8, info=0xfffffffffffffff0) at rts/ClosureSize.c:14
14 switch (info->type) {
(gdb) bt
#0 0x00000000004f006a in closure_sizeW_ (p=0x42203a7fd8, info=0xfffffffffffffff0) at rts/ClosureSize.c:14
#1 0x000000000049768a in closure_sizeW (p=0x42203a7fd8) at rts/include/rts/storage/ClosureMacros.h:418
#2 0x00000000004c745a in nonmovingAllocatorCensus_ (alloc_idx=2, collect_live_words=true) at rts/sm/NonMovingCensus.c:40
#3 0x00000000004c787d in nonmovingPrintAllocatorCensus (collect_live_words=true) at rts/sm/NonMovingCensus.c:138
#4 0x00000000004c6d8e in nonmovingMark_ (mark_queue=0x6afcd0, dead_weaks=0x7ffff6b5de60, resurrected_threads=0x7ffff6b5de68, concurrent=true) at rts/sm/NonMoving.c:1224
#5 0x00000000004c64a3 in nonmovingConcurrentMarkWorker (data=0x0) at rts/sm/NonMoving.c:933
#6 0x00000000004dce09 in start_thread (param=0x6a18e0) at rts/posix/OSThreads.c:218
#7 0x00007ffff7cdfe24 in start_thread () from /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libc.so.6
#8 0x00007ffff7d619b0 in clone3 () from /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/lib/libc.so.6
(gdb) p *Bdescr(nonmovingGetSegment(0x42203a7fd8))
$7 = {start = 0x42203a0000, {free = 0x4200000002, nonmoving_segment = {allocator_idx = 2, next_free_snap = 0}}, link = 0x0, u = {back = 0x42203a7ff8, bitmap = 0x42203a7ff8,
scan = 0x42203a7ff8}, gen = 0x6a15c0, gen_no = 1, dest_no = 1, node = 0, flags = 1024, blocks = 8, _padding = {0, 0, 0}}
(gdb) p printClosure(0x42203a7fd8)
0x42203a7fd8: ghc-prim:GHC.Types.:(0x42203622e1, 0x42203683fa)
```
### Solution
Maybe all we need to do is only enable live word collection if we are not doing concurrent collection?
If so then this should be a one line change and I'd be happy to make an MRBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24392GHC 9.8.1 crashes with `heap overflow` while deriving `Data` on Windows if bo...2024-02-14T20:26:26ZJavier SagredoGHC 9.8.1 crashes with `heap overflow` while deriving `Data` on Windows if both `-O -XHaskell2010` are enabled## Summary
I replaced the code below because I found a much much smaller reproduction.
```
code\Only-0.1 via λ 9.8.1
❯ /c/ghcup/bin/ghc-9.8.1 -fforce-recomp src/Data/Tuple/Only.hs -XHaskell2010
[1 of 1] Compiling Data.Tuple.Only ( src...## Summary
I replaced the code below because I found a much much smaller reproduction.
```
code\Only-0.1 via λ 9.8.1
❯ /c/ghcup/bin/ghc-9.8.1 -fforce-recomp src/Data/Tuple/Only.hs -XHaskell2010
[1 of 1] Compiling Data.Tuple.Only ( src\Data\Tuple\Only.hs, src\Data\Tuple\Only.o )
code\Only-0.1 via λ 9.8.1
➜ /c/ghcup/bin/ghc-9.8.1 -fforce-recomp src/Data/Tuple/Only.hs -O
[1 of 1] Compiling Data.Tuple.Only ( src\Data\Tuple\Only.hs, src\Data\Tuple\Only.o )
code\Only-0.1 via λ 9.8.1
➜ /c/ghcup/bin/ghc-9.8.1 -fforce-recomp src/Data/Tuple/Only.hs -XHaskell2010 -O
[1 of 1] Compiling Data.Tuple.Only ( src\Data\Tuple\Only.hs, src\Data\Tuple\Only.o )
ghc-9.8.1.exe: heap overflow
code\Only-0.1 via λ 9.8.1
➜ cat src/Data/Tuple/Only.hs
{-# LANGUAGE DeriveDataTypeable #-}
module Data.Tuple.Only where
import Data.Data (Data)
data Only a = Only deriving (Data)
```
## Steps to reproduce
```bash
ghcup install ghc 9.8.1 --set
ghcup install cabal 3.10.2.1 --set
cat <<EOF > Only.hs
{-# LANGUAGE DeriveDataTypeable #-}
module Only where
import Data.Data (Data)
data Only a = Only deriving (Data)
EOF
ghc Only.hs -XHaskell2010 -O
```
## Environment
* GHC version used: 9.8.1
Optional:
* Operating System: Windows: `MINGW64_NT-10.0-22631 ... 3.4.10.x86_64 2023-12-22 10:06 UTC x86_64 Msys`
* System Architecture: x86_649.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/24389error: ld: unknown option: -no_warn_duplicate_libraries on macOS with GHC 9.6.42024-02-21T10:07:56ZBodigrimerror: ld: unknown option: -no_warn_duplicate_libraries on macOS with GHC 9.6.4## Summary
I've upgraded from GHC 9.6.3 to 9.6.4 on my macOS machine and `zlib-0.6.3.0` stopped building.
## Steps to reproduce
```
$ cabal-3.10.2.0 unpack zlib && cd zlib-0.6.3.0 && cabal-3.10.2.0 build -w ghc-9.6.4
Unpacking to zlib...## Summary
I've upgraded from GHC 9.6.3 to 9.6.4 on my macOS machine and `zlib-0.6.3.0` stopped building.
## Steps to reproduce
```
$ cabal-3.10.2.0 unpack zlib && cd zlib-0.6.3.0 && cabal-3.10.2.0 build -w ghc-9.6.4
Unpacking to zlib-0.6.3.0/
Resolving dependencies...
Build profile: -w ghc-9.6.4 -O1
In order, the following will be built (use -v for more details):
- zlib-0.6.3.0 (lib) (first run)
Configuring library for zlib-0.6.3.0..
Preprocessing library for zlib-0.6.3.0..
linking /private/tmp/zlib-0.6.3.0/dist-newstyle/build/aarch64-osx/ghc-9.6.4/zlib-0.6.3.0/build/Codec/Compression/Zlib/Stream_hsc_make.o failed (exit code 1)
rsp file was: "/private/tmp/zlib-0.6.3.0/dist-newstyle/build/aarch64-osx/ghc-9.6.4/zlib-0.6.3.0/build/Codec/Compression/Zlib/hsc2hscall71797-2.rsp"
command was: /usr/bin/gcc /private/tmp/zlib-0.6.3.0/dist-newstyle/build/aarch64-osx/ghc-9.6.4/zlib-0.6.3.0/build/Codec/Compression/Zlib/Stream_hsc_make.o /private/tmp/zlib-0.6.3.0/dist-newstyle/build/aarch64-osx/ghc-9.6.4/zlib-0.6.3.0/build/Codec/Compression/Zlib/Stream_hsc_utils.o -o /private/tmp/zlib-0.6.3.0/dist-newstyle/build/aarch64-osx/ghc-9.6.4/zlib-0.6.3.0/build/Codec/Compression/Zlib/Stream_hsc_make --target=arm64-apple-darwin -Wl,-no_fixup_chains -Wl,-no_warn_duplicate_libraries --target=arm64-apple-darwin -Wl,-no_fixup_chains -lz -L/Users/andrew/.ghcup/ghc/9.6.4/lib/ghc-9.6.4/lib/../lib/aarch64-osx-ghc-9.6.4/bytestring-0.11.5.3 -L/Users/andrew/.ghcup/ghc/9.6.4/lib/ghc-9.6.4/lib/../lib/aarch64-osx-ghc-9.6.4/template-haskell-2.20.0.0 -L/Users/andrew/.ghcup/ghc/9.6.4/lib/ghc-9.6.4/lib/../lib/aarch64-osx-ghc-9.6.4/pretty-1.1.3.6 -L/Users/andrew/.ghcup/ghc/9.6.4/lib/ghc-9.6.4/lib/../lib/aarch64-osx-ghc-9.6.4/ghc-boot-th-9.6.4 -L/Users/andrew/.ghcup/ghc/9.6.4/lib/ghc-9.6.4/lib/../lib/aarch64-osx-ghc-9.6.4/deepseq-1.4.8.1 -L/Users/andrew/.ghcup/ghc/9.6.4/lib/ghc-9.6.4/lib/../lib/aarch64-osx-ghc-9.6.4/array-0.5.6.0 -L/Users/andrew/.ghcup/ghc/9.6.4/lib/ghc-9.6.4/lib/../lib/aarch64-osx-ghc-9.6.4/base-4.18.2.0 -liconv -L/Users/andrew/.ghcup/ghc/9.6.4/lib/ghc-9.6.4/lib/../lib/aarch64-osx-ghc-9.6.4/ghc-bignum-1.3 -L/Users/andrew/.ghcup/ghc/9.6.4/lib/ghc-9.6.4/lib/../lib/aarch64-osx-ghc-9.6.4/ghc-prim-0.10.0 -L/Users/andrew/.ghcup/ghc/9.6.4/lib/ghc-9.6.4/lib/../lib/aarch64-osx-ghc-9.6.4/rts-1.0.2 -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -lm -ldl -lffi
error: ld: unknown option: -no_warn_duplicate_libraries
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error: cabal-3.10.2.0: Failed to build zlib-0.6.3.0.
```
## Expected behavior
I expect it to build successfully. For instance, GHC 9.8.1 works fine:
```
$ cabal-3.10.2.0 unpack zlib && cd zlib-0.6.3.0 && cabal-3.10.2.0 build -w ghc-9.8.1
Unpacking to zlib-0.6.3.0/
Resolving dependencies...
Build profile: -w ghc-9.8.1 -O1
In order, the following will be built (use -v for more details):
- zlib-0.6.3.0 (lib) (first run)
Configuring library for zlib-0.6.3.0..
Preprocessing library for zlib-0.6.3.0..
Building library for zlib-0.6.3.0..
[1 of 6] Compiling Codec.Compression.Zlib.ByteStringCompat
[2 of 6] Compiling Codec.Compression.Zlib.Stream
[3 of 6] Compiling Codec.Compression.Zlib.Internal
[4 of 6] Compiling Codec.Compression.Zlib.Raw
[5 of 6] Compiling Codec.Compression.Zlib
[6 of 6] Compiling Codec.Compression.GZip
```
## Environment
* GHC version used: 9.6.4, installed via ghcup.
* Cabal 3.10.2.0, installed via ghcup.
* Operating System: macOS Ventura 13.0.1.
* System Architecture: arm (M2).
```
$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-857.1
BUILD 23:13:29 May 7 2023
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 14.0.3, (clang-1403.0.22.14.1) (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 14.0.3 (tapi-1403.0.5.1)
```9.6.5https://gitlab.haskell.org/ghc/ghc/-/issues/24383T24171 segfaults on AArch64 with GHC HEAD:2024-01-30T17:08:56ZAndreas KlebingerT24171 segfaults on AArch64 with GHC HEAD:## Summary
This test seems to segfault consistently on my local aarch64 machine when run with:
`hadrian/build -j6 --flavour=release test --only="T24171"`
```
=====> 1 of 1 [0, 0, 0]
Wrong exit code for T24171()(expected 0 , actual 2 )...## Summary
This test seems to segfault consistently on my local aarch64 machine when run with:
`hadrian/build -j6 --flavour=release test --only="T24171"`
```
=====> 1 of 1 [0, 0, 0]
Wrong exit code for T24171()(expected 0 , actual 2 )
Stderr run ( T24171 ):
make[1]: *** [Makefile:8: build_and_run] Segmentation fault (core dumped)
make: *** [Makefile:5: clean_build_and_run] Error 2
*** unexpected failure for T24171(normal)
```
## Expected behavior
No segfaults
## Environment
* GHC version used: GHC-HEAD ( 699da01bbbf3e42c7d38b9cfe443dd0e8e256342 )
* AArch64
* Debian sidAndreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/24381Binding incorrectly reported as shadowed when using `NoFieldSelectors`2024-02-08T17:32:08ZtaylorfausakBinding incorrectly reported as shadowed when using `NoFieldSelectors`## Summary
When using the `NoFieldSelectors` language extension, GHC 9.8.1 incorrectly reports that bindings shadow field selectors. I believe that this is a regression from GHC 9.6.4 and before.
## Steps to reproduce
Compiling the fo...## Summary
When using the `NoFieldSelectors` language extension, GHC 9.8.1 incorrectly reports that bindings shadow field selectors. I believe that this is a regression from GHC 9.6.4 and before.
## Steps to reproduce
Compiling the following module with GHC 9.8.1:
``` hs
{-# OPTIONS_GHC -Wname-shadowing #-}
{-# LANGUAGE Haskell2010 #-} -- Necessary to avoid `NamedFieldPuns` from `GHC2021`.
{-# LANGUAGE NoFieldSelectors #-}
module M where
data T = C { x :: () }
f x = x
```
Gives me the following warning:
```
M.hs:6:3: warning: [GHC-63397] [-Wname-shadowing]
This binding for ‘x’ shadows the existing binding
defined at M.hs:5:14
|
6 | f x = x
| ^
```
## Expected behavior
There should not be any warnings when compiling that module. The field selector `x` does not exist, so using it as a function argument does not shadow anything. Changing line 6 to be `f = x` gives this error:
```
M.hs:6:5: error: [GHC-88464]
Variable not in scope: x
Suggested fix:
Notice that ‘x’ is a field selector belonging to the type ‘T’
that has been suppressed by NoFieldSelectors.
|
6 | f = x
| ^
```
## Environment
* GHC version used: 9.8.19.8.2sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.com