GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-12T14:44:58Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24523`rts-1.0.2.conf` (or earlier) specifies `rts.haddock` but no such file ships ...2024-03-12T14:44:58ZMike Pilgrem`rts-1.0.2.conf` (or earlier) specifies `rts.haddock` but no such file ships with GHC## Summary
Since GHC 9.0.1 (at least, on Windows*), the `rts-1.0.2.conf` file (or its equivalent) has specified a `rts.haddock` file (in key `haddock-interfaces`) but no such file is provided with GHC. Before GHC 9.0.1, the `rts.conf` f...## Summary
Since GHC 9.0.1 (at least, on Windows*), the `rts-1.0.2.conf` file (or its equivalent) has specified a `rts.haddock` file (in key `haddock-interfaces`) but no such file is provided with GHC. Before GHC 9.0.1, the `rts.conf` file did not specify a `*.haddock` file.
*I also looked inside the `*.tar.xz` file for GHC 9.8.2/x86_64/Alpine Linux 3.12 (dynamically linked). I think the same is true for Linux.
## Expected behavior
Either the `*.conf` file does not specify a `*.haddock` file or that the specified `rts.haddock` file is provided with GHC.
## Environment
* GHC version used: 9.0.1 to 9.8.2.
Optional:
* Operating System: Windows
* System Architecture: x86_64ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24519CmmToAsm/x86: Poor unrolling for unaligned memcpy2024-03-20T14:58:37ZMatthew Cravenclyring@gmail.comCmmToAsm/x86: Poor unrolling for unaligned memcpyCompile the following module, and look at the generated assembly:
```haskell
module Memcpy where
import Foreign
import Data.Word
fun :: Ptr Word8 -> Ptr Word8 -> IO ()
fun p q = copyBytes p q 16
```
When I compile with `ghc-9.8.2 -O ...Compile the following module, and look at the generated assembly:
```haskell
module Memcpy where
import Foreign
import Data.Word
fun :: Ptr Word8 -> Ptr Word8 -> IO ()
fun p q = copyBytes p q 16
```
When I compile with `ghc-9.8.2 -O -dno-typeable-binds Memcpy.hs -S` on my x86-64 machine, this is what I see:
<details>
```asm
.section .text
.align 8
.align 8
.quad 12884901903
.quad 0
.long 14
.long 0
.globl Memcpy_fun1_info
.type Memcpy_fun1_info, @function
Memcpy_fun1_info:
.LcRu:
leaq -16(%rbp),%rax
cmpq %r15,%rax
jb .LcRy
.LcRz:
movq $.LcRr_info,-16(%rbp)
movq %r14,%rbx
movq %rsi,-8(%rbp)
addq $-16,%rbp
testb $7,%bl
jne .LcRr
.LcRs:
jmp *(%rbx)
.align 8
.quad 1
.long 30
.long 0
.LcRr_info:
.LcRr:
movq $.LcRx_info,(%rbp)
movq 7(%rbx),%rax
movq 8(%rbp),%rbx
movq %rax,8(%rbp)
testb $7,%bl
jne .LcRx
.LcRB:
jmp *(%rbx)
.align 8
.quad 65
.long 30
.long 0
.LcRx_info:
.LcRx:
movq 8(%rbp),%rax
movq 7(%rbx),%rbx
;; !!!
movb 0(%rbx),%cl
movb %cl,0(%rax)
movb 1(%rbx),%cl
movb %cl,1(%rax)
movb 2(%rbx),%cl
movb %cl,2(%rax)
movb 3(%rbx),%cl
movb %cl,3(%rax)
movb 4(%rbx),%cl
movb %cl,4(%rax)
movb 5(%rbx),%cl
movb %cl,5(%rax)
movb 6(%rbx),%cl
movb %cl,6(%rax)
movb 7(%rbx),%cl
movb %cl,7(%rax)
movb 8(%rbx),%cl
movb %cl,8(%rax)
movb 9(%rbx),%cl
movb %cl,9(%rax)
movb 10(%rbx),%cl
movb %cl,10(%rax)
movb 11(%rbx),%cl
movb %cl,11(%rax)
movb 12(%rbx),%cl
movb %cl,12(%rax)
movb 13(%rbx),%cl
movb %cl,13(%rax)
movb 14(%rbx),%cl
movb %cl,14(%rax)
movb 15(%rbx),%bl
movb %bl,15(%rax)
leaq ghczmprim_GHCziTupleziPrim_Z0T_closure+1(%rip),%rbx
addq $16,%rbp
jmp *(%rbp)
.LcRy:
leaq Memcpy_fun1_closure(%rip),%rbx
jmp *-8(%r13)
.size Memcpy_fun1_info, .-Memcpy_fun1_info
.section .data
.align 8
.align 1
.globl Memcpy_fun1_closure
.type Memcpy_fun1_closure, @object
Memcpy_fun1_closure:
.quad Memcpy_fun1_info
.section .text
.align 8
.align 8
.quad 12884901903
.quad 0
.long 14
.long 0
.globl Memcpy_fun_info
.type Memcpy_fun_info, @function
Memcpy_fun_info:
.LcRU:
jmp Memcpy_fun1_info
.size Memcpy_fun_info, .-Memcpy_fun_info
.section .data
.align 8
.align 1
.globl Memcpy_fun_closure
.type Memcpy_fun_closure, @object
Memcpy_fun_closure:
.quad Memcpy_fun_info
.section .note.GNU-stack,"",@progbits
.ident "GHC 9.8.2"
```
</details>
Notice the 32 single-byte `movb` instructions used to implement the copy. (I have marked this with `!!!`.)
We are probably using single-byte move instructions because the given `Ptr`s can have arbitrary alignment. But on x86-64, the penalty for an unaligned `movq` is typically at most a few cycles. It would be much better for both speed and code size to emit four eight-byte move instructions or even two unaligned 16-byte move instructions. (There are a few of the latter in SSE and SSE2, which we assume are available on every x86-64 machine.) And indeed I see the latter if I also add `-fllvm`.
I haven't checked, but would not be surprised if there were similar opportunities for improvement available on other platforms.https://gitlab.haskell.org/ghc/ghc/-/issues/24518Update Cabal to version 3.10.3.0 for GHC-9.6 and GHC-9.82024-03-21T13:19:34ZTrevis ElserUpdate Cabal to version 3.10.3.0 for GHC-9.6 and GHC-9.8## Summary
At the most user facing level, plugins appear to not work correctly with 9.6/9.8 when using `stack`. The issue on that side is tracked https://github.com/commercialhaskell/stack/issues/6251. However, it would appear that the ...## Summary
At the most user facing level, plugins appear to not work correctly with 9.6/9.8 when using `stack`. The issue on that side is tracked https://github.com/commercialhaskell/stack/issues/6251. However, it would appear that the underlying issue is with the `Cabal` library. The issue for `Cabal` is at https://github.com/haskell/cabal/issues/9375. The fix for this is included in `cabal-3.10.3.0`~~, which ghc-9.10 appears to be ahead of~~.
So if I'm understanding the various moving parts all correctly bumping the included `Cabal` version for the next 9.6 and 9.8 series releases will fix the issue. As it stands, this is holding some users on 9.4.x.
## Steps to reproduce
From the cabal issue, reproducing would appear to be as simple as having a plugin module Foo and then running:
```
ghc-9.6.3 --abi-hash -fplugin=Foo
```
Which would result in:
```
<command line>: Could not find module ‘Foo’
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
```
## Expected behavior
The expectation would be to have a hash from the above.
@mpickering I'm tagging you because you commented here: https://github.com/haskell/cabal/issues/9375#issuecomment-1789748616 and almost certainly have more context/understanding than I do on the internal implications of this.9.6.5ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24517Provide RTS statistics in GHC.Stats, for example number of blocked threads etc2024-03-14T10:40:51ZliteronProvide RTS statistics in GHC.Stats, for example number of blocked threads etc## Motivation
The current GHC.Stats mainly exposes GC details, and memory usage details. But it doesn't expose anything about number of running/blocked... threads? It can be insightful when troubleshooting production issues to see for e...## Motivation
The current GHC.Stats mainly exposes GC details, and memory usage details. But it doesn't expose anything about number of running/blocked... threads? It can be insightful when troubleshooting production issues to see for example that the number of blocked threads (for example blocked on some MVar / TVar) have suddenly increased.
Now, I have no idea what of this kind of thread/MVar/TVar/.. stats is feasible to collect/expose in the runtime, but the more the merrier.
## Proposal
Basically adding new stats fields about threads or synchronization primitives (STM retry counts, whatever).
Note that these are preferred in a Prometheus-friendly incremental counter format, like many of the memory-related stats already are.https://gitlab.haskell.org/ghc/ghc/-/issues/24511GHCI missing new line on Windows WSL 2.0 Debian Environment2024-03-13T00:45:55ZBrian TeagueGHCI missing new line on Windows WSL 2.0 Debian Environment## Summary
Expressions entered in the GHCI REPL interface do not create a newline character after pressing enter before the output is rendered.
```haskell
❯ ghci
GHCi, version 9.8.1: https://www.haskell.org/ghc/ :? for help
ghci> 1 + ...## Summary
Expressions entered in the GHCI REPL interface do not create a newline character after pressing enter before the output is rendered.
```haskell
❯ ghci
GHCi, version 9.8.1: https://www.haskell.org/ghc/ :? for help
ghci> 1 + 12
ghci> double x = x + xghci> double 24
ghci>
```
## Steps to reproduce
* Start Alacritty Terminal version 0.11.0 on windows
* Type command Debian to enter WSL environment
* Type GHCI to start the GHCI interpreter.
* Enter any expression and press enter.
## Expected behavior
Expected the GHCI interpreter to create a new line character after pressing enter before displaying the output
```haskell
❯ ghci
GHCi, version 9.8.1: https://www.haskell.org/ghc/ :? for help
ghci> 1 + 1
2
ghci> double x = x + x
ghci> double 2
4
ghci>
```
## Environment
│✔✔ GHCup 0.1.20.0 latest,recommended
│✔✔ Stack 2.13.1 recommended
│✔✔ HLS 2.5.0.0 recommended
│✔✔ cabal 3.10.2.1 latest,recommended
│✔✔ GHC 9.8.1 base-4.19.0.0 hls-powered,2023-10-09
## Optional:
### Operating System:
* WSL version: 2.0.9.0
* Kernel version: 5.15.133.1-1
* WSL image: Debian
* WSLg version: 1.0.59
* MSRDC version: 1.2.4677
* Direct3D version: 1.611.1-81528511
* DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
* Windows version: 10.0.19045.4046
### System Architecture: X86_64https://gitlab.haskell.org/ghc/ghc/-/issues/24510Generically's mappend should agree with the underlying (<>)2024-03-12T15:03:08ZIcelandjackGenerically's mappend should agree with the underlying (<>)There is unfortunate duplication of behaviours with `(<>)` and `mappend`, their meaning should always coincide but there are ways of making them out of sync. GeneralizedNewtypeDeriving is one way, but I wanted to discuss an error brought...There is unfortunate duplication of behaviours with `(<>)` and `mappend`, their meaning should always coincide but there are ways of making them out of sync. GeneralizedNewtypeDeriving is one way, but I wanted to discuss an error brought to my attention.
```haskell
{-# Language DerivingVia #-}
{-# Language DerivingStrategies #-}
import Data.Monoid
import Data.Map
import GHC.Generics
-- :set -XOverloadedLists
-- >> Foo [('a', "Hello")] `mappend` Foo [('a', "World")]
-- Foo (fromList [('a',"Hello")])
-- >> Foo [('a', "Hello")] <> Foo [('a', "World")]
-- Foo (fromList [('a',"HelloWorld")])
data Foo = Foo (Map Char String)
deriving stock (Show, Generic)
deriving Monoid via Generically Foo
instance Semigroup Foo where
Foo map <> Foo map1 = Foo (unionWith (<>) map map1)
```
The desired append operation is clearly the user-defined one: `unionWith (<>)`, but `Generically Foo` (wrongly) assumes that the user is deriving `Semigroup` generically as well: `(<>) @(Generically Foo)`.
```haskell
instance (Generic a, Monoid (Rep a ()) => Monoid (Generically a) where
..
mappend :: Generically a -> Generically a -> Generically a
mappend = (<>) @(Generically a)
```
Instead, I propose adding a `Semigroup a` constraint and making use of whatever `(<>)` method already exists. If the user derives `(<>)` generically, then `mappend` will also be generic. In this example, where the user has specified their own bespoke `(<>) = unionWith (<>)` that should be used for `mappend`.
We now see that both `mappend` and `(<>)` produce the same result:
```haskell
-- >> Foo [('a', "Hello")] `mappend` Foo [('a', "World")]
-- Foo (fromList [('a',"HelloWorld")])
-- >> Foo [('a', "Hello")] <> Foo [('a', "World")]
-- Foo (fromList [('a',"HelloWorld")])
instance (Generic a, Semigroup a, Monoid (Rep a ()) => Monoid (Generically a) where
..
mappend :: Generically a -> Generically a -> Generically a
mappend = coerce do (<>) @a
```https://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.2ZubinZubin