GitLab

Simon Peyton Jones pushed to branch wip/T23162-spj at Glasgow Haskell Compiler / GHC

Commits:

14281a22
by Ben Gamari at 2025-10-11T14:06:47-04:00
```
rts/nonmoving: Fix comment spelling
```

bedd38b0

by Ben Gamari at 2025-10-11T14:06:47-04:00

rts/nonmoving: Use atomic operations to update bd->flags

215d6841

by Ben Gamari at 2025-10-11T14:06:47-04:00

nonmoving: Use get_itbl instead of explicit loads

This is cleaner and also fixes unnecessary (and unsound) use of
`volatile`.

2c94aa3a

by Ben Gamari at 2025-10-11T14:06:47-04:00

rts/Scav: Handle WHITEHOLEs in scavenge_one

`scavenge_one`, used to scavenge mutable list entries, may encounter
`WHITEHOLE`s when the non-moving GC is in use via two paths:

  1. when an MVAR is being marked concurrently
  2. when the object belongs to a chain of selectors being short-cutted.

Fixes #26204.

6bd8155c

by Matthew Pickering at 2025-10-11T14:07:29-04:00

Add support for generating bytecode objects

This commit adds the `-fwrite-byte-code` option which makes GHC emit a
`.gbc` file which contains a serialised representation of bytecode.

The bytecode can be loaded by the compiler to avoid having to
reinterpret a module when using the bytecode interpreter (for example,
in GHCi).

There are also the new options:

* -gbcdir=<DIR>: Specify the directory to place the gbc files
* -gbcsuf=<suffix>: Specify the suffix for gbc files

The option `-fbyte-code-and-object-code` now implies
`-fwrite-byte-code`.

These performance tests fail due to https://github.com/haskell/directory/issues/204

-------------------------
Metric Increase:
    MultiComponentModules
    MultiLayerModules
    MultiComponentModulesRecomp
    MultiLayerModulesRecomp
    MultiLayerModulesTH_Make
    MultiLayerModulesTH_OneShot
    T13701
-------------------------

The bytecode serialisation part was implemented by Cheng Shao

Co-authored-by: Cheng Shao <terrorjack@type.dance>

dc8f9599

by Matthew Pickering at 2025-10-11T14:07:30-04:00

Revert "Add a perf test for #26425"

This test has a large memory spike currently, which makes the test
sensitive, since if you allocate a little more or less, the precise
location where GC happens shifts and you observe a different part of the
spike.

Andreas told me to revert the patch for now, and he will add it back
when he fixes the memory spike.

This reverts commit 41bdb16fd083110a06507248f648c507a2feb4af.

e10dcd65

by Sven Tennie at 2025-10-12T10:24:56+00:00

T22859: Increase threadDelay for small machines

The previously used thread delay led to failures on my RISC-V test
setups.

d59ef6b6

by Hai / @BestYeen at 2025-10-14T21:51:14-04:00

Change Alex and Happy m4 scripts to display which version was found in the system, adapt small formatting details in Happy script to be more like the Alex script again.

c98abb6a

by Hai / @BestYeen at 2025-10-14T21:52:08-04:00

Update occurrences of return to pure and add a sample for redefining :m to mean :main

70ee825a

by Cheng Shao at 2025-10-14T21:52:50-04:00

testsuite: fix T3586 for non-SSE3 platforms

`T3586.hs` contains `-fvia-C -optc-msse3` which I think is a
best-effort basis to harvest the C compiler's auto vectorization
optimizations via the C backend back when the test was added. The
`-fvia-C` part is now a deprecated no-op because GHC can't fall back
to the C backend on a non-unregisterised build, and `-optc-msse3`
might actually cause the test to fail on non x86/x64 platforms, e.g.
recent builds of wasi-sdk would report `wasm32-wasi-clang: error:
unsupported option '-msse3' for target 'wasm32-unknown-wasi'`.

So this patch cleans up this historical cruft. `-fvia-C` is removed,
and `-optc-msse3` is only passed when cpuid contains `pni` (which
indicates support of SSE3).

4be32153

by Teo Camarasu at 2025-10-15T08:06:09-04:00

Add submodules for template-haskell-lift and template-haskell-quasiquoter

These two new boot libraries expose stable subsets of the
template-haskell interface.

