GitLab

Hassan Al-Awwadi pushed to branch wip/haanss/depdir at Glasgow Haskell Compiler / GHC

Commits:

8d33d048

by Berk Özkütük at 2025-07-07T20:42:20-04:00

Consider `PromotedDataCon` in `tyConStupidTheta`

Haddock checks data declarations for the stupid theta so as not to
pretty-print them as empty contexts. Type data declarations end up as
`PromotedDataCon`s by the time Haddock performs this check, causing a
panic. This commit extends `tyConStupidTheta` so that it returns an
empty list for `PromotedDataCon`s. This decision was guided by the fact
that type data declarations never have data type contexts (see (R1) in
Note [Type data declarations]).

Fixes #25739.

a26243fd

by Ryan Hendrickson at 2025-07-07T20:43:07-04:00

haddock: Document instances from other packages

When attaching instances to `Interface`s, it isn't enough just to look
for instances in the list of `Interface`s being processed. We also need
to look in the modules on which they depend, including those outside of
this package.

Fixes #25147.
Fixes #26079.

0fb24420

by Rodrigo Mesquita at 2025-07-07T20:43:49-04:00

hadrian: Fallback logic for internal interpreter

When determining whether to build the internal interpreter, the `make`
build system had a fallback case for platforms not in the list of
explicitly-supported operating systems and architectures.

This fallback says we should try to build the internal interpreter if
building dynamic GHC programs (if the architecture is unknown).

Fixes #24098

fe925bd4
by Ben Gamari at 2025-07-07T20:44:30-04:00
```
users-guide: Reference Wasm FFI section
```
5856284b
by Ben Gamari at 2025-07-07T20:44:30-04:00
```
users-guide: Fix too-short heading warning
```

a48dcdf3

by Duncan Coutts at 2025-07-07T20:45:18-04:00

Reorganise documentation for allocate* functions

Consolodate interface information into the .h file, keeping just
implementation details in the .c file.

Use Notes stlye in the .h file and refer to notes from the .c file.

de5b528c

by Duncan Coutts at 2025-07-07T20:45:18-04:00

Introduce common utilities for allocating arrays

The intention is to share code among the several places that do this
already.

b321319d

by Duncan Coutts at 2025-07-07T20:45:18-04:00

Use new array alloc utils in Heap.c

The CMM primop can now report heap overflow.

1d557ffb

by Duncan Coutts at 2025-07-07T20:45:18-04:00

Use new array alloc utils in ThreadLabels.c

Replacing a local utility.

e59a1430

by Duncan Coutts at 2025-07-07T20:45:18-04:00

Use new array alloc utils in Threads.c

Replacing local open coded version.

482df1c9

by Duncan Coutts at 2025-07-07T20:45:18-04:00

Add exitHeapOverflow helper utility

This will be useful with the array alloc functions, since unlike
allocate/allocateMaybeFail, they do not come in two versions. So if it's
not convenient to propagate failure, then one can use this.

4d3ec8f9

by Duncan Coutts at 2025-07-07T20:45:18-04:00

Use new array alloc utils in Weak.c

Also add a cpp macro CCS_SYSTEM_OR_NULL which does what it says. The
benefit of this is that it allows us to referece CCS_SYSTEM even when
we're not in PROFILING mode. That makes abstracting over profiling vs
normal mode a lot easier.

0c4f2fde

by Duncan Coutts at 2025-07-07T20:45:18-04:00

Convert the array alloc primops to use the new array alloc utils

a3354ad9

by Duncan Coutts at 2025-07-07T20:45:18-04:00

While we're at it, add one missing 'likely' hint

To a cmm primops that raises an exception, like the others now do.

33b546bd

by meooow25 at 2025-07-07T20:46:09-04:00

Keep scanl' strict in the head on rewrite

`scanl'` forces elements to WHNF when the corresponding `(:)`s are
forced. The rewrite rule for `scanl'` missed forcing the first element,
which is fixed here with a `seq`.

8a69196e

by Rodrigo Mesquita at 2025-07-08T07:39:47-04:00

debugger/rts: Allow toggling step-in per thread

The RTS global flag `rts_stop_next_breakpoint` globally sets the
interpreter to stop at the immediate next breakpoint.

