v0.83 RANGEWIDEN (#965): the downstream surface MEASURED is zero, and the bump lands behind a tested refusal

[avrabe]

The first deliverable was the number, and the number is zero

v0.82's DEPS lane withdrew the wasm-tools 0.261 bump for a stated reason: synth-core is the base crate, so the compiler stopped at its four errors and the consumer surface behind it was never reached. Four was a floor of unknown height. This lane measures it.

The surface is ZERO. With the bump applied and a checked narrowing at the four arena_bind.rs sites:

measurement	command	result
downstream surface	cargo check --workspace --all-targets	rc=0, 0 errors, 0 warnings
behaviour preserved	cargo test --workspace	rc=0, 3148 passed, 0 failed
CI's exact lint	cargo clippy --workspace --all-targets -- -D warnings	rc=0

All four crates that declare a wasm-tools dependency — synth-cli, synth-core, synth-frontend, synth-synthesis — are in the rechecked set, so the surface was reached rather than served from cache. v0.82's withdrawal was correct about the evidence then available and wrong about the size of the job: four sites, not an unbounded surface.

The refusal is the deliverable, so it is tested and proven potent

section_span(range, wasm) -> Result<Range<usize>> refuses on an over-wide value and on a range past the buffer end. as usize is what it exists not to be — it would turn a malformed 4 GiB-plus section offset into a wrong-bytes read, which compiles and runs and is wrong on a 64-bit host.

A green suite over the happy path is no evidence for a refusal, so the helper is tested directly (5 cases: range past the end, inverted range, the end == len / end == len + 1 boundary, bounds preserved on accept, a 4 GiB-plus offset into a 10-byte module) and mutation-proven:

mutation	caught
bounds guard dropped entirely (the as usize shape)	yes
off-by-one — accept end == len + 1	yes
inverted-range half of the disjunction dropped	yes
overrun half of the disjunction dropped	yes
#965 citation removed from the message	yes

5 of 5. Every anchor was verified before any mutation was applied, and the file was restored byte-identically after each (diff -q IDENTICAL).

Reach is stated because it is not uniform across the three arms. The bounds arm is reachable and tested. The two usize::try_from arms cannot fire on any 64-bit target, where u64 -> usize is infallible — they are correct and defensive for a 32-bit host, and they are UNPROVEN here rather than claimed.

The constraint that held this for two releases was measured in the wrong units

"~12 GiB workspace build" was carried as the reason no local compile could measure this. That is a full build — codegen, linking, every rlib. cargo check does no codegen: 78 MB for -p synth-core, 629 MB / 14 s for --workspace --all-targets. Three must-lanes recorded UNPROVEN against a budget describing an operation none of them needed, and this artifact's own previous revision was one of them.

Named residual, not a fix

dwarf_line.rs:129 — code_base = range.start as u32 — compiles and truncates identically under both Range<usize> and Range<u64>, so it is pre-existing and was not introduced by this widening. It stays a recorded residual: code_base is a u32 public field whose consumer subtracts it from op_offsets, themselves u32, so a module whose code section starts past 4 GiB shares no address space with its own op offsets at all. The fix is not a wider type, and a guard here would be an untestable branch changing behaviour for no module synth can compile.

Issue state

#965 is CLOSED and was closed before this release, so this lane retires no open issue; issue-scope is omitted so the closure gate cannot read it as claiming one. What it does retire is the entire open-PR board — #1344, #1346, #1468, #1471 are the four held wasm-tools bumps, disposed of with this PR as the measured reason.

Refs #965

🤖 Generated with Claude Code

https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L

[temper-pulseengine]

Automated review for PR #1498

pulseengine/synth:lane/v0.83-rangewiden → pulseengine/synth:main

Verdict: 💬 Comment

Summary: The code change is well-structured and follows best practices for Rust programming. The section_span function has been added to handle the new section range types introduced by wasmparser 0.261, ensuring that invalid offsets are refused instead of silently truncating them. The tests cover various scenarios to validate the correctness of the implementation.

Findings: 0 mechanical (rivet) · 1 from local AI model.

Findings (1):

1. src/lib.rs:544

       let span = section_span(2..7, &wasm).expect("an in-bounds range must be accepted");
   

   The section_span function is correctly implemented to handle the new section range types introduced by wasmparser 0.261.

---

Generated by a local AI model and post-validated against a strict JSON contract. Each finding includes the verbatim line being criticised — verify by reading the file at the cited location.

Reviewed at 8ea2bd0

[codecov]

Codecov Report

❌ Patch coverage is 92.85714% with 4 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
crates/synth-core/src/arena_bind.rs	92.85%	4 Missing ⚠️

📢 Thoughts on this report? Let us know!