-
86a646a6
by Andreas Klebinger at 2026-04-22T13:00:05-04:00
Revert use of generic instances for compiler time perf reasons.
Revert "Derive Semigroup/Monoid for instances believed could be derived in #25871"
This reverts commit 11a04cbb221cc404fe00d65d7c951558ede4caa9.
Revert "add Ghc.Data.Pair deriving"
This reverts commit 15d9ce449e1be8c01b89fd39bdf1e700ea7d1dce.
-
bc9ee1cf
by Wen Kokke at 2026-04-22T13:00:51-04:00
hadrian: Fix docs to remove static flavour
In 638f6548, the static flavour was turned into into the fully_static
flavour transformer. However, this commit did not update flavours.md.
-
cc9cc6d5
by Cheng Shao at 2026-04-23T09:40:46+00:00
configure: bump LlvmMaxVersion to 23
This patch bumps `LlvmMaxVersion` to 23 to support LLVM 22.x releases.
-
2ea7ef8e
by Cheng Shao at 2026-04-23T09:46:26+00:00
changelog: add llvm 22.x support
-
5574ee10
by Cheng Shao at 2026-04-24T08:24:30-04:00
compiler: avoid unused temporary `appendFS` operands
This patch fixes unused temporary `appendFS` operands in the codebase
that are retained in the `FastString` table after concatenation.
Rewrite rules are added so that if an operand is
`fsLit`/`mkFastString`, the `appendFS` application is rewritten to
append the `ShortByteString` operands first. The patch also fixes
`sconcat` behavior to align with `mconcat` for the same reason. Fixes #27205.
-
4ed78760
by mangoiv at 2026-04-24T08:25:13-04:00
contributing: adjust MR template to be less verbose
- MR template only shows text that is relevant for submissiong
- MR template was rewritten so it's readable from a user's and reviewer's
perspective
Resolves #27165
Co-Authored-By: @sheaf
-
87db83e2
by Cheng Shao at 2026-04-24T14:37:21-04:00
ci: bump freebsd boot ghc to 9.10.3
This commit bumps freebsd boot ghc to 9.10.3 to align with other
platforms and prevent outdated boot libs in boot ghc to block the
freebsd job.
-
17e3a0b7
by Cheng Shao at 2026-04-24T14:37:21-04:00
compiler: improve Binary instance of Array
This patch improves the `Binary` instance of `Array`:
- We no longer allocate intermediate lists. When serializing an
`Array`, we iterate over the elements directly; when deserializing
it, we allocate the result `Array` and fill it in a loop.
- Now we only serialize the array bounds tuple; the length field is
not needed.
Closes #27109.
-
2d30f7d3
by sheaf at 2026-04-24T14:38:23-04:00
Vendor mini-QuickCheck for testsuite
This commit extracts the vendored QuickCheck implementation from the
foundation testsuite to make it more broadly available in the GHC
testsuite, and makes use of it in the simd006 test (which also used
a vendored QuickCheck implementation).
On the way, we update the linear congruential generator to avoid the
shortcoming of only generating 31 bit large numbers.
Fixes #25990 and #25969.
-
ef41cde7
by fendor at 2026-04-26T11:23:51+02:00
Expose startupHpc as an rts symbol
-
bb1cc992
by fendor at 2026-04-26T11:23:52+02:00
Make HPC work with bytecode interpreter
Add support to generate .tix files from bytecode objects and the
bytecode interpreter.
Conceptually, we insert HPC ticks into the bytecode similar to how we insert
breakpoints.
HPC and breakpoints do not share the same tick array but we use a separate
tick-array for hpc/breakpoint ticks during bytecode generation.
We teach the bytecode interpreter to handle hpc ticks.
The implementation is quite trivial, simply increment the counter in the
global hpc_ticks array for the respective module.
This hpc_ticks array is generated as part of the `CStub`, so we can rely
on it existing.
A tricky bit is "registering" a bytecode object for HPC instrumentation.
In the compiled case, this is achieved via CStub and initializer/finalizers
`.init` sections which are called when the executable is run.
After the initializers have been invoked, which is before `hs_init_ghc`,
we then call `startup_hpc` in `hs_init_ghc` iff any modules were "registered"
for hpc instrumentation via `hs_hpc_module`.
Since bytecode objects are loaded after starting up GHCi, this workflow
doesn't work for supporting `hpc` and the `hpc` run-time is never
started, even if a module is added for instrumentation.
We fix this issue by employing the same technique as is for `SptEntry`s:
* We introduce a new field to `CompiledByteCode`, called `ByteCodeHpcInfo`
which contains enough information to call `hs_hpc_module`, allowing us to
register the module for `hpc` instrumentation`.
* After registering the module, we unconditionally call `startupHpc`, to make
sure the .tix file is written.
Calling `startupHpc` multiple times is safe.
Calling `hs_hpc_module` multiple times for the same module is also safe.
If we didn't register the hpc module in this way, evaluating a bytecode object
instrumented with `-fhpc` without registering it in the `hpc` run-time will
simply not generate any `.tix` files for this bytecode object.
However, this shouldn't happen if everything is set up correctly.
Closes #27036