[jdx]

What

Two lints surface under a newer/nightly clippy (0.1.99) that today's stable (0.1.97) doesn't yet flag. This clears both so a cargo +nightly clippy -- -D warnings run stays green.

clippy::question_mark — crates/aube-lockfile/src/source.rs

Rewrote the trailing exec: arm of the source-kind match with the ? operator. Behavior is identical — the function already returns Option, so strip_prefix("exec:")? returns None exactly where the old else { return None } did.

deprecated Atomic::fetch_update — crates/aube/src/progress/mod.rs

fetch_update is #[deprecated(since = "1.99.0")] in favor of try_update. I did not switch to try_update: it's #[stable(since = "1.95.0")] and this repo's MSRV is 1.93, so the swap would fail the cargo-msrv gate. Instead added a scoped #[allow(deprecated)] with a comment to swap it once MSRV clears 1.95. The deprecation is nightly-only for now, so stable builds are unaffected either way.

Verification

• cargo clippy --all-targets -- -D warnings (stable 1.97) → exit 0
• cargo +nightly clippy --all-targets --all-features -- -D warnings (nightly 0.1.99) → exit 0
• cargo fmt --check clean; cargo test -p aube-lockfile passes.

Not addressed

A future-incompat warning from transitive deps (bytecheck, nix, rkyv) is upstream churn, not fixable in this repo.

🤖 Generated with Claude Code

---

Note

Low Risk
Lint-only refactors with documented identical exec: parse semantics; progress clamp logic unchanged aside from silencing a nightly-only deprecation.

Overview
Keeps cargo +nightly clippy -D warnings green with two lint-only tweaks and no intended behavior changes.

In LocalSource::parse, the exec: branch is folded into the final else arm using strip_prefix("exec:")?, matching clippy::question_mark while preserving the same Option outcomes as the old explicit return None.

In clamp_reused_to, AtomicUsize::fetch_update is left in place (MSRV 1.93 blocks switching to try_update, stable since 1.95) and a scoped #[allow(deprecated)] plus an MSRV note documents when to migrate.

^{Reviewed by Cursor Bugbot for commit e80ac67. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Warning

Review limit reached

@jdx, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 4 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Central YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro Plus

Run ID: afdcd0a8-9c1b-43af-92ea-ef3b16f8f0b8

📥 Commits

Reviewing files that changed from the base of the PR and between b73cc20 and e80ac67.

📒 Files selected for processing (2)

• crates/aube-lockfile/src/source.rs
• crates/aube/src/progress/mod.rs

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Greptile Summary

Maintenance-only PR that clears two nightly clippy lints (clippy::question_mark and the nightly-only fetch_update deprecation) without altering runtime behavior.

• source.rs: The trailing exec: if-else arm is rewritten using the ? operator; the short-circuit None path is identical to the previous else { return None }.
• progress/mod.rs: A scoped #[allow(deprecated)] with a clear MSRV comment is added around fetch_update. Switching to try_update (stable since 1.95) is correctly deferred because the project MSRV is 1.93.

Confidence Score: 5/5

Safe to merge — both changes are purely mechanical and preserve existing runtime behavior exactly.

The source.rs refactor is a direct semantic equivalent: the ? on strip_prefix("exec:") returns None from the function under the same condition as the old else { return None } branch. The progress/mod.rs change adds only a lint suppression attribute with a well-documented rationale and a clear migration path once the MSRV is bumped. No logic changes, no new error paths.

No files require special attention.

Important Files Changed

Filename	Overview
crates/aube-lockfile/src/source.rs	Refactored trailing exec: arm of if-else chain to use ? operator — behavior is identical, clippy::question_mark lint satisfied
crates/aube/src/progress/mod.rs	Added scoped #[allow(deprecated)] with explanatory comment to suppress nightly-only fetch_update deprecation until MSRV clears 1.95

_{Reviews (1): Last reviewed commit: "chore: satisfy nightly clippy (question_..." | Re-trigger Greptile}