GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-12T15:04:15Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24509Undocumented ghci commands2024-03-12T15:04:15ZAdam GundryUndocumented ghci commandsThe `:check` and `:where` GHCi commands appear to be missing from the user's guide. We should either document them or deprecate them. (Originally noted at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12070#note_551552.)
Ideally w...The `:check` and `:where` GHCi commands appear to be missing from the user's guide. We should either document them or deprecate them. (Originally noted at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12070#note_551552.)
Ideally we would have a test that all the `ghciCommands` are documented...Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24508Do not emit `-Winaccessible-code` warnings when the pattern-match checker wou...2024-03-14T09:09:32ZSebastian GrafDo not emit `-Winaccessible-code` warnings when the pattern-match checker would warn as wellhttps://discourse.haskell.org/t/inaccessible-vs-redundant-warnings-in-gadt-pattern-matching/8952 had one more user confused by the apparent redundancy of `-Winaccessible-code` warnings with those of the pattern-match checker.
In https:/...https://discourse.haskell.org/t/inaccessible-vs-redundant-warnings-in-gadt-pattern-matching/8952 had one more user confused by the apparent redundancy of `-Winaccessible-code` warnings with those of the pattern-match checker.
In https://gitlab.haskell.org/ghc/ghc/-/issues/19428 I proposed to deprecate `-Winaccessible-code` for this reason, but @RyanGlScott correctly pointed out that there are inaccessible code warnings that have no equivalent in the pattern-match checker.
So in this ticket, I instead propose not to generate `-Winaccessible-code` warnings inside patterns.https://gitlab.haskell.org/ghc/ghc/-/issues/24506RTS crash with 9.8.12024-03-12T15:10:14ZSophie TaylorRTS crash with 9.8.1## Summary
I'm working on implementing a production system via a rete network, using STM. When I add certain productions, I get an exception thrown due to a `lens` `Fold` folding an empty list. When trying to debug this in GHCi I added ...## Summary
I'm working on implementing a production system via a rete network, using STM. When I add certain productions, I get an exception thrown due to a `lens` `Fold` folding an empty list. When trying to debug this in GHCi I added a breakpoint to the function where the empty Fold occurs, and before the Fold even happens, about two seconds after hitting the breakpoint, GHCi crashes with the following:
```haskell
ghci> :break Rete.ReteEffect.matchFromToken
Breakpoint 0 activated at src/Rete/ReteEffect.hs:(437,34)-(470,85)
ghci> import ForTesting
ghci> testCommand "add rules {\"rule\" (state <snake> * *) (<n1> <n2> <n3>) (<c> <g> <b>) --> (<n1> <n2> <n3>) (<c> <g> <b>)}"
Stopped in Rete.ReteEffect.matchFromToken, src/Rete/ReteEffect.hs:(437,34)-(470,85)
_result :: Sem r Core.WME.RuleMatch = _
tok :: Core.WME.WMEToken ? Core.WME.IsProductionToken = _
token :: Rete.Types.Tokens.WMEToken' Core.WME.WMEMetadata = _
[src/Rete/ReteEffect.hs:(437,34)-(470,85)] ghci> <interactive>: internal error: evacuate: strange closure type 636340344
Stack trace:
0x7fffef73027f set_initial_registers (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffee1de088 dwfl_thread_getframes (/nix/store/8hy9xdnczdpn846qpsybwlpk5l607lbj-elfutils-0.189/lib/libdw-0.189.so)
0x7fffee1ddbdb get_one_thread_cb (/nix/store/8hy9xdnczdpn846qpsybwlpk5l607lbj-elfutils-0.189/lib/libdw-0.189.so)
0x7fffee1ddeea dwfl_getthreads (/nix/store/8hy9xdnczdpn846qpsybwlpk5l607lbj-elfutils-0.189/lib/libdw-0.189.so)
0x7fffee1de417 dwfl_getthread_frames (/nix/store/8hy9xdnczdpn846qpsybwlpk5l607lbj-elfutils-0.189/lib/libdw-0.189.so)
0x7fffef730887 libdwGetBacktrace (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef73902d rtsFatalInternalErrorFn (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef739200 barf (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef716171 evacuate1 (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef71beac scavenge_block1 (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef7658b7 scavenge_loop1 (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef75a702 scavenge_until_all_done (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef75c193 GarbageCollect (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef73d320 scheduleDoGC (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef73e339 schedule (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef73ebdc scheduleWorker (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef7431dd workerStart (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffee29fdd4 start_thread (/nix/store/aw2fw9ag10wr9pf0qk4nk5sxi0q0bn56-glibc-2.37-8/lib/libc.so.6)
0x7fffee3219b0 __clone3 (/nix/store/aw2fw9ag10wr9pf0qk4nk5sxi0q0bn56-glibc-2.37-8/lib/libc.so.6)
(GHC version 9.8.1 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
Error: cabal: repl failed for cosmothought-core-0.1.0.0. The build process
terminated with exit code -6
```
## Steps to reproduce
Most convenient as a Nix flake:
1. grab from https://gitlab.com/spacekitteh/cosmothought/-/tree/repro-24506?ref_type=heads, ensure the current branch is `repro-24506`
2. `nix develop`
3. `cabal repl core`
5. `ghci> import ForTesting`
6. Optionally, `ghci> :break Rete.ReteEffect.producePatternMap` for a stack trace of the segfault. Sometimes, it doesn't produce a stacktrace, but it often does.
7. `ghci> repro24506`
8. Sometimes, a single invocation of `repro24506` doesn't result in the segfault; just run `repro24506` again until it does.
~~Alternatively, it can be reproduced in `gdb` using `cosmothought-core-oneoff`; but this requires setting a breakpoint. If you run `gdb --args cosmothought-core-oneoff +RTS -DS`, and set a breakpoint on `cosmothoughtzmcorezm0zi1zi0zi0zminplace_ReteziReteBuilder_createOrShareAlphaNodes_info`, it will barf during Sanity checking.~~ Ok that's due to setting the breakpoint incorrectly, see https://gitlab.haskell.org/ghc/ghc/-/issues/24506#note_552349
The exact value for the strange closure type changes from run to run. Sometimes, it just segfaults instead of printing the backtrace.
The problem is almost certainly in the `core/src/Rete` modules, in particular, how I'm using `stm-hamt's`.
I'm trying to narrow it down in order to find a minimal test case, but it's difficult.
## Expected behavior
Not crash.
## Things tried
- `+RTS --nonmoving-gc` and `--copying-gc` both segfault
- `-O0 -fno-static-argument-transformation` still segfaults
- `+RTS -C0 -V0` with non-threaded runtime still segfaults
- Linked with `-debug`
- `+RTS -DS` doesn't produce anything immediately obvious to me
## Possibly related
~~#24443 ~~ Nope, just a coincidence, but a strange one
## Environment
* GHC version used: 9.8.1
* Operating System: NixOS
* System Architecture: x64https://gitlab.haskell.org/ghc/ghc/-/issues/24505Instances getting incorrect IPE data2024-03-12T15:11:17ZFinley McIlwaineInstances getting incorrect IPE dataCode:
```haskell
{-# LANGUAGE AllowAmbiguousTypes #-}
module Main where
import GHC.InfoProv
import Unsafe.Coerce
-- Boilerplate to help us access the literal dictionaries
data Dict c where
Dict :: forall c. c => Dict c
data Bo...Code:
```haskell
{-# LANGUAGE AllowAmbiguousTypes #-}
module Main where
import GHC.InfoProv
import Unsafe.Coerce
-- Boilerplate to help us access the literal dictionaries
data Dict c where
Dict :: forall c. c => Dict c
data Box where
Box :: forall a. a -> Box
mkBox :: forall a. a => Box
mkBox = unsafeCoerce (Dict @a)
-- Interesting bit
data A = A
instance Eq A where
A == A = True
instance Ord A where
A <= A = undefined
main :: IO ()
main = do
(\(Box d) -> print =<< whereFrom d) $ mkBox @(Eq A)
(\(Box d) -> print =<< whereFrom d) $ mkBox @(Ord A)
```
This program prints the IPE data of the `Eq A` and `Ord A` dictionaries. The `Eq A` dictionary looks as we would expect, with `ipLabel = $fEqA`. The `Ord A` dictionary, however, gets the label `<`. Compile with:
```
ghc -O -fforce-recomp -finfo-table-map -fdistinct-constructor-tables Main.hs
```
The program outputs:
```
Just (InfoProv {ipName = "C:Eq_Main_0_con_info", ipDesc = CONSTR_2_0, ipTyDesc = "Eq", ipLabel = "$fEqA", ipMod = "Main", ipSrcFile = "Main.hs", ipSrcSpan = "23:10-13"})
Just (InfoProv {ipName = "C:Ord_Main_0_con_info", ipDesc = CONSTR, ipTyDesc = "Ord", ipLabel = "<", ipMod = "Main", ipSrcFile = "Main.hs", ipSrcSpan = "26:10-14"})
```
I would expect the `Ord` label to be `$fOrdA`, not `<`.
Interestingly, if we add more explicit definitions to the `Ord A` instance, the label changes. Changing the instance to:
```haskell
instance Ord A where
A <= A = undefined
compare = undefined
```
Changes the label to `>` instead of `<`:
```
Just (InfoProv {ipName = "C:Ord_Main_0_con_info", ipDesc = CONSTR, ipTyDesc = "Ord", ipLabel = ">", ipMod = "Main", ipSrcFile = "Main.hs", ipSrcSpan = "26:10-14"})
```https://gitlab.haskell.org/ghc/ghc/-/issues/24504Eliminate dependence of "Hello World" on `Read`2024-03-09T00:37:40ZBen GamariEliminate dependence of "Hello World" on `Read`With the merge of !8869, a "Hello World" executable now pulls in various machinery to do with `Read` (including some rather large `Integer` utilities). This regresses code size of very simple programs and yet in principle shouldn't be ne...With the merge of !8869, a "Hello World" executable now pulls in various machinery to do with `Read` (including some rather large `Integer` utilities). This regresses code size of very simple programs and yet in principle shouldn't be necessary. I have started investigating why the linker draws these definitions into the final link.9.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24503checkHomeModulesClosed is really slow2024-03-05T14:56:38ZZubincheckHomeModulesClosed is really slow`checkHomeModulesClosed` seems to traverse all paths in the package dependency graph and this quickly becomes infeasible for larger graphs.
To reproduce, try to load Agda into a multi component session and notice that GHCi seems to be s...`checkHomeModulesClosed` seems to traverse all paths in the package dependency graph and this quickly becomes infeasible for larger graphs.
To reproduce, try to load Agda into a multi component session and notice that GHCi seems to be stuck before it even gets to compiling any modules.
Fix in !12162ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24501Release tracking ticket for GHC 9.6.52024-03-05T23:04:52ZZubinRelease tracking ticket for GHC 9.6.5This is the release checklist for the %"9.6.5" milestone. See #16816 for the template that this was derived from.
# Pre-release checklist
* [ ] Ensure that submodules are on released tags (the below is produced using [this script](htt...This is the release checklist for the %"9.6.5" milestone. See #16816 for the template that this was derived from.
# Pre-release checklist
* [ ] Ensure that submodules are on released tags (the below is produced using [this script](https://gitlab.haskell.org/bgamari/ghc-utils/blob/master/rel-eng/submod-release-summary.py)):
* [ ] `libraries/Cabal`: version *todo*
* [ ] `libraries/Win32`: version *todo*
* [ ] `libraries/binary`: version *todo*
* [ ] `libraries/bytestring`: version *todo*
* [ ] `libraries/containers`: version *todo*
* [ ] `libraries/deepseq`: version *todo*
* [ ] `libraries/directory`: version *todo*
* [ ] `libraries/filepath`: version *todo*
* [ ] `libraries/haskeline`: version *todo*
* [ ] `libraries/mtl`: version *todo*
* [ ] `libraries/parsec`: version *todo*
* [ ] `libraries/pretty`: version *todo*
* [ ] `libraries/process`: version *todo*
* [ ] `libraries/terminfo`: version *todo*
* [ ] `libraries/text`: version *todo*
* [ ] `libraries/time`: version *todo*
* [ ] `libraries/transformers`: version *todo*
* [ ] `libraries/unix`: version *todo*
* [ ] `libraries/xhtml`: version *todo*
* [ ] `utils/haddock`: version *todo*
* [ ] `utils/hsc2hs`: version *todo*
* [ ] Notify stakeholders of release progress: `Julian Ospald <hasufell@posteo.de>, ghc-devs@haskell.org`
* [ ] Non-released submodules up-to-date:
* [ ] `nofib` (upstream: ghc/nofib>)
* [ ] `libffi-tarballs` (upstream: ghc/libffi-tarballs>)
* [ ] `libraries/ghc-bignum/gmp/gmp-tarballs` (upstream: ghc/gmp-tarballs>)
* [ ] `LlvmMinVersion` and `LlvmMaxVersion` in `configure.ac` is targetting intended LLVM version
* [ ] `llvm-targets` file [updated](https://gitlab.haskell.org/ghc/ghc/wikis/making-releases#updating-the-tree)
* [ ] Release notes (`docs/users_guide/x.y.z-notes.rst`) written
* Release notes linked in `docs/users_guide/release-notes.rst`
* LLVM version requirement mentioned
* [ ] Remove "Included libraries" sections from old release notes
* [ ] `autoconf` scripts [updated](https://gitlab.haskell.org/ghc/ghc/wikis/making-releases#updating-the-tree)
* [ ] Check that Unicode database in `base` (`libraries/base/cbits/README.Unicode`) reflects current standard release (http://www.unicode.org/versions/latest/).
* [ ] Verify that the ~"backport needed" label has no more issues/merge requests needing backport
* [ ] Verify that all CI builds are green before moving to *release checklist*
* [ ] Update hadrian bootstrap plans for the latest compiler releases:
* Update `hadrian/bootstrap/generate_bootstrap_plans` to include any new compiler releases in the last two major release series
* Drop any plans that are outside of the bootstrap support window
* Run `hadrian/bootstrap/generate_bootstrap_plans` and commit the files that it generates
* Update `bootstrap_matrix` in `.gitlab-ci.yml` to reflect the most recent minor release in each major series supported by bootstrapping
# Release checklist
* [ ] Ensure that the [Migration](https://gitlab.haskell.org/ghc/ghc/wikis/migration/) page is up-to-date
* [ ] Push a provision provisional release commit to trigger the release builds using `git push -o ci.variable="RELEASE_JOB=yes"`
* [ ] Wait until builds finish; verify that they finished successfully
* [ ] Fetch release artifacts TODO: documentation
* [ ] Write down a link to the release pipeline here: <URL>
* [ ] Sign and push release artifacts to `downloads.haskell.org` [TODO: documentation]
* [ ] Submit `ghcup` metadata upstream:
* Manually trigger the `ghcup-metadata-testing-release` job of the release pipeline
* Download the `metadata_test.yaml` artifact from the `ghcup-metadata-release` job of the release pipeline
* Clone [`ghcup-metadata`](https://github.com/haskell/ghcup-metadata/)
* Integrate the appropriate release section into `ghcup-metadata/ghcup-0.0.7.yaml` (or `ghcup-prerelease-0.0.7.yaml` for pre-releases)
* Replace the `&id<n>` identifiers with unique names
* Add the `Latest` (or `LatestPrerelease`) to the new release's `viTags` field
* Remove `Latest` for the previous release's `viTags` field; for pre-releases add the `Prerelease` tag)
* Add the `base-w.x.y.z` (e.g. `base-4.19.0.0`) tag to `viTags`
* Sign the resulting metadata YAML file with `gpg --detach-sign`
* Open a merge request submitting the metadata upstream
* Start a "Bindist installation" [workflow](https://github.com/haskell/ghcup-metadata/actions/workflows/bindists.yaml)
* [ ] [Make a release tag](https://gitlab.haskell.org/ghc/ghc/wikis/making-releases#tagging-the-release)
* [ ] Release/revise GHC-maintained libraries on Hackage using [this script](https://gitlab.haskell.org/ghc/ghc/-/blob/master/.gitlab/upload_ghc_libs.py):
* [ ] `libraries/base`
* [ ] `libraries/ghc-prim`
* [ ] `libraries/array`
* [ ] `libraries/stm`
* [ ] `libraries/ghc-heap`
* [ ] `libraries/ghc-compact`
* [ ] `libraries/ghc-boot`
* [ ] `libraries/ghc-boot-th`
* [ ] `libraries/hpc`
* [ ] `libraries/libiserv`
* [ ] `libraries/template-haskell`
* [ ] `libraries/ghc-bignum`
* [ ] Update ghc/homepage>:
* [ ] Write download page (see ghc/homepage>)
* [ ] Make sure that the Signing Key is correct for the relevant release
* [ ] Add news item to [`index.html`](https://gitlab.haskell.org/ghc/homepage/blob/master/index.shtml)
* [ ] Add link to [`download.shtml`](https://gitlab.haskell.org/ghc/homepage/blob/master/download.shtml). Be sure to link to the Migration guide.
* [ ] Look over changes locally
* [ ] Add release announcement to [GHC blog](https://gitlab.haskell.org/ghc/homepage/tree/master/blog). Be sure to link to the Migration guide.
* [ ] Push changes to `master`
* [ ] Announce on: `GHC developers <ghc-devs@haskell.org>, GHC Users <glasgow-haskell-users@haskell.org>, Haskell Cafe <haskell-cafe@haskell.org>`
* Mention sponsors
* Mention ghc/ghc-hq>
* Link to release notes and migration guide
* [ ] Announce on: [Haskell Discourse](https://discourse.haskell.org/), [/r/haskell](https://reddit.com/r/haskell), [/m/haskell](https://kbin.social/m/haskell)
* [ ] When releasing the latest version, update `latest` symlink on `downloads.haskell.org`, e.g. `ln -sfT 9.6.3 latest` if 9.6 was the latest major series.
# Post-release checklist
* [ ] Update the Wiki [status page](https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-Status)
* [ ] Update the [language pragma history](https://gitlab.haskell.org/ghc/ghc/wikis/language-pragma-history)
* [ ] Mark milestone as *closed*
* [ ] Update `/topic` in `#ghc`
* [ ] Update the [VersionHistory](https://gitlab.haskell.org/ghc/ghc/wikis/commentary/libraries/version-history) wiki page
* [ ] Set `RELEASE=NO`
* [ ] Create a release tracking ticket for the next release using the template in #16816https://gitlab.haskell.org/ghc/ghc/-/issues/24497JS: putStrLn is executed asynchronously in browser2024-03-05T14:47:50ZStefano DebenedettiJS: putStrLn is executed asynchronously in browser## Summary
The `console.log` generated by the JS backend for a `putStrLn` is executed asynchronously in browsers.
## Steps to reproduce
See attached repro case `Test.hs`.
```
$ rm -rf Test Test.hi Test.o Test.jsexe; javascript-unknow...## Summary
The `console.log` generated by the JS backend for a `putStrLn` is executed asynchronously in browsers.
## Steps to reproduce
See attached repro case `Test.hs`.
```
$ rm -rf Test Test.hi Test.o Test.jsexe; javascript-unknown-ghcjs-ghc-9.8.2 -v -dcore-lint Test.hs > ghc.log 2>&1 && ./Test
one
two
```
Loading `Test.jsexe/index.html` is a browser and opening the JS console log will show:
```
two all.js:44450:24
one all.js:8575:17
```
## Expected behavior
The `putStrLn` to be executed synchronously, as in the native backend and as interpreted by `nodejs`.
## Environment
* GHC version used: 9.8.2 JS backend
* Nodejs version used: v20.11.0
* Google Chrome version used: 121.0.6167.184 (Official build) (64 bit)
* Mozilla Firefox version used: 123.0 (64 bit)
Optional:
* Operating System:
* System Architecture:
```
$ uname -a
Linux abcde 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
```
[Test.hs](/uploads/9c99ee468d81f5bbe52db4dd3ed0ee90/Test.hs)
[ghc.log](/uploads/22b8f9f05f09e7d729fd17499c5b9a41/ghc.log)https://gitlab.haskell.org/ghc/ghc/-/issues/24495Javascript backend -O1 breaks referential transparency in a function having a...2024-03-26T16:52:40ZStefano DebenedettiJavascript backend -O1 breaks referential transparency in a function having a Double argument and doing String concatenation## Summary
A pure `String` value shows up as two different values when output via `putStrLn` and via `console.log`.
The following factors seem to concur in triggering this behaviour:
* The optimization level is `-O1` (does not happen ...## Summary
A pure `String` value shows up as two different values when output via `putStrLn` and via `console.log`.
The following factors seem to concur in triggering this behaviour:
* The optimization level is `-O1` (does not happen with `-O0` or `-O2`)
* The affected function has a `Double` argument (does not happen if the argument is `Int`, see the commented `testInt` function in the repro case)
* The `String` concatenation has certain characteristics (eg. does not happen for the commented `testDouble2` function in the repro case and for other similar tweaks to the `String` concatenation)
## Steps to reproduce
See attached repro case `Test.hs`.
```
$ for i in $(seq 0 2); do rm -rf Test Test.hi Test.o Test.jsexe; echo compiling with -O$i; javascript-unknown-ghcjs-ghc-9.8.2 -v -O$i -dcore-lint Test.hs > ghc.log.O$i 2>&1; echo results with -O$i; ./Test; done
compiling with -O0
results with -O0
1 ab bd
2 ab bd
compiling with -O1
results with -O1
1 ab bd
2 ab
compiling with -O2
results with -O2
1 ab bd
2 ab bd
```
Loading `index.html` in a web browser also exhibits the same behaviour in the JS console log.
## Expected behavior
The program's output to be identical regardless of the optimization level. The second part of the second line of the `-O1` results to be the same as the second part of the first line, i.e. `"ab bd"` instead of just `"ab "`.
## Environment
* GHC version used: 9.8.2 JS backend
* Nodejs version used: v20.11.0
* Google Chrome version used: 121.0.6167.184 (Official build) (64 bit)
Optional:
* Operating System:
* System Architecture:
```
$ uname -a
Linux abcde 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
```Sylvain HenrySylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/24494A type equality constraint is necessary despite GHC warning that it's redundant2024-03-05T17:42:19ZMikolaj KonarskiA type equality constraint is necessary despite GHC warning that it's redundant## Summary
The first [type equality](https://github.com/Mikolaj/horde-ad/blob/b42aeabc0cb9fdbc8933ddd444143d008a5b986f/src/HordeAd/Core/Engine.hs#L308) in this type signature
```hs
cfwd
:: forall r y f vals advals.
( RankedOf f ...## Summary
The first [type equality](https://github.com/Mikolaj/horde-ad/blob/b42aeabc0cb9fdbc8933ddd444143d008a5b986f/src/HordeAd/Core/Engine.hs#L308) in this type signature
```hs
cfwd
:: forall r y f vals advals.
( RankedOf f ~ Flip OR.Array
, AdaptableHVector (ADVal (Flip OR.Array)) advals
, AdaptableHVector (ADVal (Flip OR.Array)) (ADVal f r y)
, AdaptableHVector (Flip OR.Array) vals
, AdaptableHVector (Flip OR.Array) (f r y)
, DualNumberValue advals, vals ~ DValue advals )
=> (advals -> ADVal f r y) -> vals -> vals -> f r y
```
is reported as redundant by GHC 9.8.1 (with both -O0 and -O1, with GHC 9.6.4 only with -O1) but the typing fails with the equality removed with
```
test/simplified/TestAdaptorSimplified.hs:1629:22: error: [GHC-40404]
• Reduction stack overflow; size = 201
When simplifying the following type:
Show
(HordeAd.Core.Delta.DeltaS
(ShapedOf
@GHC.TypeNats.Nat
(RankedOf
@[GHC.TypeNats.Nat]
(ShapedOf
@GHC.TypeNats.Nat
(RankedOf
@[GHC.TypeNats.Nat]
(ShapedOf
```
etc.
## Steps to reproduce
Checkout https://github.com/Mikolaj/horde-ad/blob/b42aeabc0cb9fdbc8933ddd444143d008a5b986f.
Run with GHC 9.8.1 or later (probably):
```
cabal test simplifiedOnlyTest -ftest_seq --test-options='-p 4Sin' --allow-newer --disable-optimization
```
After a dozen files tt should warn the equality is redundant and after another dozen it should start running the tests (all run fine). Remove the equality, run again, a few files later the error from above should pop up.
## Expected behavior
I have no idea if the type equality is really needed (or maybe a much weaker equality would be enough, e.g., `RankedOf (ShapedOf ranked) ~ ranked`?). I expect GHC to tell what it is so that I don't have to think.
## Environment
* GHC version used: 9.8.1 and 9.6.4https://gitlab.haskell.org/ghc/ghc/-/issues/24491Add a --test-ways flag to hadrian2024-03-05T14:36:55ZTeo CamarasuAdd a --test-ways flag to hadrianThis is a small idea to improve hadrian. Have a `--test-ways=<way>(,<way>)*` flag that allows specifying multiple ways at the same time rather than having to use several `--test-way=way1 --test-way=way2` options.This is a small idea to improve hadrian. Have a `--test-ways=<way>(,<way>)*` flag that allows specifying multiple ways at the same time rather than having to use several `--test-way=way1 --test-way=way2` options.https://gitlab.haskell.org/ghc/ghc/-/issues/24488TypeAbstractions example produces a parse error2024-03-09T17:48:33ZJkensikTypeAbstractions example produces a parse error## Summary
The example from the documentation
`
f5 :: [forall a. a -> a -> a]
f5 = [ \ @a x _ -> x :: a,
\ @a _ y -> y :: a ]
`
gives the error
error: [GHC-58481] parse error on input ‘@’
|
26 | f5 = [ \ @a x _ -> x :: a,
...## Summary
The example from the documentation
`
f5 :: [forall a. a -> a -> a]
f5 = [ \ @a x _ -> x :: a,
\ @a _ y -> y :: a ]
`
gives the error
error: [GHC-58481] parse error on input ‘@’
|
26 | f5 = [ \ @a x _ -> x :: a,
## Environment
GHC9.8.2Vladislav ZavialovVladislav Zavialovhttps://gitlab.haskell.org/ghc/ghc/-/issues/24487regression with 9.6/9.8, observed as heap usage but could be due to behavior ...2024-03-13T19:35:39Zquarkregression with 9.6/9.8, observed as heap usage but could be due to behavior change## Summary
The [Bluespec Compiler (bsc)](github.com/b-lang-org/bsc) is compiled with GHC and we have observed a regression in our testsuite when using GHC 9.6 and 9.8 (including recent 9.8.2), that was not a failure with GHC 9.4 and ear...## Summary
The [Bluespec Compiler (bsc)](github.com/b-lang-org/bsc) is compiled with GHC and we have observed a regression in our testsuite when using GHC 9.6 and 9.8 (including recent 9.8.2), that was not a failure with GHC 9.4 and earlier.
Specifically, in the BSC repo, in directory `/testsuite/bsc.bugs/bluespec_inc/b1490/`, there are two tests which exhaust the heap when set with `-M256` but execute fine when it is increased with `+RTS -M260` and `+RTS -M265`. However, with earlier versions of GHC (such as 9.4.8), the heap size can be reduced dramatically and it still executes without exhausting the heap, even down to `-M4K`!
Something clearly changed in GHC, but I don't think it's necessarily directly related to heap usage; I would guess that maybe a code optimization has changed the behavior, and it is resulted in BSC using more heap. I say that because BSC is itself a compiler, and the test cases which are now failing are tests that involve a for-loop in the Bluespec design being compiled, and the tests are checking that BSC is able to unroll the loops and properly prune the growing structure so that it doesn't explode. The heap usage could be because BSC is now failing to properly prune, as a result of a behavior change resulting from a change in GHC.
However, I don't know how to diagnose this. Are there RTS flags that can dump information about heap usage, that I can compare between GHC versions? I can use `+RTS -s`, but it doesn't show max heap usage, and the info that it does show isn't significantly different between GHC 9.8 and 9.4.
I assume that a binary search of the GHC commits might find the point where the issue was introduced, but each iteration would take a while.
Any advice you can provide on how to investigate this would be appreciated.
## Steps to reproduce
BSC is a large program, but if you want to reproduce, you can do this:
```
git clone --recursive https://github.com/B-Lang-org/bsc
cd bsc
make install-src
cd testsuite/bsc.bugs/bluespec_inc/b1490/
../../../../inst/bin/bsc -verilog Bug1490MyUnion.bsv +RTS -M256M
```
The result of running BSC in the last line is (when compiled with 9.8 or 9.6):
```
bsc: Heap exhausted;
bsc: Current maximum heap size is 268435456 bytes (256 MB).
bsc: Use `+RTS -M<size>' to increase it.
```
## Expected behavior
I expect BSC to run to completion and output a message like this (which is what you get with GHC 9.4.8 and earlier version):
```
Verilog file created: module_arbitrate_myunion.v
```
In fact, with GHC 9.4.8 (and presumably earlier), the heap can be reduced significantly and BSC still executes fine:
```
../../../../inst/bin/bsc -verilog Bug1490MyUnion.bsv +RTS -M4K
```
With GHC 9.6 and 9.8, the heap needs to be increased to around 260 or 265, for it to compile. This difference between essentially nothing (4K) and 260M seems significant, and so I felt it was worth reporting (particularly if the heap is just a sympton and that it's due to a bug in behavior).
## Environment
* GHC versions that fail: 9.8.2, 9.8.1, 9.6.4, 9.6.2
* GHC versions that work: 9.4.8 (and many earlier versions)
* Operating System: My results reported here are on macOS 11, but the same failures were seen on GitHub VMs for Ubuntu 22.04 and macOS 12
* System Architecture: x86_64
We have been using various versions of GHC in our CI over the last few years and had not noticed an issue up through 9.4.x (on various Ubuntu and macOS VMs). We then tested with 9.8.1 (on Ubuntu 22.04 and macOS 12) and saw the error. Today, on my macOS 11 system, I confirmed that 9.8.1 fails and that the recently released 9.8.2 also fails, and I checked 9.6.2 and 9.6.4 and saw that they also failed. So I would guess that the issue was introduced in 9.6. I confirm that we currently do not observe the failure when using 9.4.8 (on Ubuntu 20.04 and 22.04 and macOS 11, 12, and 13).https://gitlab.haskell.org/ghc/ghc/-/issues/24486ignored unrecognised input when compiling with a plugin2024-03-05T14:33:15ZMarcin Szamotulskiignored unrecognised input when compiling with a plugin## Summary
When I compile a package with `ghc-tags-plugin` enabled, e.g. passing the following options (one will need to modify it depending on your system):
```
package io-classes
ghc-options: -package-db=/home/coot/.local/state/caba...## Summary
When I compile a package with `ghc-tags-plugin` enabled, e.g. passing the following options (one will need to modify it depending on your system):
```
package io-classes
ghc-options: -package-db=/home/coot/.local/state/cabal/store/ghc-9.6.4/package.db/
-plugin-package=ghc-tags-plugin-0.6.1.0
-fplugin=Plugin.GhcTags
-fplugin-opt=Plugin.GhcTags:../tags
```
I am getting the following warnings:
```
Warning: ignoring unrecognised input `/home/coot/clients/iog/io-sim/dist-newstyle/build/x86_64-linux/ghc-9.6.4/io-classes-1.4.1.0/build/Control/Concurrent/Class/M
onadMVar.dyn_o'
...
```
It doesn't really matter what package I try to compile; I haven't tried to use any other plugin, but I don't get that warning when I disable the `ghc-tags-plugin`.
## Steps to reproduce
Given above. To install `ghc-tags-plugin` follow instruction in the [readme](https://github.com/coot/ghc-tags-plugin/)
## Expected behavior
No warning.
## Environment
* GHC version used: `ghc-9.6.4`
Optional:
* Operating System: Linux
* System Architecture: x86_649.10.2ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24485Sort out haddock hyperlinked-sources links2024-03-26T17:46:45ZBen GamariSort out haddock hyperlinked-sources linksCurrently Haddock's hyperlinked sources [fails to account](https://github.com/haskell/haddock/issues/1628) for declaration reexports correctly. This needs to be addressed for 9.10.1 to avoid compromising `base` documentation due to the `...Currently Haddock's hyperlinked sources [fails to account](https://github.com/haskell/haddock/issues/1628) for declaration reexports correctly. This needs to be addressed for 9.10.1 to avoid compromising `base` documentation due to the `ghc-internal` split.9.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24483Can't re-export duplicate field names from identical constructor names2024-03-29T08:20:01ZTom EllisCan't re-export duplicate field names from identical constructor namesThis is a new ticket to track [an issue explained by @adamgundry](https://gitlab.haskell.org/ghc/ghc/-/issues/13352#note_294968) in a prior (closed) ticket. That is, the following code leads to the following error. The error is still pr...This is a new ticket to track [an issue explained by @adamgundry](https://gitlab.haskell.org/ghc/ghc/-/issues/13352#note_294968) in a prior (closed) ticket. That is, the following code leads to the following error. The error is still present as of GHC 9.8. It seems like an artificial limitation and it would be great if it could be lifted. This is particularly annoying if we want to create a custom `Prelude`. It makes it impossible to create a custom `Prelude` containing two different fields with the same name, if their constructors also share the same name.
```
{-# LANGUAGE DuplicateRecordFields #-}
module A where
data S = C { foo :: Int }
{-# LANGUAGE DuplicateRecordFields #-}
module B where
data T = C { foo :: Int }
{-# LANGUAGE DuplicateRecordFields #-}
module C (S(foo), T(foo)) where
import A (S(..))
import B (T(..))
```
```
Conflicting exports for ‘foo’:
‘S(foo)’ exports ‘foo’
imported from ‘A’ at C.hs:5:28-32
(and originally defined at A.hs:3:16-18)
‘T(foo)’ exports ‘foo’
imported from ‘B’ at C.hs:6:28-32
(and originally defined at B.hs:5:14-16)
```
----
It's also an interesting puzzle to try to imagine the implementation details that allow both `foo`s to be used within the same module but not re-exported from the same module! I haven't been able to work it out ...
EDIT: Ah, I think I have an explanation: in a given module, duplicate field names are disambiguated by the module they were imported from plus the constructor name.https://gitlab.haskell.org/ghc/ghc/-/issues/24481Support NoFieldSelectors as a datatype and field annotation2024-02-26T09:45:21ZAdam GundrySupport NoFieldSelectors as a datatype and field annotationThe GHC Steering Committee has accepted [proposal 512: NoFieldSelectors as a datatype and field annotation](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0512-nofieldselectors-per-datatype.md). This makes it possib...The GHC Steering Committee has accepted [proposal 512: NoFieldSelectors as a datatype and field annotation](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0512-nofieldselectors-per-datatype.md). This makes it possible to annotate individual datatypes or fields as to whether they should use `FieldSelectors` or `NoFieldSelectors`.https://gitlab.haskell.org/ghc/ghc/-/issues/24480cannot bootstrap ghc-9.8.2 with ghc-9.8.12024-02-27T15:46:55Zjwaldmanncannot bootstrap ghc-9.8.2 with ghc-9.8.1## Summary
Failure to build 9.8.2 from source (tarball from https://downloads.haskell.org/ghc/9.8.2/) with 9.8.1 as the bootstrap compiler. Failure because of versions of dependencies for building hadrian.
Don't know if it's supposed t...## Summary
Failure to build 9.8.2 from source (tarball from https://downloads.haskell.org/ghc/9.8.2/) with 9.8.1 as the bootstrap compiler. Failure because of versions of dependencies for building hadrian.
Don't know if it's supposed to work. Probably not, as the same thing happens when bootstrapping 9.8.1 with itself.
Building 9.8.2 with 9.6.4 looks good.
## Steps to reproduce
```
$ ./configure
$ ./hadrian/build -j binary-dist-dir --docs=no-sphinx
Warning: Requested index-state 2023-03-30T10:00:00Z is newer than
'hackage.haskell.org'! Falling back to older state (2023-03-30T08:23:24Z).
Resolving dependencies...
Error: cabal: Could not resolve dependencies:
[__0] trying: hadrian-0.1.0.0 (user goal)
[__1] trying: hadrian:+selftest
[__2] trying: QuickCheck-2.14.2 (dependency of hadrian +selftest)
[__3] trying: splitmix-0.1.0.4 (dependency of QuickCheck)
[__4] next goal: base (dependency of hadrian)
[__4] rejecting: base-4.19.0.0/installed-inplace (conflict: splitmix =>
base>=4.3 && <4.19)
...
[__4] fail (backjumping, conflict set: base, hadrian, splitmix)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, QuickCheck, splitmix, hadrian,
hadrian:selftest
```
## Environment
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.8.1
$ cabal --version
cabal-install version 3.10.2.1
compiled using version 3.10.1.0 of the Cabal library
$ uname -a
Linux ...... 6.1.0-17-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30) x86_64 GNU/Linux
```Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24478Move command line flags out of `GHC.Driver.Session`2024-03-29T14:34:34ZJadeMove command line flags out of `GHC.Driver.Session`Related to #24477:
Move flag specific stuff out of `GHC.Driver.Session`
This enables importing constants (such as the implied extensions) without needing to resolve import cycles.Related to #24477:
Move flag specific stuff out of `GHC.Driver.Session`
This enables importing constants (such as the implied extensions) without needing to resolve import cycles.https://gitlab.haskell.org/ghc/ghc/-/issues/24477When suggesting Language Extensions, also suggest Extensions which imply them2024-03-29T14:34:34ZJadeWhen suggesting Language Extensions, also suggest Extensions which imply themGHC sometimes suggests enabling language extensions. In some cases, the user might not have wanted just that extension, but an extension which implies it.
So far, this is done more-or-less when suggesting `forall` without `-XExplicitFo...GHC sometimes suggests enabling language extensions. In some cases, the user might not have wanted just that extension, but an extension which implies it.
So far, this is done more-or-less when suggesting `forall` without `-XExplicitForAll`. Here the suggested fix is:
```
Perhaps you intended to use RankNTypes
or a similar language extension to enable explicit-forall syntax: forall <tvs>. <type>
```
!12112 seeks to improve this and instead suggest
```
Use ExplicitForAll (implied by RankNTypes and ScopedTypeVariables)
to enable syntax: forall <tvs>. <type>
```
I think it could make sense to add this in general whenever a language extension is suggested that has others that imply it. This would for example, when suggesting `ExplicitNamespaces` add `(implied by TypeFamilies and TypeOperators)`.
As for the implementation of this change there are problems, specifically that importing `GHC.Driver.Session(impliedXFlags)` from `GHC.Types.Hint.Ppr` leads to various module dependency cycles.
@bgamari suggested to move flags from `GHC.Driver.Session`: #24478JadeJade