This is an implemenation of the GHC proposal https://github.com/ghc-proposals/ghc-proposals/pull/696

Work towards #25262

0c00c9c3

by Ben Gamari at 2025-10-15T08:06:51-04:00

rts: Eliminate uses of implicit constant arrays

Folding of `const`-sized variable-length arrays to a constant-length
array is a gnu extension which clang complains about.

Closes #26502.

bf902a1d

by Fendor at 2025-10-15T16:00:59-04:00

Refactor distinct constructor tables map construction

Adds `GHC.Types.Unique.FM.alterUFM_L`, `GHC.Types.Unique.DFM.alterUDFM_L`
`GHC.Data.Word64Map.alterLookup` to support fusion of distinct
constructor data insertion and lookup during the construction of the `DataCon`
map in `GHC.Stg.Debug.numberDataCon`.

Co-authored-by: Fendor <fendor@posteo.de>
Co-authored-by: Finley McIlwaine <finleymcilwaine@gmail.com>

b3585ba1

by Fendor at 2025-10-15T16:00:59-04:00

Allow per constructor refinement of distinct-constructor-tables

Introduce `-fno-distinct-constructor-tables`. A distinct constructor table
configuration is built from the combination of flags given, in order. For
example, to only generate distinct constructor tables for a few specific
constructors and no others, just pass
`-fdistinct-constructor-tables-only=C1,...,CN`.
This flag can be supplied multiple times to extend the set of
constructors to generate a distinct info table for.

You can disable generation of distinct constructor tables for all
configurations by passing `-fno-distinct-constructor-tables`.

The various configurations of these flags is included in the `DynFlags`
fingerprints, which should result in the expected recompilation logic.

Adds a test that checks for distinct tables for various given or omitted
constructors.

Updates CountDepsAst and CountDepsParser tests to account for new dependencies.

Fixes #23703

Co-authored-by: Fendor <fendor@posteo.de>
Co-authored-by: Finley McIlwaine <finleymcilwaine@gmail.com>

e17dc695

by fendor at 2025-10-15T16:01:41-04:00

Fix typos in haddock documentation for stack annotation API

f85058d3

by Zubin Duggal at 2025-10-17T13:50:52+05:30

compiler: Attempt to systematize Unique tags by introducing an ADT for each different tag

Fixes #26264

Metric Decrease:
    T9233

c85c845d

by sheaf at 2025-10-17T22:35:32-04:00

Don't prematurely final-zonk PatSyn declarations

This commit makes GHC hold off on the final zonk for pattern synonym
declarations, in 'GHC.Tc.TyCl.PatSyn.tc_patsyn_finish'.
This accommodates the fact that pattern synonym declarations without a
type signature can contain unfilled metavariables, e.g. if the RHS of
the pattern synonym involves view-patterns whose type mentions promoted
(level 0) metavariables. Just like we do for ordinary function bindings,
we should allow these metavariables to be settled later, instead of
eagerly performing a final zonk-to-type.

Now, the final zonking-to-type for pattern synonyms is performed in
GHC.Tc.Module.zonkTcGblEnv.

Fixes #26465

ba3e5bdd

by Rodrigo Mesquita at 2025-10-18T16:57:18-04:00

Move code-gen aux symbols from ghc-internal to rts

These symbols were all previously defined in ghc-internal and made the
dependency structure awkward, where the rts may refer to some of these
symbols and had to work around that circular dependency the way
described in #26166.

Moreover, the code generator will produce code that uses these symbols!
Therefore, they should be available in the rts:

PRINCIPLE: If the code generator may produce code which uses this
symbol, then it should be defined in the rts rather than, say,
ghc-internal.

That said, the main motivation is towards fixing #26166.

Towards #26166. Pre-requisite of !14892

f31de2a9

by Ben Gamari at 2025-10-18T16:57:18-04:00

rts: Avoid static symbol references to ghc-internal

This resolves #26166, a bug due to new constraints placed by Apple's
linker on undefined references.

One source of such references in the RTS is the many symbols referenced
in ghc-internal. To mitigate #26166, we make these references dynamic,
as described in Note [RTS/ghc-internal interface].

Fixes #26166

Co-authored-by: Rodrigo Mesquita <rodrigo.m.mesquita@gmail.com>
Co-authored-by: Cheng Shao <terrorjack@type.dance>

