[shinaoka]

Closes #59.

The committed Cargo.lock carried t4a-faer 0.28.0 with no source line: it was written
from a campaign build whose patch pointed at a checkout, so it was never a registry lock. Any
plain cargo command re-resolved >=0.24,<1.0 to the newest release (0.33.0) and rewrote the
file. Against 0.33 the harness adapter failed with 21 errors (Par::rayon, E0308 at every
parmod::shape(par)), because its two API generations were only reachable through features that
scripts/build_for_faer_rev.sh turns on from the checkout it is given. No lane read the lock, so
nothing noticed.

What changed

• The lock is a registry lock at the pin's version. cargo update -p t4a-faer --precise 0.28.0
  records pins/t4a-faer.rev's version (325e482, t4a-faer 0.28.0) with its source, so
  --locked is meaningful and the campaign's path patch still matches the version the pin names.
• The harness defaults are that generation: default = ["fork-par-shape", "fork-team"]
  (0.25's ParShape workspace queries, 0.26's team-only parallelism). build_for_faer_rev.sh
  passes --no-default-features when its own detection (the checkout declares pub enum ParShape / with_team) finds an older generation, so a 0.24-style checkout gets no defaults; that path needs more than the flag (it also lacks faer_fork/threadteam) and is tracked in fbench: the older-generation build path (pre-ParShape / pre-team fork) is not buildable #61. The fallback itself is untested end to end.
• A harness CI job runs cargo check -p fbench --locked and cargo test -p fbench --bins --locked. It is a lock/manifest consistency check -- no vendor, no measured revision -- which is
  the distinction the workflow comment makes for not having a smoke job. ubuntu-slim has no
  cargo, so it runs on ubuntu-latest.

Verification

