GitLab

Zubin pushed to branch wip/25924 at Glasgow Haskell Compiler / GHC

Commits:

67d41299

by Sebastian Graf at 2026-06-18T05:18:24-04:00

Desugar a `case` scrutinee only once (#27383, #20251)

In `dsExpr` for `HsCase` we desugared the scrutinee /twice/: once to
build the Core `case` itself, and again inside `matchWrapper`, which
re-desugared the source scrutinee (via `addHsScrutTmCs`) purely to
record long-distance information for the pattern-match checker.

For a single `case` that is merely wasteful.  But for nested cases it
is catastrophic.  Consider

    case (case (case e of ... ) of ... ) of ...

Desugaring the outer scrutinee desugars the middle `case` twice, each
of which desugars the inner `case` twice, and so on.  The work doubles
at every level, so desugaring takes O(2^n) time in the nesting depth.
That is the blowup reported in #27383; it is also what makes the
machine-generated program in #20251 take an age to compile.

The fix is simple.  `matchWrapper` is handed the scrutinee anyway, so
we give it the Core expression we have /already/ desugared, and record
the long-distance term constraint with `addCoreScrutTmCs` instead of
re-desugaring from source.  This is just what `matchSinglePatVar`
already does for single-pattern matches.

So:

* `matchWrapper` now takes `Maybe [CoreExpr]` rather than
  `Maybe [LHsExpr GhcTc]`.

* The `HsCase` equation of `dsExpr` passes the already-desugared
  `core_discrim`; the arrow desugarer passes its match variables.

* `addHsScrutTmCs` had no other use, so it is gone.

Desugaring is now linear in the nesting depth.  (The coverage checker
still runs `simpleOptExpr` over each scrutinee, which leaves the total
at O(n^2); that is ample.)  The long-distance information itself is
unchanged: the checker sees precisely the Core that backs the
generated code.

Test: deSugar/should_compile/T27383

fa5defde

by Rodrigo Mesquita at 2026-06-18T05:19:11-04:00

fix: Save FastStrings in the PMC

There is no point in adding the unique to the occurrence FastString we
create, since it is part of the Id anyway.

Adding it to the FastString, meant each FastString was unique
unnecessarily!

In a separate branch, running the compiler on test `InstanceMatching`
observed 30000 `FastString`s created by this code path.

Plus, `fsLit "pm"` follows the existing pattern in `mkPmId`.

4efb4a66

by Alan Zimmerman at 2026-06-18T14:41:14-04:00

TTG: Add extension points to HsConDetails

Extend HsConDetails as

    data HsConDetails p arg rec
      = PrefixCon !(XPrefixCon p) [arg]    -- C @t1 @t2 p1 p2 p3
      | RecCon    !(XRecCon p)    rec      -- C { x = p1, y = p2 }
      | InfixCon  !(XInfixCon p)  arg arg  -- p1 `C` p2
      | XHsConDetails !(XXHsConDetails p)

    type family XPrefixCon      p
    type family XRecCon         p
    type family XInfixCon       p
    type family XXHsConDetails  p

c8d27dd4

by Simon Jakobi at 2026-06-18T14:41:59-04:00

CI: quiet submodule clean output in after_script and setup

The clean and cleanup_submodules functions ran 'git submodule foreach
git clean -xdf', flooding the job log with 'Entering ...' and
'Removing ...' lines. Pass --quiet to 'git submodule' and -q to 'git
clean' to drop the success output; errors are still reported.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

09326ca6

by Matthew Pickering at 2026-06-20T23:41:12+02:00

Add missing req_interp modifier to T18441fail3 and T18441fail19

These tests require the interpreter but they were failing in a different
way with the javascript backend because the interpreter was disabled and
stderr is ignored by the test.

521e55bf

by Matthew Pickering at 2026-06-20T23:41:13+02:00

hadrian: Fill in more of the default.host toolchain file

When you are building a cross compiler this file will be used to build
stage1 and it's libraries, so we need enough information here to work
accurately. There is still more work to be done (see for example, word
size is still fixed).

23c9b6c3

by Matthew Pickering at 2026-06-20T23:42:52+02:00

hadrian: Build stage 2 cross compilers

* Most of hadrian is abstracted over the stage in order to remove the
  assumption that the target of all stages is the same platform. This
  allows the RTS to be built for two different targets for example.
* Abstracts the bindist creation logic to allow building either normal
  or cross bindists. Normal bindists use stage 1 libraries and a stage 2
  compiler. Cross bindists use stage 2 libararies and a stage 2
  compiler.
* hadrian: Make binary-dist-dir the default build target. This allows us
  to have the logic in one place about which libraries/stages to build
  with cross compilers. Fixes #24192

New hadrian target:

* `binary-dist-dir-cross`: Build a cross compiler bindist (compiler =
  stage 1, libraries = stage 2)

This commit also contains various changes to make stage2 compilers
feasible.

-------------------------
Metric Decrease:
    LinkableUsage02
    ManyAlternatives
    ManyConstructors
    MultiComponentModulesRecomp
    MultiLayerModulesRecomp
    RecordUpdPerf
    T10421
    T12150
    T12227
    T12425
    T12707
    T13035
    T13379
    T13820
    T15703
    T16577
    T18140
    T18282
    T18698a
    T18698b
    T18923
    T1969
    T20049
    T21839c
    T3294
    T4801
    T5030
    T5321FD
    T5321Fun
    T5631
    T5642
    T6048
    T783
    T9020
    T9198
    T9233
    T9630
    T9872d
    T9961
    parsing001
    T3064

Metric Increase:
    T26989
    hard_hole_fits
-------------------------

Co-authored-by: Sven Tennie <sven.tennie@gmail.com>

26fed8ab

by Matthew Pickering at 2026-06-20T23:42:52+02:00

ci: Test cross bindists

We remove the special logic for testing in-tree cross
compilers and instead test cross compiler bindists, like we do for all
other platforms.

80c8910e

by Matthew Pickering at 2026-06-20T23:42:52+02:00

ci: Introduce CROSS_STAGE variable

In preparation for building and testing stage3 bindists we introduce the
CROSS_STAGE variable which is used by a CI job to determine what kind of
bindist the CI job should produce.

At the moment we are only using CROSS_STAGE=2 but in the future we will
have some jobs which set CROSS_STAGE=3 to produce native bindists for a
target, but produced by a cross compiler, which can be tested on by
another CI job on the native platform.

CROSS_STAGE=2: Build a normal cross compiler bindist
CROSS_STAGE=3: Build a stage 3 bindist, one which is a native compiler and library for the target

8215573d