GitLab

Matthew Pickering pushed to branch wip/t26745 at Glasgow Haskell Compiler / GHC

Commits:

d4b1e353
by Simon Hengel at 2025-12-10T00:00:02-05:00
```
Fix syntax error in gadt_syntax.rst
```

91cc8be6

by Cheng Shao at 2025-12-10T00:00:43-05:00

ci: fix "ci.sh clean" to address frequent out of space error on windows runners

This patch fixes the `ci.sh clean` logic to address frequent out of
space error on windows runners; previously it didn't clean up the
inplace mingw blobs, which is the largest source of space leak on
windows runners. See added comment for detailed explanation.

fe2b79f4

by Recursion Ninja at 2025-12-10T08:34:18-05:00

Narrow before optimising MUL/DIV/REM into shifts

The MUL/DIV/REM operations can be optimised into shifts when one of the
operands is a constant power of 2. However, as literals in Cmm are
stored as 'Integer', for this to be correct we first need to narrow the
literal to the appropriate width before checking whether the literal is
a power of 2.

Fixes #25664

06c2349c

by Recursion Ninja at 2025-12-10T08:34:58-05:00

Decouple 'Language.Haskell.Syntax.Type' from 'GHC.Utils.Panic'

  - Remove the *original* defintion of 'hsQTvExplicit' defined within 'Language.Haskell.Syntax.Type'

  - Redefine 'hsQTvExplicit' as 'hsq_explicit' specialized to 'GhcPass' exported by 'GHC.Utils.Panic'

  - Define 'hsQTvExplicitBinders' as 'hsq_explicit' specialized to 'DocNameI' exported by 'Haddock.GhcUtils'.

  - Replace all call sites of the original 'hsQTvExplicit' definition with either:
    1. 'hsQTvExplicit' updated definition
    2. 'hsQTvExplicitBinders'

All call sites never entered the 'XLHsQTyVars' constructor branch, but a call to 'panic' existed on this code path because the type system was not strong enought to guarantee that the 'XLHsQTyVars' construction was impossible.
These two specialized functions provide the type system with enough information to make that guarantee, and hence the dependancy on 'panic' can be removed.

ac0815d5

by sheaf at 2025-12-10T23:39:57-05:00

Quantify arg before mult in function arrows

As noted in #23764, we expect quantification order to be left-to-right,
so that in a type such as

  a %m -> b

the inferred quantification order should be [a, m, b] and not [m, a, b].

This was addressed in commit d31fbf6c, but that commit failed to update
some other functions such as GHC.Core.TyCo.FVs.tyCoFVsOfType.

This affects Haddock, as whether we print an explicit forall or not
depends on whether the inferred quantification order matches the actual
quantification order.

2caf796e

by sheaf at 2025-12-10T23:39:57-05:00

Haddock: improvements to ty-var quantification

This commit makes several improvements to how Haddock deals with the
quantification of type variables:

  1. In pattern synonyms, Haddock used to jumble up universal and
     existential quantification. That is now fixed, fixing #26252.

     Tested in the 'PatternSyns2' haddock-html test.

  2. The logic for computing whether to use an explicit kind annotation
     for a type variable quantified in a forall was not even wrong.
     This commit improves the heuristic, but it will always remain an
     imperfect heuristic (lest we actually run kind inference again).
     In the future (#26271), we hope to avoid reliance on this heuristic.

b14bdd59

by Teo Camarasu at 2025-12-10T23:40:38-05:00

Add explicit export list to GHC.Num

Let's make clear what this module exports to allow us to easily deprecate and remove some of these in the future. Resolves https://gitlab.haskell.org/ghc/ghc/-/issues/26625

d99f8326

by Cheng Shao at 2025-12-11T19:14:18-05:00

compiler: remove unused CPP code in foreign stub

This patch removes unused CPP code in the generated foreign stub:

- `#define IN_STG_CODE 0` is not needed, since `Rts.h` already
  includes this definition
- The `if defined(__cplusplus)` code paths are not needed in the `.c`
  file, since we don't generate C++ stubs and don't include C++
  headers in our stubs. But it still needs to be present in the `.h`
  header since it might be later included into C++ source files.

46c9746f

by Cheng Shao at 2025-12-11T19:14:57-05:00

configure: bump LlvmMaxVersion to 22

This commit bumps LlvmMaxVersion to 22; 21.x releases have been
available since Aug 26th, 2025 and there's no regressions with 21.x so
far. This bump is also required for updating fedora image to 43.

96fce8d0