• cargo check -p fbench --locked at this head: compiles (16.29 s on this Mac, cold-ish).
• cargo test -p fbench --bins --locked: 6 passed, 0 failed (49.70 s).
• bash -n scripts/build_for_faer_rev.sh: clean.
• Not run: a full vendor/campaign build (and the older-generation path, fbench: the older-generation build path (pre-ParShape / pre-team fork) is not buildable #61). The script change only adds --no-default-features for
  older generations; the patch/preflight path is untouched, and the lock now names the pin's
  version, which is the identity the preflight compares.

[shinaoka]

GPT-6.1-sol adversarial review

CRITICAL: none
NEEDS_CHANGES: 1
UNVERIFIED: 1

Critical (must not merge)

none

Needs changes

• Cargo.lock:1813–1815 — The new registry lock breaks builds of the currently pinned campaign revision. pins/t4a-faer.rev:70 still names 325e482… (t4a-faer 0.28.0), but Cargo retains the locked registry 0.33.0 instead of selecting the supplied 0.28.0 path patch; consequently, scripts/build_for_faer_rev.sh:270–274 exits during preflight, before reaching the modified build command.
  • Reproduce: In a disposable copy of this PR, set FORK to a checkout at 325e482b6532624d06236ad6991a41c57b0c23d1 and UPSTREAM to the upstream 0.24.4 checkout, then run:

    bash scripts/faer_patch_preflight.sh \
      --manifest "$PWD/Cargo.toml" \
      --fork-manifest "$FORK/faer/Cargo.toml" \
      --upstream-manifest "$UPSTREAM/faer/Cargo.toml" \
      --config "patch.crates-io.t4a-faer.path=\"$FORK/faer\"" \
      --config "patch.crates-io.faer.path=\"$UPSTREAM/faer\""

  • Observed: Using isolated copies of the actual manifests and locks, with cached published 0.28.0 and upstream 0.24.4 as the patch paths, the base 01a1cb8 preflight exits 0, while head 5e3c3ae exits 1: this build would link t4a-faer from '…/t4a-faer-0.33.0/Cargo.toml', not from '…/t4a-faer-0.28.0/Cargo.toml'.
  • Required correction: Re-resolve the campaign’s temporary lock against the requested checkout before checking its identity, while preserving registry-arm locking and restoring the committed lock afterward; add a regression test for the pinned 0.28.0 checkout. The registry-only commands at .github/workflows/ci.yml:63–65 cannot detect this failure, contradicting the PR’s “campaign build is unaffected” claim.

Unverified claims

• fbench/Cargo.toml:29, Cargo.lock:1813 — The reported local “0.22 s warm,” “36.55 s,” and “21 errors before” lack an attached baseline transcript. The head CI log establishes six passing tests, but not those local timings or the historical error count; reproducing those claims requires running the stated commands on both revisions with the original toolchain, cache state, and lock-resolution conditions.

Checked and fine

Read CI runs 42601624180 and 42601634139: both identify head 5e3c3ae…; the inspected harness log reports six passed, zero ignored, zero filtered out.
bash -n scripts/build_for_faer_rev.sh passes.
Not run: a full vendor/campaign build or local Rust test suite; the campaign lock-resolution failure was reproduced without compilation.

---

Reviewed head: 5e3c3ae52dffea44aa9b1bf0b6a695560cd69628 at 2026-11-09T10:34:32Z. This review is valid only for that commit: if the head has moved, it is a review of a tree that is not being merged.
Automated (gpt_review.sh). This is an enumeration of counterexamples, not a verdict; the merge decision stays with a human.

[shinaoka]

GPT-6.1-sol adversarial review

CRITICAL: none
NEEDS_CHANGES: 2
UNVERIFIED: 1

Critical (must not merge)

none

Needs changes

• The older-generation fallback does not establish the compatibility claimed in the PR. scripts/build_for_faer_rev.sh:233–235,270–274,285: --no-default-features is applied only to the build, after a preflight that resolves with defaults and can reject the checkout before reaching that build.

  • Reproduction: In a disposable copy of 3515235, invoke scripts/faer_patch_preflight.sh with --manifest <copy>/Cargo.toml, fork/upstream manifest paths, and the corresponding two path patches, using t4a-faer 0.24.9 as the fork. With real Cargo and the committed lock, this exits 1: the resolved fork is the registry’s 0.28.0, not the supplied 0.24.9.
  • Trying to re-resolve with cargo update --offline -p t4a-faer --precise 0.24.9 --config 'patch.crates-io.t4a-faer.path="<0.24.9-directory>"' also fails: fbench references the dependency feature threadteam, which 0.24.9 does not provide (fbench/Cargo.toml:37). Removing the new defaults in the disposable copy did not remove that resolution failure.
  • These are existing compatibility obstacles, not proof that this PR introduced them; however, the added fallback does not justify “a 0.24-style checkout keeps working.” Either demonstrate that supported path with a regression test or remove that compatibility claim. Deleting the new fallback still passed all nine non-mutation preflight tests; the separate existing retry-mutation test was excluded from that run.

• The new script comment names a dependency version that this PR does not test. scripts/build_for_faer_rev.sh:227–228 says the committed lock selects t4a-faer 0.33, whereas Cargo.lock:1813 selects 0.28.0.

  • Reproduction: Compare git show 3515235:scripts/build_for_faer_rev.sh with git show 3515235:Cargo.lock. The new CI commands use --locked, so their success establishes compilation against 0.28.0, not 0.33. Correct the comment to match the actual lock.

Unverified claims

• The historical “21 errors” count and local timing figures are unverified. The PR body associates those errors with the unconfigured branches at fbench/src/backend.rs:58 and the scratch-query call sites, but the underlying historical compiler transcript and the reported Mac timing logs cannot read from the supplied artifacts. Reproducing that count requires checking the pre-change harness against registry 0.33.0; the current head’s successful locked CI does not establish it.

Checked and fine

• Actions run 42602888437 reports head SHA 35152357174a5b0723a260fbed69e848efe3bcab; its logs show both locked Cargo commands succeeding and 6 passed, 0 failed, 0 ignored.
• The unmodified preflight test suite passed all 10 tests locally.
• Not checked: full vendor/campaign builds or older-generation end-to-end compilation; local cache verification timed out, and local Rust compilation was not rerun.

---

Reviewed head: 35152357174a5b0723a260fbed69e848efe3bcab at 2026-11-09T10:42:21Z. This review is valid only for that commit: if the head has moved, it is a review of a tree that is not being merged.
Automated (gpt_review.sh). This is an enumeration of counterexamples, not a verdict; the merge decision stays with a human.

[shinaoka]

GPT-6.1-sol adversarial review

CRITICAL: none
NEEDS_CHANGES: 0
UNVERIFIED: 1

Critical (must not merge)

none

Needs changes

none

Unverified claims

• Campaign-path compatibility remains unverified — scripts/build_for_faer_rev.sh:272-287, Cargo.lock:1813-1815, and Cargo.lock:1835-1838: unchanged preflight code does not establish unchanged behavior with the new registry lock, which also changes t4a-faer-traits from 0.24.2 to 0.24.3; .github/workflows/ci.yml:63-65 never invokes this path. To verify, use fork checkout 325e482b6532624d06236ad6991a41c57b0c23d1 and the pinned upstream checkout, run bash scripts/build_for_faer_rev.sh --checkout <fork> --upstream <upstream> --vendor openblas --out /tmp/fbench-build.env, then inspect Cargo.lock.resolved and confirm the committed lock was restored byte-for-byte. This review did not execute that build; the PR explicitly acknowledges the missing evidence.

Checked and fine

• Head-specific push run 42603870575 targets cdbd50005703d0c331cdcd25c9fbae807a01bd6d; its logs show both locked Cargo commands ran and 6 passed, 0 failed, 0 ignored, 0 filtered out.
• bash -n scripts/build_for_faer_rev.sh passed on an extracted copy of that exact head.
• Not checked: full vendor/campaign build or older-generation execution; registry CI does not establish either path’s buildability.

---

Reviewed head: cdbd50005703d0c331cdcd25c9fbae807a01bd6d at 2026-11-09T10:48:24Z. This review is valid only for that commit: if the head has moved, it is a review of a tree that is not being merged.
Automated (gpt_review.sh). This is an enumeration of counterexamples, not a verdict; the merge decision stays with a human.

[shinaoka]

Campaign-path check requested by the review, run on this Mac without a vendor build (preflight only):

FORK=/tmp/faer-325           # worktree at 325e482 (t4a-faer 0.28.0, the pin)
UPSTREAM=.../faer-0.24.4     # upstream faer 0.24.4
bash scripts/faer_patch_preflight.sh --manifest $PWD/Cargo.toml \
  --fork-manifest $FORK/faer/Cargo.toml --upstream-manifest $UPSTREAM/Cargo.toml \
  --config patch.crates-io.t4a-faer.path="$FORK/faer" \
  --config patch.crates-io.faer.path="$UPSTREAM"

Result: the preflight passes (no identity error). The same command on head 5e3c3ae failed with
this build would link t4a-faer from .../t4a-faer-0.33.0/Cargo.toml, not from .../t4a-faer-0.28.0/Cargo.toml`` because that head's lock named 0.33. So the registry lock at the
pin's version puts the campaign patch back on the path it selects.

One thing the preflight does: cargo metadata rewrites Cargo.lock to the path entries (it removed
the source/checksum of t4a-faer, faer and downgraded t4a-faer-traits to the checkout's
0.24.2). That is cargo's normal behaviour when a patch applies, and it is the same on the base
(01a1cb8); this PR does not change it, and the campaign build copies its own resolved lock aside.
Not run: the full --vendor openblas build (it builds OpenBLAS from source), so the binary-level
campaign build remains unexercised here.