lance-graph-contract: make the aarch64 NEON path actually compile - #1200
Conversation
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Essentials Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe AArch64 NEON implementation now imports the required feature-detection macro and passes compile-time shift values to dimension extraction. Documentation records the compiler defects, fixes, and architecture verification. ChangesAArch64 NEON compilation
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: Poem
✨ Finishing Touches📝 Generate docstrings
Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_a8cacac7-830d-4bef-9cce-ea57681c8ca6) |
Three compiler errors, all inside `#[cfg(target_arch = "aarch64")]` blocks in `mul.rs`, and all present since the code was written. Nothing had ever built this crate for aarch64, so nothing had ever parsed them. Surfaced by `AdaWorldAPI/q2#146`: that fork's test suite had been gated to `if: github.repository == 'quarto-dev/q2'` and so had never run. Un-gating it put this crate on a macOS aarch64 runner for the first time: error: cannot find macro `is_aarch64_feature_detected` in this scope --> crates/lance-graph-contract/src/mul.rs:983 error[E0435]: attempt to use a non-constant value in a constant --> crates/lance-graph-contract/src/mul.rs:1467 (and :1468) Two independent defects: 1. `is_aarch64_feature_detected!` is NOT re-exported at the root of `std` — its x86 sibling is, which is precisely why this is easy to get wrong: the x86 arm two lines above compiles bare. Added `use std::arch::…` inside the aarch64 block. 2. `vshrq_n_u64` is an `_n_` intrinsic: the shift is encoded into the instruction and must be a constant, but `extract_dim_pair` took `shift: i32` as a runtime argument. All eight call sites already passed literals (36, 4, 8, 12, 56), so this is an exact mechanical change to a `const SHIFT: i32` parameter — no behaviour and no redesign. Verified, reproduce-then-fix: rustup target add aarch64-unknown-linux-gnu cargo check -p lance-graph-contract --target aarch64-unknown-linux-gnu --all-targets -> the same 3 errors, before the change cargo clippy -p lance-graph-contract --target aarch64-unknown-linux-gnu --all-targets -- -D warnings -> clean, after cargo clippy -p lance-graph-contract --all-targets -- -D warnings # native x86_64 -> clean, unchanged cargo test -p lance-graph-contract -> 21 passed, 0 failed cargo fmt -p lance-graph-contract -- --check -> clean The change is entirely inside aarch64-gated blocks, so x86_64 codegen is untouched by construction as well as by measurement. Board: `.claude/board/EPIPHANIES.md` gains E-THE-AARCH64-PATH-HAD-NEVER-BEEN-COMPILED-1. The finding worth keeping is not either bug but the class: `#[cfg(target_arch = ...)]` code is unparsed, untypechecked text on every machine that is not that arch — indistinguishable from a comment — so an arch-gated path without a build for that arch is a plan, not code. For a zero-dep crate the check costs one `rustup target add` and a few seconds. Whether this repo's CI should carry that job is the open question this leaves; it currently does not. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AGVLyRZNEKKBSfBDJfbY3V
`citation-decay` failed on the first push of this entry, and it was right.
The entry quoted the compiler output verbatim, including
`crates/lance-graph-contract/src/mul.rs:983` and `:1467`/`:1468`. Those are
citations into a file that this very PR edits, so the fix moved both — a
coordinate into a moving frame, decayed by construction the moment it landed.
Per the tool's own instruction ("THE FIX IS NOT TO CORRECT THE LINE NUMBER"),
the numbers are replaced with stable addresses: the aarch64 arm of the
SIMD-caps probe, and `extract_dim_pair`. The exact line numbers survive in this
PR's body and in the previous commit message, neither of which is a citation
surface. The entry now also records that the check caught it, because "the
citation moved because the fix moved it" is the mechanism the rule exists for
and is worth one sentence in the entry itself.
Verified locally by reproducing the failure first:
python3 .claude/tools/citation_decay.py --since 3797237
before: 1 new decay(s), 147 pre-existing
after: 0 new decay(s), 147 pre-existing, 0 fixed since base
The 147 pre-existing are the untouched backlog the check does not fail on.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AGVLyRZNEKKBSfBDJfbY3V
f3e4094 to
422f4f4
Compare
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_de353016-caae-4924-a89c-23bc37341383) |
Three compiler errors, all inside
#[cfg(target_arch = "aarch64")]blocks inmul.rs, and all present since the code was written. Nothing had ever builtthis crate for aarch64, so nothing had ever parsed them.
How it surfaced
AdaWorldAPI/q2#146. That fork's test suite had been gated toif: github.repository == 'quarto-dev/q2', so it had never run there. Un-gatingit put
lance-graph-contract(a path-dep of q2 via[patch]) on a macOSaarch64 runner for the first time:
The two defects
1 ·
is_aarch64_feature_detected!is not at the root ofstd. Its x86sibling is, which is exactly why this is easy to get wrong — the x86 arm two
lines above compiles bare. The aarch64 macro lives under
std::arch. Added theimport inside the aarch64 block.
2 ·
vshrq_n_u64is an_n_intrinsic. The shift is encoded into theinstruction, so it must be a constant — but
extract_dim_pairtookshift: i32as a runtime argument. All eight call sites already passedliterals (36, 4, 8, 12, 56), so this is an exact mechanical change to a
const SHIFT: i32parameter. No behaviour change, no redesign, no call sitesemantically altered.
Verification — reproduce first, then fix
The change is entirely inside aarch64-gated blocks, so x86_64 codegen is
untouched by construction as well as by measurement.
The finding worth keeping
Not either bug — the class.
#[cfg(target_arch = ...)]code is unparsed,untypechecked, uncompiled text on every machine that is not that arch:
indistinguishable from a comment. Both defects would have been caught by
the compiler the first time anything built for aarch64, and nothing ever had.
For a zero-dep crate like this one the check costs one
rustup target addanda few seconds. Whether this repo's CI should carry an aarch64 check job is
the open question this leaves — it currently does not, and the defect reached
mainand stayed there.One more detail worth recording: the discovery came from a consumer's CI, on
a platform this repo does not test, during a run whose purpose was entirely
unrelated. Un-gating a suite that has never run is a measurement, and it
returns findings that are not about the change being made.
Board:
.claude/board/EPIPHANIES.mdgainsE-THE-AARCH64-PATH-HAD-NEVER-BEEN-COMPILED-1(prepended, append-only).🤖 Generated with Claude Code
https://claude.ai/code/session_01AGVLyRZNEKKBSfBDJfbY3V
Summary by CodeRabbit
Bug Fixes
Tests