Repository navigation
clippy: fix the remaining lints on aarch64-linux and macOS - #33958
Conversation
`cargo clippy` passes on x86_64-linux after the previous two commits, but the workspace is still not clean on the other hosts contributors and CI builds run. `ptr_cast_constness` on aarch64, where `c_char` is `u8` so these casts change only constness (on x86_64 `c_char` is `i8`, so the type changes too and the lint stays quiet): - `bun_core::util::dupe_z` `p as *const c_char` - `bun_alloc::free_sensitive_cstr` `p as *mut u8`, `p as *mut c_void` Rewritten with `.cast()` / `.cast_const()` / `.cast_mut()`, which are `#[inline(always)] self as _` in core — the same single `PtrToPtr` cast, same address, same provenance. The `*const` -> `*mut` laundering in `free_sensitive_cstr` is pre-existing and unchanged; the pointer's root is a `default_alloc::malloc` allocation that `dupe_z` already wrote through. `derivable_impls` on macOS for `Sendfile`: the impl is only derivable where the linux/android-gated fields are absent, and `Fd` has no `Default` impl, so `#[derive(Default)]` would not compile there. Suppressed with the reason recorded; `#[allow]` rather than `#[expect]` since the lint does not fire on linux. Verified `cargo clippy --workspace --no-deps --keep-going` exits 0 on all three: macOS arm64 (host), x86_64-unknown-linux-gnu (what the Clippy workflow runs), and aarch64-unknown-linux-gnu.
|
Updated 7:28 PM PT - Jul 10th, 2026
@cirospaciari, your commit cf55bed is building: |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
WalkthroughChangesPointer and lint updates
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
Comment |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — mechanical clippy fixes with no behavioral change.
What was reviewed:
.cast()/.cast_const()/.cast_mut()rewrites indupe_zandfree_sensitive_cstr— same address/mutability/pointee as the originalascasts, just split so the constness change is explicit.- Confirmed
Fdderives noDefault(src/bun_core/util.rs:932), so#[derive(Default)]onSendfilewould indeed fail on linux/android;#[allow]over#[expect]is correct given the lint only fires on non-linux targets.
Extended reasoning...
Overview
Three-file follow-up to #33951 fixing target-specific clippy lints: two ptr_cast_constness sites in bun_alloc::free_sensitive_cstr / bun_core::util::dupe_z rewritten from as to .cast() chains, and one #[allow(clippy::derivable_impls, reason = ...)] on Sendfile's manual Default impl in FileResponseStream.rs.
Security risks
None. The pointer casts are byte-for-byte equivalent to the previous as casts (cast/cast_const/cast_mut are #[inline(always)] wrappers around self as _). The *const → *mut laundering in free_sensitive_cstr is pre-existing and its soundness argument (root allocation is a writable default_alloc::malloc block) is unchanged. The Sendfile change is a lint attribute only — the impl body is untouched.
Level of scrutiny
Low. This is lint hygiene with zero runtime semantic change, in the same vein as the immediately preceding #33951. I traced each rewritten cast: dupe_z's p is *mut u8, so p.cast_const().cast::<c_char>() = *const c_char (same as before); free_sensitive_cstr's p is *const c_char, so .cast::<u8>().cast_mut() = *mut u8 and .cast::<c_void>().cast_mut() = *mut c_void (same as before). Verified Fd has no Default impl, making the suppression's stated reason accurate, and the #[allow]-not-#[expect] choice is correct since the lint is absent on linux where warnings = deny would flag an unfulfilled expectation.
Other factors
No CODEOWNERS on the touched paths. No prior review comments. Bug hunter found nothing. The PR description's verification (clippy clean on all three targets, cargo fmt --check, path tests passing) is appropriate for a no-behavior-change lint fix.
3 participants
Follow-up to #33951, which unbroke
cargo clippyon the Clippy workflow's runner (x86_64-unknown-linux-gnu). The workspace is still not clean on the other hosts, sobun run rust:clippyfails for anyone developing on an Apple Silicon Mac, and for the aarch64 Linux target.Measured on
main(55ba6e453c) vs this branch,cargo clippy --workspace --no-deps --keep-going:mainptr_cast_constness— aarch64 onlyc_charisu8on aarch64 andi8on x86_64, so these casts change only constness on aarch64 and the lint fires there but not on the runner:bun_core::util::dupe_z—p as *const c_charbun_alloc::free_sensitive_cstr—p as *mut u8,p as *mut c_voidRewritten with
.cast()/.cast_const()/.cast_mut(). These are not "smarter" thanas: incorethey are literally#[inline(always)] pub const fn cast_const(self) -> *const T { self as _ }, so each rewrite is the same singlePtrToPtrcast with the same address and the same provenance.The
*const→*mutlaundering infree_sensitive_cstris pre-existing and unchanged by this PR. The pointer's root is adefault_alloc::mallocallocation thatdupe_zalready wrote through, so writing through it here was sound before and is sound now — Rust does not track mutability in raw-pointer provenance.derivable_impls— macOS onlySendfile'sDefaultimpl is only derivable where the#[cfg(any(target_os = "linux", target_os = "android"))]fields are absent. On linux/android the impl carriessocket_fd: Fd::INVALID, andFdhas noDefaultimpl at all —#[derive(Default)]would not compile there. Suppressed with the reason recorded.#[allow]rather than#[expect]in both suppression sites, because an expectation would go unfulfilled on the platform where the lint doesn't fire, andwarnings = "deny"would turn that into an error.Verification
cargo clippy --workspace --no-deps --keep-goingexits 0 on all three targets above (andcargo fmt --checkis clean). Builtbun-debugand exercised the touched crates through the CLI —path.resolve/path.win32.normalize,process.env,Bun.spawnSync— plusbun bd test test/js/node/path/→ 122 pass, 0 fail.Reverting just this commit reproduces both failures on macOS and aarch64, so the changes are load-bearing.