Dario LipicarandClaude Opus 5 ff5dbbd489 conformance: close the arity work — retire B-arity-overflow, on measurement (#52) ...

* conformance: retire the arity cells that flipped, narrow the one that did not

18 of the 24 registered arity cells went xpass once the SDK fixes reached this
repo; the other 6 did not, and they turned out to be a different defect wearing
the same case id.

The measurement is what decided this, not a prediction. The relock was pushed
first WITHOUT these edits so the gate would report which cells actually
flipped -- and it is as well, because retiring all 24 (which is what I expected
to do) would have deleted the only thing still pointing at a live bug.

RETIRED IN FULL:
  * B-arity-overflow-identity (main), 6/6. `version("junk")` refuses.
  * B-arity-overflow (ext), 12/12 -- both cases, both providers, all three
    consumers.

NARROWED, NOT RETIRED: B-arity-overflow (main) keeps exactly one case,
failure/B/arity/too-many-zero-parameter, and its diagnosis is replaced.

THE SPLIT IS THE VOID RETURN, NOT THE ZERO ARITY. The ext table's
zero-parameter case rides `whoAmI`, which returns tstr, and it flipped with
everything else. The main table's rides `doVoid`. Only a method whose contract
says it returns NOTHING loses its refusal.

THE PROVIDER IS INNOCENT, checked rather than assumed -- in the exact store
path the failing run consumed, resolved through its derivation rather than a
store glob (a glob over every build showed no guard at all and would have sent
me to the wrong repo):

  dmcnz6gmr3amgm10xrmip5v8p8sk9bg9-logos-test_fullapi_cpp-module-lib-install
    strings ... | grep expected
      expected 0 arguments, got     <- the zero-arity guard IS there

The refusal is discarded by logos-plugin-qt's qt-host-generator, at TWO sites
on two concurrency paths. logos-plugin-qt#28 fixed the multi one and is already
in this repo's builder (verified root-to-leaf: logos-test-modules ->
logos-module-builder b06c287 -> logos-plugin-qt 048152f, which has that merge
as an ancestor). These six cells were re-measured at that builder and were
STILL xfail, which is what exposed the second site: the single-concurrency path
returns early via `kVoidMethods.contains(methodName)` before reaching the
branch #28 changed. logos-plugin-qt#29 closes it; the cells retire when a
builder carrying #29 reaches here.

NO RELOCK HERE ANY MORE. This branch carried one, to module-builder c021491;
master has since moved to b06c287, which is newer and contains all three SDK
fixes (verified by ancestry AND by content: the upper-bound emission in
cpp-sdk 937f17ed, invalid_args_max in rust-sdk 7d2192c8, qt-sdk at exactly
6a570b30). Keeping mine would have been a downgrade.

NOT REGISTERED: event/tstr on test_fullapi_rust answered WATCH_FAILED on the
`py` consumer in one run and passed in the next -- failed, passed, failed
across three otherwise identical runs. Fixed on the driver side in
logos-logoscore-py#22, not parked here: a cell that passes most of the time
would xpass and redden the gate. A flake has to be fixed or left visible.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* chore(deps): relock module-builder for the second void-refusal site

Measurement commit: B-arity-overflow's six remaining cells are left registered
on purpose, so the gate reports whether they actually flip. #28 looked complete
and did not, and re-measuring at the builder that supposedly contained it is
exactly what found the second site.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* conformance: retire B-arity-overflow — the void cells flipped

6 of 6 xpass: void/method_return on both providers across all three consumers.
Nothing else moved (pass 560, xfail 10 = M4-residual 6 + M3 4, no fail), so the
entry retires in full and the arity work is closed on both halves — the
provider refusing (logos-cpp-sdk#150, logos-rust-sdk#50) and the consumer
reporting the refusal (logos-plugin-qt#28 and #29).

It took two plugin-qt PRs because there are two void sites on two concurrency
paths, and the second was found only by re-measuring: with #28 in the builder,
verified root-to-leaf through the lock and by content in the emitter, these six
cells were STILL xfail. The fix was in the build and the cells had not moved.

Worth stating plainly, because the opposite was tempting at every step: 18 of
these 24 cells flipped one bump earlier, and retiring the whole entry then
would have deleted the six that were still broken. The glue would have gone on
reporting a provider's refusal as a successful void call, with nothing left
watching for it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* chore(deps): relock module-builder onto master

9d1139b pinned 6044ffc, the head of module-builder#218's branch, because that
was the only place the second void-refusal fix existed at the time. #218 has
merged as 464a75d, which pins the same logos-plugin-qt f668ef2 — so this is a
re-point onto master, not a content change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

2026-08-26 11:29:45 -03:00

9.8 MiB

Raw Permalink Blame History

The file is too large to be shown. View Raw