With this commit, single step mode can additionally be set per thread in
the TSO flag (TSO_STOP_NEXT_BREAKPOINT).

Being able to toggle "stop at next breakpoint" per thread is an
important requirement for implementing "stepping out" of a function in a
multi-threaded context.

And, more generally, having a per-thread flag for single-stepping paves the
way for multi-threaded debugging.

That said, when we want to enable "single step" mode for the whole
interpreted program we still want to stop at the immediate next
breakpoint, whichever thread it belongs to.

That's why we also keep the global `rts_stop_next_breakpoint` flag, with
`rts_enableStopNextBreakpointAll` and `rts_disableStopNextBreakpointAll` helpers.

Preparation for #26042

73d3f864

by Rodrigo Mesquita at 2025-07-08T07:39:47-04:00

docs: Case continuation BCOs

This commit documents a subtle interaction between frames for case BCOs
and their parents frames. Namely, case continuation BCOs may refer to
(non-local) variables that are part of the parent's frame.

The note expanding a bit on these details is called [Case continuation BCOs]

d7aeddcf

by Rodrigo Mesquita at 2025-07-08T07:39:47-04:00

debugger: Implement step-out feature

Implements support for stepping-out of a function (aka breaking right after
returning from a function) in the interactive debugger.

It also introduces a GHCi command :stepout to step-out of a function
being debugged in the interpreter. The feature is described as:

    Stop at the first breakpoint immediately after returning from the current
    function scope.

    Known limitations: because a function tail-call does not push a stack
    frame, if step-out is used inside of a function that was tail-called,
    execution will not be returned to its caller, but rather its caller's
    first non-tail caller. On the other hand, it means the debugger
    follows the more realistic execution of the program.
    In the following example:

    .. code-block:: none

    f = do
       a
       b <--- (1) set breakpoint then step in here
       c
    b = do
       ...
       d <--- (2) step-into this tail call
    d = do
       ...
       something <--- (3) step-out here
       ...

    Stepping-out will stop execution at the `c` invokation in `f`, rather than
    stopping at `b`.

The key idea is simple: When step-out is enabled, traverse the runtime
stack until a continuation BCO is found -- and enable the breakpoint
heading that BCO explicitly using its tick-index.
The details are specified in `Note [Debugger: Step-out]` in `rts/Interpreter.c`.

Since PUSH_ALTS BCOs (representing case continuations) were never headed
by a breakpoint (unlike the case alternatives they push), we introduced
the BRK_ALTS instruction to allow the debugger to set a case
continuation to stop at the breakpoint heading the alternative that is
taken. This is further described in `Note [Debugger: BRK_ALTS]`.

Fixes #26042

5d9adf51

by Rodrigo Mesquita at 2025-07-08T07:39:47-04:00

debugger: Filter step-out stops by SrcSpan

To implement step-out, the RTS looks for the first continuation frame on
the stack and explicitly enables its entry breakpoint. However, some
continuations will be contained in the function from which step-out was
initiated (trivial example is a case expression).

Similarly to steplocal, we will filter the breakpoints at which the RTS
yields to the debugger based on the SrcSpan. When doing step-out, only
stop if the breakpoint is /not/ contained in the function from which we
initiated it.

This is especially relevant in monadic statements such as IO which is
compiled to a long chain of case expressions.

See Note [Debugger: Filtering step-out stops]

7677adcc
by Cheng Shao at 2025-07-08T07:40:29-04:00
```
compiler: make ModBreaks serializable
```

14f67c6d

by Rodrigo Mesquita at 2025-07-08T07:40:29-04:00

refactor: "Inspecting the session" moved from GHC

Moved utilities for inspecting the session from the GHC module to
GHC.Driver.Session.Inspect

Purely a clean up

9d3f484a

by Rodrigo Mesquita at 2025-07-08T07:40:30-04:00

cleanup: Pass the HUG to readModBreaks, not HscEnv

A minor cleanup. The associated history and setupBreakpoint functions
are changed accordingly.

b595f713

by Rodrigo Mesquita at 2025-07-08T07:40:30-04:00

cleanup: Move readModBreaks to GHC.Runtime.Interpreter

With some small docs changes

d223227a

by Rodrigo Mesquita at 2025-07-08T07:40:30-04:00

