Marge Bot pushed to branch wip/marge_bot_batch_merge_job 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 - - - - - bafe47cb by Alan Zimmerman at 2026-07-01T20:46:42-04:00 EPA: Remove LocatedLW from MatchGroup This is the last usage of LocatedLW / SrcSpanAnnLW - - - - - 39 changed files: - compiler/GHC/Hs/Dump.hs - compiler/GHC/Hs/Expr.hs - compiler/GHC/Hs/Utils.hs - compiler/GHC/Iface/Ext/Ast.hs - compiler/GHC/Parser.y - compiler/GHC/Parser/Annotation.hs - compiler/GHC/Parser/PostProcess.hs - compiler/GHC/Parser/Types.hs - compiler/GHC/Rename/Bind.hs - compiler/GHC/Rename/Utils.hs - compiler/GHC/Tc/Gen/Arrow.hs - compiler/GHC/Tc/Gen/Do.hs - compiler/GHC/Tc/Gen/Expr.hs - compiler/GHC/Tc/Gen/Match.hs - compiler/GHC/Tc/TyCl/PatSyn.hs - compiler/GHC/ThToHs.hs - rts/Capability.c - rts/Capability.h - rts/Messages.c - rts/Schedule.c - rts/Ticker.h - rts/posix/Ticker.c - rts/sm/GC.c - testsuite/tests/ghc-api/exactprint/T22919.stderr - testsuite/tests/ghc-api/exactprint/ZeroWidthSemi.stderr - testsuite/tests/module/mod185.stderr - testsuite/tests/parser/should_compile/DumpParsedAst.stderr - testsuite/tests/parser/should_compile/DumpParsedAstComments.stderr - testsuite/tests/parser/should_compile/DumpRenamedAst.stderr - testsuite/tests/parser/should_compile/DumpSemis.stderr - testsuite/tests/parser/should_compile/DumpTypecheckedAst.stderr - testsuite/tests/parser/should_compile/KindSigs.stderr - testsuite/tests/parser/should_compile/T15279.stderr - testsuite/tests/parser/should_compile/T20718.stderr - testsuite/tests/parser/should_compile/T20846.stderr - testsuite/tests/parser/should_compile/all.T - testsuite/tests/printer/Test20297.stdout - testsuite/tests/printer/Test24533.stdout - utils/check-exact/ExactPrint.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/12d6eb4b4bcffa42f6cade0dc2a8d5c... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/12d6eb4b4bcffa42f6cade0dc2a8d5c... You're receiving this email because of your account on gitlab.haskell.org.