GitLab

Cheng Shao pushed to branch wip/terrorjack/asan at Glasgow Haskell Compiler / GHC

Commits:

6e381626

by Duncan Coutts at 2026-07-01T22:29:55+01:00

Adjust releaseCapability_ precondition to allow cap->running_task == NULL

There are two use cases for releaseCapability_:

1. The current Task (cap->running_task) releases the Capability.
   The Capability is marked free, and if there is any work to do,
   an appropriate Task is woken up.

2. There is no current task (cap->task == NULL), and thus the
   Capability is idle, and we want to wake up an idle Task to animate
   the Capability. This case uses always_wakeup.

Currently, the precondition for releaseCapability_ is
  cap->running_task != NULL
and so the 2nd use cases have to set cap->running_task (which is then
immediately overwritten) just to satisfy the precondition. See the
use cases in sendMessage and prodCapability.

So we can relax the precondition to be:
  cap->running_task != NULL || always_wakeup
so that in the always_wakeup case, we say it is ok for the
cap->running_task to be NULL.

This lets us simplify sendMessage and prodCapability. In particular it
will allow prodCapability to not need a Task parameter.

The ulterior motive for all this is that I want to be able to call
prodCapability from an OS thread that is not itself a Task, in persuit
of issue #27086: disentangle I/O managers from wakeUpRts. The most
straightforward way to wake the RTS is using prodCapability, but the
context in which we will need to do that are threads that are not Tasks.

89404ebc

by Duncan Coutts at 2026-07-01T22:29:55+01:00

prodCapability no longer needs to take a Task param

Now that releaseCapability_ can accept cap->running_task == NULL then it
is no longer necessary for prodCapability to require a Task.

4e60c5f6

by Duncan Coutts at 2026-07-01T22:29:56+01:00

Define prodOneCapability

There was an existing declaration for this in the header file, but no
definition.

Similarly, there is a declaration for prodAllCapabilities but no
definition, and we don't need it, so remove the declaration.

2527026f

by Duncan Coutts at 2026-07-01T22:29:56+01:00

Add a wakeUpRtsViaTicker feature to the posix ticker

It proxies a call to wakeUpRts, but crucially, this can be called from
a signal handler context. It will be used for ctl-c handling.

aa5a03a5

by Duncan Coutts at 2026-07-01T22:29:56+01:00

Change how wakeUpRts works

Previously it would call wakeupIOManager to get a capability to wake up
and run. This works but it entangles the I/O managers with unrelated
features: ctl-c handling and idle gc (the two features that use wakeUpRts).

The reason it used wakeupIOManager is that this action is safe to use
from a posix signal handler, since it just posts bytes to a pipe.
Otherwise the more direct approach (used e.g. by sendMessage when the
target capability is idle) is to use releaseCapability. But that uses
condition variables and mutexes, which are not safe to use from within a
signal handler.

So instead of entangling the (multiple) I/O managers with this, we make
wakeUpRts use the direct approach (using prodOneCapability). On win32
the ctl-c console handler can call wakeUpRts directly, since it is
called in a proper thread. On posix, to deal with the signal handler
problem, we make the signal handler ask the ticker thread to proxy the
call to wakeUpRts, since the ticker thread is also a proper thread.

This will allow the I/O managers to no longer be concerned with this.
This is good because there are many I/O managers (and they're
complicated), but there is (on posix) only one ticker implementation. So
this is an overall reduction in coupling and complexity.

Fixes issue #27086

c6d53c16

by sheaf at 2026-07-02T21:35:44-04:00

Test driver: normalise line numbers into libraries

When comparing the stdout of tests that print out callstacks, we can't
rely on the stability of exact line:column spans pointing into libraries
(e.g. ghc-internal), as any change (such as adding a comment) can change
them.

This commit addresses this by normalising away line:column in callstacks,
but only when those point into internal libraries. We don't do this in
general, as the exact span might be important to the test (e.g. for a
span within the test module itself).

Fixes #27387

81ee62e0

by Alan Zimmerman at 2026-07-02T21:36:33-04:00

EPA: Remove LocatedLW from MatchGroup

This is the last usage of LocatedLW / SrcSpanAnnLW

925959db

by Recursion Ninja at 2026-07-04T04:14:12-04:00

Decoupling 'L.H.S' from 'GHC.Hs.Doc'

  * Migrated 'GHC.Hs.Doc' and 'GHC.Hs.DocString' AST defintions from 'GHC.*' namespace,
    to new 'Language.Haskell.Syntax.Doc' module in the 'L.H.S' "namespace."
  * Updated 'HsDocString to be TTG-parameterised as 'HsDocString pass'.
  * Added 'GHC.Hs.Extension.Pass': splits 'GhcPass'/'Pass' and all 'HsDocString'
    TTG instances out of 'GHC.Hs.Extension', which re-exports it unchanged
    (this is backwards compatible and prevents the introduction of a boot file).
  * Deleted 'GHC.Hs.Doc.hs-boot'; removed all 'L.H.S.*' imports of 'GHC.Hs.Doc'.
  * Updated 'GHC.Hs.DocString' to be TTG pass-parameterised throughout; moved
    'mkHsDocStringChunk'/'unpackHDSC' here (require 'GHC.Utils.Encoding').
  * Split 'GHC.Rename.Doc.rnHsDoc' from 'rnHsDocIdentifiersOnly'.
  * Updated parser, renamer, typechecker, HIE, and exact-print for new types.
  * Added 'HsDocString' TTG instances for 'DocNameI' to 'Haddock.Types'.
  * Killed the last module loop between GHC.* and LHS.*.
        - Only edges from LHS.* to GHC.Data.FastString now!

Resolves #26971

b7e24044

by mangoiv at 2026-07-04T04:14:56-04:00

ci: retry fetching test metrics

Retry fetching test metrics to make the CI not fail if the services is
temporarily unavailable

4180af3f

by Zubin Duggal at 2026-07-04T04:15:38-04:00

Bump semaphore-compat submodule to 2.0.1

This versions includes some cruicial fixes for darwin

242d4317

by sheaf at 2026-07-04T04:16:19-04:00

Remove outdated comment in GHC.Data.ShortText

There was a long comment in GHC.Data.ShortText about a workaround that
was necessary when bootstrapping with GHC 9.2 and below. The actual
logic has since been dropped, but the comment remained. This commit
removes the vestigial comment.

975ed78b