cleanup: Move interpreterProfiled to Interp.Types

Moves interpreterProfiled and interpreterDynamic to
GHC.Runtime.Interpreter.Types from GHC.Runtime.Interpreter.

7fdd0a3d

by Rodrigo Mesquita at 2025-07-08T07:40:30-04:00

cleanup: Don't import GHC in Debugger.Breakpoints

Remove the top-level

    import GHC

from GHC.Runtime.Debugger.Breakpoints

This makes the module dependencies more granular and cleans up the
qualified imports from the code.

5e4da31b
by Rodrigo Mesquita at 2025-07-08T07:40:30-04:00
```
refactor: Use BreakpointId in Core and Ifaces
```

741ac3a8

by Rodrigo Mesquita at 2025-07-08T07:40:30-04:00

stg2bc: Derive BcM via ReaderT StateT

A small refactor that simplifies GHC.StgToByteCode by deriving-via the
Monad instances for BcM. This is done along the lines of previous
similar refactors like 72b54c0760bbf85be1f73c1a364d4701e5720465.

0414fcc9

by Rodrigo Mesquita at 2025-07-08T07:40:30-04:00

refact: Split InternalModBreaks out of ModBreaks

There are currently two competing ways of referring to a Breakpoint:

    1. Using the Tick module + Tick index
    2. Using the Info module + Info index

1. The Tick index is allocated during desugaring in `mkModBreaks`. It is
used to refer to a breakpoint associated to a Core Tick. For a given
Tick module, there are N Ticks indexed by Tick index.

2. The Info index is allocated during code generation (in StgToByteCode)
and uniquely identifies the breakpoints at runtime (and is indeed used
to determine which breakpoint was hit at runtime).

Why we need both is described by Note [Breakpoint identifiers].

For every info index we used to keep a `CgBreakInfo`, a datatype containing
information relevant to ByteCode Generation, in `ModBreaks`.

This commit splits out the `IntMap CgBreakInfo` out of `ModBreaks` into
a new datatype `InternalModBreaks`.

    - The purpose is to separate the `ModBreaks` datatype, which stores
      data associated from tick-level information which is fixed after
      desugaring, from the unrelated `IntMap CgBreakInfo` information
      accumulated during bytecode generation.

    - We move `ModBreaks` to GHC.HsToCore.Breakpoints

The new `InternalModBreaks` simply combines the `IntMap CgBreakInfo`
with `ModBreaks`. After code generation we construct an
`InternalModBreaks` with the `CgBreakInfo`s we accumulated and the
existing `ModBreaks` and store that in the compiled BCO in `bc_breaks`.

    - Note that we previously only updated the `modBreaks_breakInfo`
      field of `ModBreaks` at this exact location, and then stored the
      updated `ModBreaks` in the same `bc_breaks`.

    - We put this new datatype in GHC.ByteCode.Breakpoints

The rest of the pipeline for which CgBreakInfo is relevant is
accordingly updated to also use `InternalModBreaks`

2a097955

by Rodrigo Mesquita at 2025-07-08T07:40:30-04:00

cleanup: Use BreakpointIds in bytecode gen

Small clean up to use BreakpointId and InternalBreakpointId more
uniformly in bytecode generation rather than using Module + Ix pairs

0515cc2f

by Rodrigo Mesquita at 2025-07-08T07:40:30-04:00

ghci: Allocate BreakArrays at link time only

Previously, a BreakArray would be allocated with a slot for every tick
in a module at `mkModBreaks`, in HsToCore. However, this approach has
a few downsides:

- It interleaves interpreter behaviour (allocating arrays for
  breakpoints) within the desugarer

- It is inflexible in the sense it is impossible for the bytecode
  generator to add "internal" breakpoints that can be triggered at
  runtime, because those wouldn't have a source tick. (This is relevant
  for our intended implementation plan of step-out in #26042)

- It ties the BreakArray indices to the *tick* indexes, while at runtime
  we would rather just have the *info* indexes (currently we have both
  because BreakArrays are indexed by the *tick* one).

Paving the way for #26042 and #26064, this commit moves the allocation
of BreakArrays to bytecode-loading time -- akin to what is done for CCS
arrays.