43fdfddc

by Ben Gamari at 2025-10-18T16:57:18-04:00

compiler: Rename isMathFun -> isLibcFun

This set includes more than just math functions.

4ed5138f

by Ben Gamari at 2025-10-18T16:57:18-04:00

compiler: Add libc allocator functions to libc_funs

Prototypes for these are now visible from `Prim.h`, resulting in
multiple-declaration warnings in the unregisterised job.

9a0a076b

by Ben Gamari at 2025-10-18T16:57:18-04:00

rts: Minimize header dependencies of Prim.h

Otherwise we will end up with redundant and incompatible declarations
resulting in warnings during the unregisterised build.

26b8a414

by Diego Antonio Rosario Palomino at 2025-10-18T16:58:10-04:00

Cmm Parser: Fix incorrect example in comment

The Parser.y file contains a comment with an incorrect example of textual
Cmm (used in .cmm files). This commit updates the comment to ensure it
reflects valid textual Cmm syntax.

Fixes #26313

67831474

by Richard Eisenberg at 2025-10-21T16:13:25+01:00

Refactor fundep solving

This commit is a large-scale refactor of the increasingly-messy code that
handles functional dependencies.  It has virtually no effect on what compiles
but improves error messages a bit.  And it does the groundwork for #23162.

The big picture is described in
    Note [Overview of functional dependencies in type inference]
in GHC.Tc.Solver.FunDeps

* New module GHC.Tc.Solver.FunDeps contains all the fundep-handling
  code for the constraint solver.

* Fundep-equalities are solved in a nested scope; they may generate
  unifications but otherwise have no other effect.
  See GHC.Tc.Solver.FunDeps.solveFunDeps

  The nested needs to start from the Givens in the inert set, but
  not the Wanteds; hence a new function `resetInertCans`, used in
  `nestFunDepsTcS`.

* That in turn means that fundep equalities never show up in error
  messages, so the complicated FunDepOrigin tracking can all disappear.

* We need to be careful about tracking unifications, so we kick out
  constraints from the inert set after doing unifications.  Unification
  tracking has been majorly reformed: see Note [WhatUnifications] in
  GHC.Tc.Utils.Unify.

  A good consequence is that the hard-to-grok `resetUnificationFlag`
  has been replaced with a simpler use of
  `reportCoarseGrainUnifications`

Smaller things:

* Rename `FunDepEqn` to `FunDepEqns` since it contains multiple
  type equalities.

Some compile time improvement

Metrics: compile_time/bytes allocated
                          Baseline
                  Test       value      New value Change
---------------------- --------------------------------------
         T5030(normal) 173,839,232    148,115,248 -14.8% GOOD
hard_hole_fits(normal) 286,768,048    284,015,416  -1.0%

             geo. mean                             -0.2%
             minimum                              -14.8%
             maximum                               +0.3%

Metric Decrease:
    T5030

51194dc2

by Simon Peyton Jones at 2025-10-21T16:13:25+01:00

QuickLook's tcInstFun should make instantiation variables directly

tcInstFun must make "instantiation variables", not regular
unification variables, when instantiating function types. That was
previously implemented by a hack: set the /ambient/ level to QLInstTyVar.

But the hack finally bit me, when I was refactoring WhatUnifications.
And it was always wrong: see the now-expunged (TCAPP2) note.

This commit does it right, by making tcInstFun call its own
instantiation functions.  That entails a small bit of duplication,
but the result is much, much cleaner.

07273cef

by Simon Peyton Jones at 2025-10-21T16:13:25+01:00

Build implication for constraints from (static e)

This commit addresses #26466, by buiding an implication for the
constraints arising from a (static e) form.  The implication has
a special ic_info field of StaticFormSkol, which tells the constraint
solver to use an empty set of Givens.

See (SF3) in Note [Grand plan for static forms]
in GHC.Iface.Tidy.StaticPtrTable

This commit also reinstates an `assert` in GHC.Tc.Solver.Equality.

The test `StaticPtrTypeFamily` was failing with an assertion failure,
but it now works.

38e504b9
by Simon Peyton Jones at 2025-10-21T16:14:46+01:00
```
Comments about defaulting representation equalities
```

a6773e40