GitLab

Alan Zimmerman pushed to branch wip/az/ghc-cpp at Glasgow Haskell Compiler / GHC

Commits:

b08c08ae

by soulomoon at 2025-05-28T01:57:23+08:00

Refactor handling of imported COMPLETE pragmas
from the HPT

Previously, we imported COMPLETE pragmas from all modules in the Home
Package Table (HPT) during type checking. However, since !13675, there
may be non-below modules in the HPT from the dependency tree that we do
not want to import COMPLETE pragmas from. This refactor changes the way
we handle COMPLETE pragmas from the HPT to only import them from modules
that are "below" the current module in the HPT.

- Add hugCompleteSigsBelow to filter COMPLETE pragmas from "below"
  modules in the HPT, mirroring hugRulesBelow.
- Move responsibility for calling hugCompleteSigsBelow to tcRnImports,
  storing the result in the new tcg_complete_match_env field of TcGblEnv.
- Update getCompleteMatchesTcM to use tcg_complete_match_env.

This refactor only affects how COMPLETE pragmas are imported from the
HPT, imports from external packages are unchanged.

16014bf8

by Hécate Kleidukos at 2025-05-28T20:09:34-04:00

Expose all of Backtraces' internals for ghc-internal

Closes #26049

a0adc30d
by Ryan Hendrickson at 2025-05-30T14:12:52-04:00
```
haddock: Fix links to type operators
```

7b64697c

by Mario Blažević at 2025-05-30T14:13:41-04:00

Introduce parenBreakableList and use it in ppHsContext

5f213bff

by fendor at 2025-06-02T09:16:24+02:00

Make GHCi commands compatible with multiple home units

=== Design

We enable all GHCi features that were previously guarded by the `inMulti`
option.

GHCi supported multiple home units up to a certain degree for quite a while now.
The supported feature set was limited, due to a design impasse:
One of the home units must be "active", e.g., there must be one `HomeUnit`
whose `UnitId` is "active" which is returned when calling

```haskell
do
hscActiveUnitId <$> getSession
```

This makes sense in a GHC session, since you are always compiling a particular
Module, but it makes less intuitive sense in an interactive session.
Given an expression to evaluate, we can't easily tell in which "context" the expression
should be parsed, typechecked and evaluated.
That's why initially, most of GHCi features, except for `:reload`ing were disabled
if the GHCi session had more than one `HomeUnitEnv`.

We lift this restriction, enabling all features of GHCi for the multiple home unit case.
To do this, we fundamentally change the `HomeUnitEnv` graph to be multiple home unit first.
Instead of differentiating the case were we have a single home unit and multiple,
we now always set up a multiple home unit session that scales seamlessly to an arbitrary
amount of home units.

We introduce two new `HomeUnitEnv`s that are always added to the `HomeUnitGraph`.
They are:

The "interactive-ghci", called the `interactiveGhciUnit`, contains the same
`DynFlags` that are used by the `InteractiveContext` for interactive evaluation
of expressions.
This `HomeUnitEnv` is only used on the prompt of GHCi, so we may refer to it as
"interactive-prompt" unit.
See Note [Relation between the `InteractiveContext` and `interactiveGhciUnitId`]
for discussing its role.

And the "interactive-session"", called `interactiveSessionUnit` or
`interactiveSessionUnitId`, which is used for loading Scripts into
GHCi that are not `Target`s of any home unit, via `:load` or `:add`.

Both of these "interactive" home units depend on all other `HomeUnitEnv`s that
are passed as arguments on the cli.
Additionally, the "interactive-ghci" unit depends on `interactive-session`.

We always evaluate expressions in the context of the
"interactive-ghci" session.
Since "interactive-ghci" depends on all home units, we can import any `Module`
from the other home units with ease.

As we have a clear `HomeUnitGraph` hierarchy, we can set `interactiveGhciUnitId`
as the active home unit for the full duration of the GHCi session.
In GHCi, we always set `interactiveGhciUnitId` to be the currently active home unit.

=== Implementation Details

Given this design idea, the implementation is relatively straight
forward.
The core insight is that a `ModuleName` is not sufficient to identify a
`Module` in the `HomeUnitGraph`. Thus, large parts of the PR is simply
about refactoring usages of `ModuleName` to prefer `Module`, which has a
`Unit` attached and is unique over the `HomeUnitGraph`.

Consequentially, most usages of `lookupHPT` are likely to be incorrect and have
been replaced by `lookupHugByModule` which is keyed by a `Module`.

In `GHCi/UI.hs`, we make sure there is only one location where we are
actually translating `ModuleName` to a `Module`:

* `lookupQualifiedModuleName`