Since a BreakArray is allocated only when bytecode is linked, if a
breakpoint is set (e.g. `:break 10`) before the bytecode is linked,
there will exist no BreakArray to trigger the breakpoint in.

Therefore, the function to allocate break arrays (`allocateBreakArrays`)
is exposed and also used in GHC.Runtime.Eval to allocate a break array
when a breakpoint is set, if it doesn't exist yet (in the linker env).

8016561f
by Simon Peyton Jones at 2025-07-08T07:41:13-04:00
```
Add a test for T26176
```

454cd682

by Simon Peyton Jones at 2025-07-08T07:41:13-04:00

Add test for #14010

This test started to work in GHC 9.6 and has worked since.
This MR just adds a regression test

ea2c6673

by Teo Camarasu at 2025-07-08T13:24:43-04:00

Implement user-defined allocation limit handlers

Allocation Limits allow killing a thread if they allocate more than a
user-specified limit.
We extend this feature to allow more versatile behaviour.

- We allow not killing the thread if the limit is exceeded.
- We allow setting a custom handler to be called when the limit is exceeded.

User-specified allocation limit handlers run in a fresh thread and are passed
the ThreadId of the thread that exceeded its limit.

We introduce utility functions for getting and setting the allocation
limits of other threads, so that users can reset the limit of a thread
from a handler. Both of these are somewhat coarse-grained as we are
unaware of the allocations in the current nursery chunk.

We provide several examples of usages in testsuite/tests/rts/T22859.hs

Resolves #22859

03e047f9
by Simon Hengel at 2025-07-08T13:25:25-04:00
```
Fix typo in using.rst
```

67957854

by Ben Gamari at 2025-07-09T09:44:44-04:00

compiler: Import AnnotationWrapper from ghc-internal

Since `GHC.Desugar` exported from `base` has been deprecated.

813d99d6
by Ben Gamari at 2025-07-09T09:44:44-04:00
```
ghc-compact: Eliminate dependency on ghc-prim
```
0ec952a1
by Ben Gamari at 2025-07-09T09:44:44-04:00
```
ghc-heap: Eliminate dependency on ghc-prim
```
480074c3
by Ben Gamari at 2025-07-09T09:44:44-04:00
```
ghc-heap: Drop redundant import
```

03455829

by Ben Gamari at 2025-07-09T09:44:45-04:00

ghc-prim: Bump version to 0.13.1

There are no interface changes from 0.13.0 but the implementation now
lives in `ghc-internal`.

d315345a

by Ben Gamari at 2025-07-09T09:44:45-04:00

template-haskell: Bump version number to 2.24.0.0

Bumps exceptions submodule.

004c800e
by Ben Gamari at 2025-07-09T09:44:45-04:00
```
Bump GHC version number to 9.14
```

eb1a3816

by Ben Gamari at 2025-07-09T09:44:45-04:00

Bump parsec to 3.1.18.0

Bumps parsec submodule.

86f83296
by Ben Gamari at 2025-07-09T09:44:45-04:00
```
unix: Bump to 2.8.7.0

Bumps unix submodule.
```

89e13998

by Ben Gamari at 2025-07-09T09:44:45-04:00

binary: Bump to 0.8.9.3

Bumps binary submodule.

55fff191

by Ben Gamari at 2025-07-09T09:44:45-04:00

Win32: Bump to 2.14.2.0

Bumps Win32 submodule.

7dafa40c

by Ben Gamari at 2025-07-09T09:44:45-04:00

base: Bump version to 4.22.0

Bumps various submodules.

ef03d8b8

by Rodrigo Mesquita at 2025-07-09T09:45:28-04:00

base: Export displayExceptionWithInfo

This function should be exposed from base following CLC#285

Approved change in CLC#344

Fixes #26058

49558e40
by Hassan Al-Awwadi at 2025-07-09T17:05:04+02:00
```
Add the option to depend on a directory.
```

c8bf3a56

by Hassan Al-Awwadi at 2025-07-09T17:05:04+02:00

this commit takes the previously defined getDirHash and moves it from Fingerprints module to being locally defined within GHC.Unit.Finder (which is lower in the module tree that GHC.HsToCore.Usage).

This way we avoid altering GHC.Internals or base, which is maybe for the best, but one could argue it really does belong inside Fingerprint...

c305925d