Bump mordant to 4e08693 - #38374
Conversation
No-Verification-Needed: lint pin and baseline only
|
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 (2)
WalkthroughThe PR updates the pinned Mordant lint-pack revision and modifies the Mordant baseline configuration for ChangesMordant lint update
Possibly related PRs
Suggested reviewers: Merge Risk: ⚪ Minimal · up to This PR updates the Mordant revision and matching baseline, with the relevant lint command reported clean. No actionable merge-blocking risk remains beyond normal confirmation of the pinned dependency and baseline. 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
Comment |
There was a problem hiding this comment.
LGTM — routine lint-pack pin bump with a regenerated baseline; no runtime code touched.
What was reviewed:
- The rev bump follows the documented process in Cargo.toml ("bumping the rev is a PR of its own, where whatever the new revision finds gets fixed or added to mordant-baseline.toml").
- Removed
stored_projection:ParseTask.rsentry matches the upstream lint refinement described in the PR body. - New
asymmetric_guard:h2_frame_parser.rsentry: checked the flagged site (thefree_resourcescall insideflush_queuefrom #38044) — thecan_send_data()guard there gates whether flushing proceeds, not whether freeing on the CLOSED transition is safe, so baselining rather than changing code is the right call.
Extended reasoning...
Overview
This PR bumps the pinned revision of the mordant dylint lint pack in Cargo.toml and regenerates mordant-baseline.toml accordingly. Two baseline changes: one entry removed (stored_projection on ParseTask.rs, obsoleted by an upstream lint fix) and one added (asymmetric_guard on h2_frame_parser.rs, a new hit from code landed in #38044). No source files are touched.
Security risks
None. The mordant lint pack is a dev-time static analysis tool run in an advisory CI lane (.github/workflows/mordant.yml); it does not affect the compiled binary. The baseline file is a suppression list read only by that CI job.
Level of scrutiny
Low. This is a version-pin bump plus a mechanical regeneration of a lint suppression file, exactly matching the process documented inline in Cargo.toml. The only judgment call — whether the new asymmetric_guard hit should be fixed or baselined — is explained in the PR description, and I spot-checked the flagged code: flush_queue's can_send_data() early-return guards whether there is data to flush, while the free_resources call fires on the HALF_CLOSED_REMOTE→CLOSED transition after END_STREAM is written. Other free_resources call sites (abort, RST, end-of-stream, finalize) are correctly unguarded by can_send_data, so the asymmetry the lint flags is intentional.
Other factors
The PR description states bun run rust:mordant is clean with the new pin and baseline. The change is self-contained, reversible, and has zero effect on shipped code or existing tests.
Picks up scarletindustries/mordant#8: asymmetric_guard no longer claims calls that sit under their own conditions. The h2_frame_parser entry from #38374 goes away and nothing else changes. bun run rust:mordant is clean.
Picks up scarletindustries/mordant#7 (a field that is also assigned is not a stored projection), which removes the ParseTask entry from the baseline.
Regenerating the baseline also added one entry that has nothing to do with the bump: asymmetric_guard on the free_resources call #38044 added in h2_frame_parser.rs. Looked at it; freeing the stream on the transition to CLOSED is right whatever can_send_data reads, so it is baselined rather than changed. First time that lint has fired here, so keeping an eye on whether it earns its place.
bun run rust:mordant is clean with the new pin and baseline.