Skip to content

merge queue: checking #12407 on master (ad1170e), stacked on #12453 - #12455

Closed
mergify[bot] wants to merge 10 commits into
masterfrom
mergify/merge-queue/28beeaa28e
Closed

merge queue: checking #12407 on master (ad1170e), stacked on #12453#12455
mergify[bot] wants to merge 10 commits into
masterfrom
mergify/merge-queue/28beeaa28e

Conversation

@mergify

@mergify mergify Bot commented Oct 13, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Note

This is a merge queue draft opened by Mergify. Nobody needs to act on it.
Mergify opened it for batch taxonomic-pelardon-c071tc of the squash-merge queue, to test #12407 before it merges into master. Pushing to this branch or closing this pull request removes #12407 from the queue.

What this draft tests

Mergify checks that #12407 still passes CI once combined with everything queued ahead of it. CI runs on this draft's code, built in this order:

  1. master at ad1170e
  2. the pull request queued ahead of this batch, listed below, which brings the tip to fe1a0e3
  3. #12407, the pull request of this batch

The check is speculative: it assumes the pull requests ahead will merge, so it starts without waiting for them.

🎉 Where it stands: checks passed

CI passed on this draft.

Follow the squash-merge queue in the dashboard

What happens next

  • Once the pull requests ahead have merged, Mergify merges #12407 into master and closes this draft.
  • If a pull request ahead fails or leaves the queue without merging, this batch is requeued and checked again on a new draft: these checks assumed it would merge.

Tip

A red check is not necessarily caused by this batch. These checks run on a tip that also carries the commits of the pull request ahead, so a failure here can come from it as much as from #12407. See only this batch's changes.

Queued ahead of this batch

This pull request entered the queue before this batch and is not part of it.

Metadata for CI tooling, read by mergify ci 
---
all_scopes: false
checking_base_sha: fe1a0e3eb42a377eecd786333077a6a683e16618
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 12407
    scopes: []
scopes: []
...
Required conditions of queue rule squash-merge for merge
  • #review-threads-unresolved = 0 [🛡 GitHub branch protection]
  • github-review-approved [🛡 GitHub branch protection]
  • any of [🛡 GitHub branch protection]:
    • check-success = Doctest Cabal
    • check-neutral = Doctest Cabal
    • check-skipped = Doctest Cabal
  • any of [🛡 GitHub branch protection]:
    • check-success = Meta checks
    • check-neutral = Meta checks
    • check-skipped = Meta checks
  • any of [🛡 GitHub branch protection]:
    • check-success = docs/readthedocs.org:cabal
    • check-neutral = docs/readthedocs.org:cabal
    • check-skipped = docs/readthedocs.org:cabal
  • any of [🛡 GitHub branch protection]:
    • check-success = Validate post job
    • check-neutral = Validate post job
    • check-skipped = Validate post job
  • any of [🛡 GitHub branch protection]:
    • check-success = fourmolu
    • check-neutral = fourmolu
    • check-skipped = fourmolu
  • any of [🛡 GitHub branch protection]:
    • check-success = hlint
    • check-neutral = hlint
    • check-skipped = hlint
  • any of [🛡 GitHub branch protection]:
    • check-success = Bootstrap post job
    • check-neutral = Bootstrap post job
    • check-skipped = Bootstrap post job
  • any of [🛡 GitHub branch protection]:
    • check-success = whitespace
    • check-neutral = whitespace
    • check-skipped = whitespace
  • any of [🛡 GitHub branch protection]:
    • check-success = Check sdist post job
    • check-neutral = Check sdist post job
    • check-skipped = Check sdist post job
  • any of [🛡 GitHub branch protection]:
    • check-success = Changelogs
    • check-neutral = Changelogs
    • check-skipped = Changelogs
Required conditions to stay in the queue

