[Git][ghc/ghc][wip/romes/exceptions-propagate] 41 commits: Don't compile `asBox` with -fprof-late
Rodrigo Mesquita (@alt-romes)
gitlab at gitlab.haskell.org
Mon Sep 30 15:52:19 UTC 2024
Rodrigo Mesquita pushed to branch wip/romes/exceptions-propagate at Glasgow Haskell Compiler / GHC
Commits:
783c8b29 by Matthew Pickering at 2024-09-26T12:07:44-04:00
Don't compile `asBox` with -fprof-late
The `asBox` function is intended to store exactly the closure which the
user passes to it. Placing a cost centre on asBox introduces a thunk,
which violates this expectation and can change the result of using asBox
when profiling is enabled.
See #25212 for more details and ample opportunity to discuss if this is
a bug or not.
- - - - -
0967dcc7 by Matthew Pickering at 2024-09-26T12:07:44-04:00
Fix normalisation of .prof files
Fix 1: If a cost centre contained CAF then the normalisation was
corrupted, now only check if CAF is at the start of a line.
Fix 2: "no location info" contain a space, which messed up the next
normalisation logic which assumed that columns didn't have spaced in.
- - - - -
9eda1cb9 by Matthew Pickering at 2024-09-26T12:07:44-04:00
testsuite: Fix normalisation of prof_files removing newlines
These normalisation steps were collapsing lines together, which made
subsequent normalisation steps fail.
```
foo x y z
CAF x y z
qux x y z
```
was getting normalised to
```
foo x y z qux x y z
```
which means that subsequent line based filters would not work correctly.
- - - - -
2b25f9e2 by Matthew Pickering at 2024-09-26T12:07:44-04:00
packaging: Enable late-ccs for release flavour
This enables late cost centres when building profiled libraries and
subsequently greatly improves the resolution of cost centre stacks when
profiling.
This patch also introduces the `grep_prof` test modifier which is used
to apply a further filter to the .prof file before they are compared.
Fixes #21732
-------------------------
Metric Increase:
libdir
-------------------------
- - - - -
bb030d0d by Brandon Chinn at 2024-09-26T12:08:21-04:00
Replace manual string lexing (#25158)
Metric Increase:
MultilineStringsPerf
This commit replaces the manual string lexing logic with native Alex
lexing syntax. This aligns the lexer much closer to the Haskell Report,
making it easier to see how the implementation and spec relate. This
slightly increases memory usage when compiling multiline strings because
we now have two distinct phases: lexing the multiline string with Alex
and post-processing the string afterwards. Before, these were done at
the same time, but separating them allows us to push as much logic into
normal Alex lexing as possible.
Since multiline strings are a new feature, this regression shouldn't be
too noticeable. We can optimize this over time.
- - - - -
16742987 by Matthew Pickering at 2024-09-26T12:08:57-04:00
Revert !4655: Stop 'import "base" Prelude' removing implicit Prelude import
This behaviour is problematic for the principle reason that `import
Prelude` may not refer to the `base` package, and in which case
importing an entirely unrelated module causing your implicit prelude to
leave the scope is extremely surprising. See the added test for this
example. Discussion on #17045.
The secondary reason for reverting this patch is that "base" can't be a
wired in package any more (see #24903), so we have to remove special
logic which singles out base from the compiler.
The rule for implicit shadowing is now simply:
* If you write import Prelude (..) then you don't get an implicit prelude import
* If you write import "foobar" Prelude (..) for all pkgs foobar,
you get an implicit import of prelude.
If you want to write a package import of Prelude, then you can enable
`NoImplicitPrelude` for the module in question to recover the behaviour
of ghc-9.2-9.10.
Fixes #17045
- - - - -
57c50f41 by Matthew Pickering at 2024-09-26T12:08:57-04:00
Rename COMPILING_BASE_PACKAGE to COMPILING_GHC_INTERNAL_PACKAGE
The COMPILING_BASE_PACKAGE macro is concerned with issues defining
symbols and using symbols in the same compilation unit. However, these
symbols now exist in ghc-internal rather than base, so we should rename
the macro accordingly.
The code is guards is likely never used as we never produce windows DLLs
but it is simpler to just perform the renaming for now.
These days there is little doubt that this macro defined in this ad-hoc
manner would be permitted to exist, but these days are not those days.
Fixes #25221
- - - - -
70764243 by Matthew Pickering at 2024-09-26T12:08:57-04:00
Preload ghc-internal rather than base
This occurence of baseUnitId was missed when moving the bulk of internal
definitions into `ghc-internal`.
We need to remove this preloading of `base` now because `base` should
not be wired in.
Towards #24903
- - - - -
12915609 by Matthew Pickering at 2024-09-26T12:08:57-04:00
Remove Data.List compat warning
There is currently a warning implemented in -Wcompat which warns you
when importing Data.List in a non-qualified manner.
```
A.hs:3:8: warning: [-Wcompat-unqualified-imports]
To ensure compatibility with future core libraries changes
imports to Data.List should be
either qualified or have an explicit import list.
|
3 | import Data.List
| ^^^^^^^^^
Ok, one module loaded.
```
GHC ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/17244
CLC discussion: https://groups.google.com/g/haskell-core-libraries/c/q3zHLmzBa5E
This warning was implemented as part of the migration to making
Data.List monomorphic again (and to be used like Data.Set, Data.Map
etc). That doesn't seem like it happened, and I imagine that the current
CLC would require a new proposal anyway in order to do that now. It's
not clear in any case what "future core libraries changes" we are
waiting to happen before this warning can be removed.
Given the first phase of the proposal has lasted 5 years it doesn't seem
that anyone is motivated to carry the proposal to completion. It does
seem a bit unnecessary to include a warning in the compiler about
"future changes to the module" when there's no timeline or volunteer to
implement these changes.
The removal of this warning was discussed again at:
https://github.com/haskell/core-libraries-committee/issues/269
During the discussion there was no new enthusiasm to move onto the next
stages of the proposal so we are removing the warning to unblock the
reinstallable "base" project (#24903)
Fixes #24904
- - - - -
d4e4d498 by Matthew Pickering at 2024-09-26T12:08:57-04:00
Move Control.Monad.Zip into ghc-internal
mzip is wired in and therefore needs to be in ghc-internal.
Fixes #25222
Towards #24903
- - - - -
d3dacdfb by Matthew Pickering at 2024-09-26T12:08:57-04:00
Unwire the base package
This patch just removes all the functions related to wiring-in the base
package and the `-this-unit-id=base` flag from the cabal file.
After this commit "base" becomes just like any other package and the
door is opened to moving base into an external repo and releasing base
on a separate schedule to the rest of ghc.
Closes #24903
- - - - -
1b39363b by Patrick at 2024-09-27T06:10:19-04:00
Add entity information to HieFile #24544
Enhanced HieFile to capture entity information for identifiers, enabling better support for language tools and protocols. See issue #24544 for more details.
Work have been done:
* Introduction of new data type `EntityInfo` in `GHC.Iface.Ext.Types`.
* Add extra field `hie_entity_infos :: NameEntityInfo` to `HieFile`
to store the mapping from entity name to corresponding entity infos
in `GHC.Iface.Ext.Types`.
* Compute `EntityInfo` for each entity name in the HieAst from `TyThing,
Id, OccName` when generating the `HieFile` in `GHC.Iface.Ext.Ast`.
* Add test T24544 to test the generation of `EntityInfo`.
- - - - -
4f3618d8 by sheaf at 2024-09-27T06:10:57-04:00
The X86 SIMD patch.
This commit adds support for 128 bit wide SIMD vectors and vector
operations to GHC's X86 native code generator.
Main changes:
- Introduction of vector formats (`GHC.CmmToAsm.Format`)
- Introduction of 128-bit virtual register (`GHC.Platform.Reg`),
and removal of unused Float virtual register.
- Refactor of `GHC.Platform.Reg.Class.RegClass`: it now only contains
two classes, `RcInteger` (for general purpose registers) and `RcFloatOrVector`
(for registers that can be used for scalar floating point values as well
as vectors).
- Modify `GHC.CmmToAsm.X86.Instr.regUsageOfInstr` to keep track
of which format each register is used at, so that the register
allocator can know if it needs to spill the entire vector register
or just the lower 64 bits.
- Modify spill/load/reg-2-reg code to account for vector registers
(`GHC.CmmToAsm.X86.Instr.{mkSpillInstr, mkLoadInstr, mkRegRegMoveInstr, takeRegRegMoveInstr}`).
- Modify the register allocator code (`GHC.CmmToAsm.Reg.*`) to propagate
the format we are storing in any given register, for instance changing
`Reg` to `RegFormat` or `GlobalReg` to `GlobalRegUse`.
- Add logic to lower vector `MachOp`s to X86 assembly
(see `GHC.CmmToAsm.X86.CodeGen`)
- Minor cleanups to genprimopcode, to remove the llvm_only attribute
which is no longer applicable.
Tests for this feature are provided in the "testsuite/tests/simd" directory.
Fixes #7741
Keeping track of register formats adds a small memory overhead to the
register allocator (in particular, regUsageOfInstr now allocates more
to keep track of the `Format` each register is used at). This explains
the following metric increases.
-------------------------
Metric Increase:
T12707
T13035
T13379
T3294
T4801
T5321FD
T5321Fun
T783
-------------------------
- - - - -
10e431ef by sheaf at 2024-09-27T06:10:57-04:00
Use xmm registers in genapply
This commit updates genapply to use xmm, ymm and zmm registers, for
stg_ap_v16/stg_ap_v32/stg_ap_v64, respectively.
It also updates the Cmm lexer and parser to produce Cmm vectors rather
than 128/256/512 bit wide scalars for V16/V32/V64, removing bits128,
bits256 and bits512 in favour of vectors.
The Cmm Lint check is weakened for vectors, as (in practice, e.g. on X86)
it is okay to use a single vector register to hold multiple different
types of data, and we don't know just from seeing e.g. "XMM1" how to
interpret the 128 bits of data within.
Fixes #25062
- - - - -
8238fb2d by sheaf at 2024-09-27T06:10:57-04:00
Add vector fused multiply-add operations
This commit adds fused multiply add operations such as `fmaddDoubleX2#`.
These are handled both in the X86 NCG and the LLVM backends.
- - - - -
2cb7b748 by sheaf at 2024-09-27T06:10:57-04:00
Add vector shuffle primops
This adds vector shuffle primops, such as
```
shuffleFloatX4# :: FloatX4# -> FloatX4# -> (# Int#, Int#, Int#, Int# #) -> FloatX4#
```
which shuffle the components of the input two vectors into the output vector.
NB: the indices must be compile time literals, to match the X86 SHUFPD
instruction immediate and the LLVM shufflevector instruction.
These are handled in the X86 NCG and the LLVM backend.
Tested in simd009.
- - - - -
0d2428d6 by sheaf at 2024-09-27T06:10:57-04:00
Add Broadcast MachOps
This adds proper MachOps for broadcast instructions, allowing us to
produce better code for broadcasting a value than simply packing that
value (doing many vector insertions in a row).
These are lowered in the X86 NCG and LLVM backends. In the LLVM backend,
it uses the previously introduced shuffle instructions.
- - - - -
e6c19a41 by sheaf at 2024-09-27T06:10:57-04:00
Fix treatment of signed zero in vector negation
This commit fixes the handling of signed zero in floating-point vector
negation.
A slight hack was introduced to work around the fact that Cmm doesn't
currently have a notion of signed floating point literals
(see get_float_broadcast_value_reg). This can be removed once CmmFloat
can express the value -0.0.
The simd006 test has been updated to use a stricter notion of equality
of floating-point values, which ensure the validity of this change.
- - - - -
f496ff7f by sheaf at 2024-09-27T06:10:57-04:00
Add min/max primops
This commit adds min/max primops, such as
minDouble# :: Double# -> Double# -> Double#
minFloatX4# :: FloatX4# -> FloatX4# -> FloatX4#
minWord16X8# :: Word16X8# -> Word16X8# -> Word16X8#
These are supported in:
- the X86, AArch64 and PowerPC NCGs,
- the LLVM backend,
- the WebAssembly and JavaScript backends.
Fixes #25120
- - - - -
5dd2a423 by sheaf at 2024-09-27T06:10:57-04:00
Add test for C calls & SIMD vectors
- - - - -
f824e1ee by sheaf at 2024-09-27T06:10:58-04:00
Add test for #25169
- - - - -
d54db7f3 by sheaf at 2024-09-27T06:10:58-04:00
Fix #25169 using Plan A from the ticket
We now compile certain low-level Cmm functions in the RTS multiple
times, with different levels of vector support. We then dispatch
at runtime in the RTS, based on what instructions are supported.
See Note [realArgRegsCover] in GHC.Cmm.CallConv.
Fixes #25169
-------------------------
Metric Increase:
T10421
T12425
T18730
T1969
T9198
-------------------------
- - - - -
d5f8778a by sheaf at 2024-09-27T06:10:58-04:00
Fix C calls with SIMD vectors
This commit fixes the code generation for C calls, to take into account
the calling convention.
This is particularly tricky on Windows, where all vectors are expected
to be passed by reference. See Note [The Windows X64 C calling convention]
in GHC.CmmToAsm.X86.CodeGen.
- - - - -
f64bd564 by sheaf at 2024-09-27T06:10:58-04:00
X86 CodeGen: refactor getRegister CmmLit
This refactors the code dealing with loading literals into registers,
removing duplication and putting all the code in a single place.
It also changes which XOR instruction is used to place a zero value
into a register, so that we use VPXOR for a 128-bit integer vector
when AVX is supported.
- - - - -
ab12de6b by sheaf at 2024-09-27T06:10:58-04:00
X86 genCCall: promote arg before calling evalArgs
The job of evalArgs is to ensure each argument is put into a temporary
register, so that it can then be loaded directly into one of the
argument registers for the C call, without the generated code clobbering
any other register used for argument passing.
However, if we promote arguments after calling evalArgs, there is the
possibility that the code used for the promotion will clobber a register,
defeating the work of evalArgs.
To avoid this, we first promote arguments, and only then call evalArgs.
- - - - -
8fd12429 by sheaf at 2024-09-27T06:10:58-04:00
X86 genCCall64: simplify loadArg code
This commit simplifies the argument loading code by making the
assumption that it is safe to directly load the argument into register,
because doing so will not clobber any previous assignments.
This assumption is borne from the use of 'evalArgs', which evaluates
any arguments which might necessitate non-trivial code generation into
separate temporary registers.
- - - - -
12504a9f by sheaf at 2024-09-27T06:10:58-04:00
LLVM: propagate GlobalRegUse information
This commit ensures we keep track of how any particular global register
is being used in the LLVM backend. This informs the LLVM type
annotations, and avoids type mismatches of the following form:
argument is not of expected type '<2 x double>'
call ccc <2 x double> (<2 x double>)
(<4 x i32> arg)
- - - - -
2bb1e8df by Cheng Shao at 2024-09-27T06:11:35-04:00
Link bytecode from interface-stored core bindings in oneshot mode
!13042
Part of #T25090
If the flag `-fprefer-byte-code` is given when compiling a module
containing TH, GHC will use Core bindings stored in interfaces to
compile and link bytecode for splices.
This was only implemented for `--make` mode initially, so this commit
adds the same mechanism to oneshot mode (`-c`).
When an interface is loaded into the EPS in `loadInterface` that has
dehydrated Core bindings, an entry is added to the new field
`eps_iface_bytecode`, containing an IO action that produces a bytecode
`Linkable`, lazily processing the `mi_extra_decls` by calling
`loadIfaceByteCode`.
When Template Haskell dependencies are resolved in `getLinkDeps`, this
action is looked up after loading a module's interface.
If it exists, the action is evaluated and the bytecode is added to the
set of `Linkable`s used for execution of the splice; otherwise it falls
back on the traditional object file.
Metric Decrease:
MultiLayerModules
T13701
- - - - -
7cb7172e by Matthew Pickering at 2024-09-27T06:12:12-04:00
ci: Fix variable inheritence for ghcup-metadata testing job
Downstream in ghcup-ci we use the CONFIGURE_ARGS variable to determine
how to setup all the different jobs.
On the downstream trigger this was being inherited from the default
setting in .gitlab.yml file.
Therefore this led to job failures as the necessary CONFIGURE_ARGS were
not being passed to the configure script when installing the bindist.
See docs:
* https://docs.gitlab.com/ee/ci/yaml/#inherit
* https://docs.gitlab.com/ee/ci/yaml/#triggerforward
1. inherit:variables:fals
- This stops the global variables being inherited into the job and
hence forwarded onto the downstream job.
2. trigger:forward:*
- yaml_variables: true (default) pass yaml variables to downstream,
this is important to pass the upstream pipeline id to downstream.
- pipeline_variables: false (default) but don't pass pipeline
variables (normal environment variables).
Fixes #25294
- - - - -
9ffd6163 by Leo at 2024-09-27T16:26:01+05:30
Fix typo in Prelude doc for (>>=)
Fix a minor typo ("equivialent" instead of "equivalent") in the documentation for (>>=) in the prelude.
- - - - -
5745dbd3 by Vladislav Zavialov at 2024-09-27T16:26:52+05:30
Wildcard binders in type declarations (#23501)
Add support for wildcard binders in type declarations:
type Const a b = a -- BEFORE: the `b` had to be named
-- even if unused on the RHS
type Const a _ = a -- AFTER: the compiler accepts
-- a wildcard binder `_`
The new feature is part of GHC Proposal #425 "Invisible binders
in type declarations", and more specifically its amendment #641.
Just like a named binder, a wildcard binder `_` may be:
* plain: _
* kinded: (_ :: k -> Type)
* invisible, plain: @_
* invisible, kinded: @(_ :: k -> Type)
Those new forms of binders are allowed to occur on the LHSs of
data, newtype, type, class, and type/data family declarations:
data D _ = ...
newtype N _ = ...
type T _ = ...
class C _ where ...
type family F _
data family DF _
(Test case: testsuite/tests/typecheck/should_compile/T23501a.hs)
However, we choose to reject them in forall telescopes and
type family result variable binders (the latter being part
of the TypeFamilyDependencies extension):
type family Fd a = _ -- disallowed (WildcardBndrInTyFamResultVar)
fn :: forall _. Int -- disallowed (WildcardBndrInForallTelescope)
(Test case: testsuite/tests/rename/should_fail/T23501_fail.hs)
See the new Notes:
* Note [Type variable binders]
* Note [Wildcard binders in disallowed contexts]
To accommodate the new forms of binders, HsTyVarBndr was changed
as follows (demonstrated without x-fields for clarity)
-- BEFORE (ignoring x-fields and locations)
data HsTyVarBndr flag
= UserTyVar flag Name
| KindedTyVar flag Name HsKind
-- AFTER (ignoring x-fields and locations)
data HsTyVarBndr flag = HsTvb flag HsBndrVar HsBndrKind
data HsBndrVar = HsBndrVar Name | HsBndrWildCard
data HsBndrKind = HsBndrNoKind | HsBndrKind LHsKind
The rest of the patch is downstream from this change.
To avoid a breaking change to the TH AST, we generate fresh
names to replace wildcard binders instead of adding a dedicated
representation for them (as discussed in #641).
And to put a cherry on top of the cake, we now allow wildcards in
kind-polymorphic type variable binders in constructor patterns,
see Note [Type patterns: binders and unifiers] and the tyPatToBndr
function in GHC.Tc.Gen.HsType; example:
fn (MkT @(_ :: forall k. k -> Type) _ _) = ...
(Test case: testsuite/tests/typecheck/should_compile/T23501b.hs)
- - - - -
ff2bdca2 by Matthew Pickering at 2024-09-27T16:27:08+05:30
ci: Push perf notes from wasm jobs
It was observed in #25299 that we were failing to push performance
numbers from the wasm jobs.
In future we might want to remove this ad-hoc check but for now it's
easier to add another special case.
Towards #25299
- - - - -
4c76f75c by Zubin Duggal at 2024-09-27T16:44:00+05:30
Bump GHC version to 9.12
- - - - -
e4ac1b0d by Zubin Duggal at 2024-09-27T19:12:24+05:30
Bump GHC version to 9.13
- - - - -
7d6945cd by Matthew Pickering at 2024-09-30T10:31:29+01:00
Fix toException method for ExceptionWithContext
Fixes #25235
- - - - -
1b121165 by Matthew Pickering at 2024-09-30T10:43:34+01:00
Exception rethrowing
Basic changes:
* Change `catch` function to propagate exceptions using the
WhileHandling mechanism.
* Introduce `catchNoPropagate`, which does the same as before, but
passes an exception which can be rethrown.
* Introduce `rethrowIO` combinator, which rethrows an exception with a
context and doesn't add a new backtrace.
* Introduce `tryWithContext` for a variant of `try` which can rethrow
the exception with it's original context.
* onException is modified to rethrow the original error rather than
creating a new callstack.
* Functions which rethrow in GHC.Internal.IO.Handle.FD,
GHC.Internal.IO.Handle.Internals, GHC.Internal.IO.Handle.Text, and
GHC.Internal.System.IO.Error are modified to not add a new callstack.
Implements CLC proposal#202 <https://github.com/haskell/core-libraries-committee/issues/202>
- - - - -
f9591422 by Rodrigo Mesquita at 2024-09-30T10:43:34+01:00
Add test for #25300
- - - - -
e3e17f21 by Rodrigo Mesquita at 2024-09-30T12:10:46+01:00
exceptions: Improve the message layout as per #285
This commit fixes the layout of the additional information included when
displaying an exception, namely the type of the exception.
It also fixes the default handler's heading message to work well
together with the improved display message of SomeException.
CLC proposal#285
- - - - -
6b5162c7 by Rodrigo Mesquita at 2024-09-30T12:11:02+01:00
Display type and callstack of exception on handler
This commit changes the Exception instance of SomeException to *simply*
display the underlying exception in `displayException`. The augmented
exception message that included the type and backtrace of the exception
are now only printed on a call to `displayExceptionWithInfo`.
At a surface level, existing programs should behave the same since the
`uncaughtExceptionHandler`, which is responsible for printing out uncaught
exceptions to the user, will use `displayExceptionWithInfo` by default.
However, unlike the instance's `displayException` method, the
`uncaughtExceptionHandler` can be overriden with
`setUncaughtExceptionHandler`. This makes the extra information opt-in
without fixing it the instance, which can be valuable if your program
wants to display uncaught exceptions to users in a user-facing way
(ie without backtraces).
This is what was originally agreed for CLC#231 or CLC#261 with regard to
the type of the exception information.
The call stack also becoming part of the default handler rather than the
Exception instance is an ammendment to CLC#164.
Discussion of the ammendment is part of CLC#285.
- - - - -
5ee369e5 by Rodrigo Mesquita at 2024-09-30T13:47:47+01:00
Do #25283
- - - - -
571aa8f3 by Rodrigo Mesquita at 2024-09-30T14:59:27+01:00
Freeze call stack in error throwing functions
- - - - -
30 changed files:
- .gitlab-ci.yml
- .gitlab/ci.sh
- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/ByteCode/Asm.hs
- compiler/GHC/Cmm.hs
- compiler/GHC/Cmm/CallConv.hs
- compiler/GHC/Cmm/Graph.hs
- compiler/GHC/Cmm/Lexer.x
- compiler/GHC/Cmm/Lint.hs
- compiler/GHC/Cmm/Liveness.hs
- compiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/Node.hs
- compiler/GHC/Cmm/Opt.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/Cmm/ProcPoint.hs
- compiler/GHC/Cmm/Reg.hs
- compiler/GHC/Cmm/Sink.hs
- compiler/GHC/Cmm/Type.hs
- compiler/GHC/Cmm/UniqueRenamer.hs
- compiler/GHC/CmmToAsm.hs
- compiler/GHC/CmmToAsm/AArch64.hs
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/CmmToAsm/AArch64/Instr.hs
- compiler/GHC/CmmToAsm/AArch64/Ppr.hs
- compiler/GHC/CmmToAsm/AArch64/Regs.hs
- compiler/GHC/CmmToAsm/Config.hs
- compiler/GHC/CmmToAsm/Format.hs
- compiler/GHC/CmmToAsm/Instr.hs
- compiler/GHC/CmmToAsm/PPC.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b4bfc7d578ea3a580b88fcabd20871afaa7eea43...571aa8f3433cbc59cd43c4d9d072c1b9a6182e6b
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b4bfc7d578ea3a580b88fcabd20871afaa7eea43...571aa8f3433cbc59cd43c4d9d072c1b9a6182e6b
You're receiving this email because of your account on gitlab.haskell.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20240930/d471bc5e/attachment-0001.html>
More information about the ghc-commits
mailing list