GitLab

Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC

Commits:

b6a2ecc7

by Berk Özkütük at 2025-07-07T10:39:41-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.

9ec94cc9

by Ryan Hendrickson at 2025-07-07T10:39:46-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.

f7fb75aa

by Rodrigo Mesquita at 2025-07-07T10: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

5529a4d8

by Rodrigo Mesquita at 2025-07-07T10: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]

92044eb0

by Rodrigo Mesquita at 2025-07-07T10: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

2e77d5be

by Rodrigo Mesquita at 2025-07-07T10: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]

9a8739cc

by Rodrigo Mesquita at 2025-07-07T10:39:48-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

d85d6c41
by Ben Gamari at 2025-07-07T10:39:48-04:00
```
users-guide: Reference Wasm FFI section
```
e13546fb
by Ben Gamari at 2025-07-07T10:39:49-04:00
```
users-guide: Fix too-short heading warning
```

1a395f27