claude and others added 10 commits October 2, 2026 20:40
@claude
Run benchmarks one at a time in cabal bench (#7557)
0a1e138 
With `-j`, every plan node runs in parallel, and with per-component
builds each benchmark suite is its own node, so `cabal bench` could run
several benchmarks at the same time, from the same package or across a
project. Concurrent benchmarks compete for resources and skew each
other's results.

Add a `benchLock`, created in `rebuildTargets` next to `registerLock`
and `cacheLock`, and take it around the bench phase in
`buildAndRegisterUnpackedPackage`. Benchmarks now run one at a time,
while configuring and building other components stays parallel. The
lock is taken outside `timedDelegate`, so `--build-timings` does not
count time spent waiting for other benchmarks.

Add a cabal-testsuite test with three benchmarks in two packages, run
with `-j3`, each of which fails if another benchmark runs at the same
time.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016nzdeKCYFDCkWsyM6etgkL
@claude
Run benchmarks only once everything is built (#7557)
3f154f4 
Holding a lock while running a benchmark keeps benchmarks from running
at the same time, but other components could still be built while a
benchmark runs, which skews its results just as much.

Instead, the bench phase of a package no longer runs its benchmarks,
but records them. Once all the packages of the plan are built (still in
parallel), `rebuildTargets` runs the recorded benchmarks one at a time,
in plan order, and records their failures in the build outcomes. Unless
we keep going after failures, no benchmark is run if a package failed to
build, and no more benchmarks are run once one of them failed. See
Note [Running benchmarks].

This replaces the `benchLock` introduced by the previous commit.

The Sequential test now also checks that nothing is built once the
first benchmark started: pkg-b's benchmark depends on a library, so that
it is still being built when pkg-a's benchmarks are ready to run. The
golden outputs of MultipleBenchmarks and T5309 change accordingly:
builds now come before benchmark runs.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016nzdeKCYFDCkWsyM6etgkL
@claude
Describe plan units accurately in Note [Running benchmarks]
c7512bf 
A benchmark suite is not a package of its own: the units of the install
plan are single components, or whole packages when they cannot be built
per component. Say so in Note [Running benchmarks], and refer to units
rather than packages in the related comments.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GVJmRffSh16Wx8JR7Kd1dC
@claude
Use an IORef for the deferred benchmarks
9e82afc 
Each update of the deferred benchmarks is a transaction of its own, and
they are only read once all the units are built, so a TVar buys nothing
over an IORef updated with atomicModifyIORef'.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GVJmRffSh16Wx8JR7Kd1dC
@ulysses4ever @claude
Address review: simplify runDeferredBenchmarks, mark changelog signif…
d013dd5 
…icant

- Walk the plan's execution order directly instead of building an
  intermediate list of benchmarks; give `go` a signature and drop the
  now-redundant `BuildFailure` annotation.
- changelog.d/issue-7557.md: set the PR number, add
  `significance: significant`, and spell out the user-visible consequences.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0176vAefrw8jPKXdh9h1wKuj
@ulysses4ever @claude
Return deferred benchmarks instead of collecting them in an IORef
e799189 
The bench phase of a unit now returns its deferred benchmark, which
`rebuildTarget` returns alongside the unit's `BuildResult`, so that
`InstallPlan.execute` collects it with the other outcomes.
`runDeferredBenchmarks` then reads both from the same map, and the
`IORef` threaded through the build functions is gone.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0176vAefrw8jPKXdh9h1wKuj
@ulysses4ever @claude
Record the deferred benchmark in the unit's BuildResult
ba5377c 
Instead of being returned in a tuple next to the BuildResult, the
deferred benchmark of a unit is now a field of its BuildResult, so the
build functions keep their `IO BuildResult` type and
`runDeferredBenchmarks` works on plain BuildOutcomes. DeferredBenchmark
is a newtype over the action, which also gives it the Show instance that
BuildResult derives.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0176vAefrw8jPKXdh9h1wKuj
@philderbeast @mergify
Add GHCJS deprecation notice
c1528c7 
(cherry picked from commit 8dca5dc)
@mergify @mergify-commit-signer
Merge of #12453
fe1a0e3
@mergify @mergify-commit-signer
Merge of #12407
c24b3c6
@mergify mergify Bot mentioned this pull request Oct 13, 2026
Merged
5 of 6 tasks
@mergify mergify Bot closed this Oct 13, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/28beeaa28e branch October 13, 2026 18:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@claude @ulysses4ever @philderbeast