If a `ModuleName` is ambiguous, we detect this and report it to the
user.

To avoid repeated lookups of `ModuleName`s, we store the `Module` in the
`InteractiveImport`, which additionally simplifies the interface
loading.

A subtle detail is that the `DynFlags` of the `InteractiveContext` are
now stored both in the `HomeUnitGraph` and in the `InteractiveContext`.
In UI.hs, there are multiple code paths where we are careful to update
the `DynFlags` in both locations.
Most importantly in `addToProgramDynFlags`.

---

There is one metric increase in this commit:

-------------------------
Metric Increase:
T4029
-------------------------

It is an increase from 14.4 MB to 16.1 MB (+11.8%) which sounds like a
pretty big regression at first.
However, we argue this increase is solely caused by using more data
structures for managing multiple home units in the GHCi session.
In particular, due to the design decision of using three home units, the
base memory usage increases... but by how much?

A big contributor is the `UnitState`, of which we have three now, which
on its own 260 KB per instance. That makes an additional memory usage of
520 KB, already explaining a third of the overall memory usage increase.
Then we store more elements in the `HomeUnitGraph`, we have more
`HomeUnitEnv` entries, etc...

While we didn't chase down each byte, we looked at the memory usage over time
for both `-hi` and `-hT` profiles and can say with confidence while the memory
usage increased slightly, we did not introduce any space leak, as
the graph looks almost identical as the memory usage graph of GHC HEAD.

---

Adds testcases for GHCi multiple home units session

* Test truly multiple home unit sessions, testing reload logic and code evaluation.
* Test that GHCi commands such as `:all-types`, `:browse`, etc., work
* Object code reloading for home modules
* GHCi debugger multiple home units session

de603d01

by fendor at 2025-06-02T09:16:24+02:00

Update "loading compiled code" GHCi documentation

To use object code in GHCi, the module needs to be compiled for use in
GHCi. To do that, users need to compile their modules with:

* `-dynamic`
* `-this-unit-id interactive-session`

Otherwise, the interface files will not match.

b255a8ca

by Vladislav Zavialov at 2025-06-02T16:00:12-04:00

docs: Fix code example for NoListTuplePuns

Without the fix, the example produces an error:

  Test.hs:11:3: error: [GHC-45219]
      • Data constructor ‘Tuple’ returns type ‘Tuple2 a b’
          instead of an instance of its parent type ‘Tuple a’
      • In the definition of data constructor ‘Tuple’
        In the data type declaration for ‘Tuple’

Fortunately, a one line change makes it compile.

6558467c

by Ryan Hendrickson at 2025-06-06T05:46:58-04:00

haddock: Parse math even after ordinary characters

Fixes a bug where math sections were not recognized if preceded by a
character that isn't special (like space or a markup character).

265d0024

by ARATA Mizuki at 2025-06-06T05:47:48-04:00

AArch64 NCG: Fix sub-word arithmetic right shift

As noted in Note [Signed arithmetic on AArch64], we should zero-extend sub-word values.

Fixes #26061

05e9be18

by Simon Hengel at 2025-06-06T05:48:35-04:00

Allow Unicode in "message" and "hints" with -fdiagnostics-as-json

(fixes #26075)

bfa6b70f

by ARATA Mizuki at 2025-06-06T05:49:24-04:00

x86 NCG: Fix code generation of bswap64 on i386

Co-authored-by: sheaf <sam.derbyshire@gmail.com>

Fix #25601

2218e794

by Alan Zimmerman at 2025-06-06T19:47:31+02:00

GHC-CPP: first rough proof of concept

Processes

     #define FOO
     #ifdef FOO
     x = 1
     #endif

Into

    [ITcppIgnored [L loc ITcppDefine]
    ,ITcppIgnored [L loc ITcppIfdef]
    ,ITvarid "x"
    ,ITequal
    ,ITinteger (IL {il_text = SourceText "1", il_neg = False, il_value = 1})
    ,ITcppIgnored [L loc ITcppEndif]
    ,ITeof]

In time, ITcppIgnored will be pushed into a comment

29b11db7

by Alan Zimmerman at 2025-06-06T19:47:31+02:00

Tidy up before re-visiting the continuation mechanic

4b63c8f6

by Alan Zimmerman at 2025-06-06T19:47:31+02:00

Switch preprocessor to continuation passing style

Proof of concept, needs tidying up

09f504e1
by Alan Zimmerman at 2025-06-06T19:47:31+02:00
```
Small cleanup
```
33c240a3
by Alan Zimmerman at 2025-06-06T19:47:32+02:00
```
Get rid of some cruft
```

e882984d