ci: bump mordant to d0dca00 - #43805
Conversation
From this revision the driver sets `--cfg mordant` and no longer sets `--cfg dylint_lib="mordant"`. Nothing in this repository names either cfg, so only the pin moves. Over the same tree the new revision prints the same 485 findings as a1effd3, all lints compared line by line. The regenerated baseline drops one stale entry that has nothing to do with the new revision: `ContextId::raw` in src/event_loop/ConcurrentTask.rs has a caller now (src/jsc/VirtualMachine.rs), so it is no longer an unused_pub finding.
|
Status: ready for review.
|
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: oven-sh/bun/.coderabbit.yaml Review profile: ASSERTIVE Plan: Essentials Run ID: 📒 Files selected for processing (2)
💤 Files with no reviewable changes (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 3 remain after this review. WalkthroughThe Mordant lint workflow now uses a new pinned revision. The Mordant baseline removes the ChangesMordant lint maintenance
Suggested reviewers: Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to The lint dependency update is ready to merge with no identified production or CI risk. 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
Comment |
…han once Three associated constants of `bun_sys::Tag` have one key on Linux and macOS and another on Windows, because a `cfg(windows)` impl block shifts the impl index. `cargo mordant` drops a duplicate finding only when it sits next to its twin, so it reports each of the three items two or three times, depending on the order in which cargo finishes the targets. The count for src/sys/lib.rs is 65 or 68 over the same tree, and the job failed when it came out as 68. Record 68 until the pinned mordant matches findings by position.
…d more than once" This reverts commit 2f40497.
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.
Beyond the inline finding on the bun_sys count, I also checked the dropped [bun_event_loop] baseline entry: ContextId::raw (src/event_loop/ConcurrentTask.rs:179) now has a caller at src/jsc/VirtualMachine.rs:1300, so removing it does not hide a finding. I could not confirm from this checkout that mordant's rust-toolchain at d0dca00 is still nightly-2026-09-01, which the workflow comment requires to be kept in sync with MORDANT_REV.
Extended reasoning...
The diff is CI-only: it bumps the pinned mordant revision in .github/workflows/rust-lints.yml and edits two entries in mordant-baseline.toml (one removed, one raised from 65 to 68). No runtime source or security-sensitive surface is touched. The removed entry is backed by a real caller in the tree; the raised count is covered by the inline finding, and the toolchain-sync claim could not be verified locally.
There was a problem hiding this comment.
LGTM — the hand-edited 68 count from my earlier comment is gone with the revert, and what remains is a plain tool-pin bump plus a baseline regeneration.
What was reviewed:
- The dropped
unused_pub:src/event_loop/ConcurrentTask.rsentry:ContextId::rawhas a caller atsrc/jsc/VirtualMachine.rs:1300, so the finding is genuinely gone; the baseline only shrinks, which cannot loosen the ratchet. MORDANT_REVchange flows into themordant-bin-<os>-<toolchain>-<rev>cache key, so no stale binary can be restored. I could not fetch mordant'srust-toolchainat d0dca00 from here, so the unchangedMORDANT_TOOLCHAINpin rests on the PR's claim — a mismatch would surface as a visiblecargo installfailure on the advisory job, not a silent pass.- No CODEOWNERS entry covers either file; the reverted middle commit leaves no residue in the tree.
Extended reasoning...
The net diff is two CI-only lines: the pinned mordant commit in .github/workflows/rust-lints.yml and the removal of one stale [bun_event_loop] baseline entry in mordant-baseline.toml; no Rust source, scripts, or mordant.toml change. It touches no security-sensitive surface. The earlier inline finding (hand-raising src/sys/lib.rs to 68) was addressed by the revert commit, the removed baseline entry is backed by a real caller in src/jsc/VirtualMachine.rs, and the mordant job is continue-on-error so a wrong toolchain pin would fail loudly without blocking merges. The remaining 65-vs-68 nondeterminism is pre-existing in mordant, documented in the PR, and unchanged by this diff.
…43810) ### Problem - The `mordant` job passes or fails at random at the pinned `d0dca00`. `cargo mordant` reports three associated constants of `bun_sys::Tag` two or three times each, so the `unused_pub` count for `src/sys/lib.rs` is 65 or 68 over the same code. The baseline records 65, and the first run on #43805 counted 68. - The cause is in mordant. It identified an item by a key that contains the index of its impl block. A `cfg(windows)` impl block shifts that index on Windows only, and mordant dropped a duplicate finding only when it sat next to its twin. The order of the three targets' records is the order in which cargo finishes them. ### Fix - `MORDANT_REV` moves to `00778d35391dc1a75381008754fd40726c1682f0` (scarletindustries/mordant#29). It matches and reports an item by its position: crate, file, offset of the name. `MORDANT_TOOLCHAIN` stays `nightly-2026-09-01`. - `mordant-baseline.toml` is regenerated and only goes down: `src/sys/lib.rs` 65 to 56, and the entries for `src/io/lib.rs` (1) and `src/spawn_sys/spawn_process.rs` (5) are gone. - Verified: `bun scripts/rust-mordant.ts` is clean from an empty `target/mordant`, and clean again on a warm run. The `mordant` check on this PR is the CI proof. ### Background - The job checks three targets in one run, so each `pub` item is recorded up to three times. `cargo mordant` decides `unused_pub` after the build, from all of those records. - The baseline holds a count per lint and file. A run fails when a count goes over. <details><summary>Notes</summary> What changes in the findings, measured over this tree with no baseline: - 18 items are no longer reported. Each has a use under one target, and the other targets' records of the same item had a different key, so the use did not count for them. Examples: `Tag::epoll_ctl` (Linux), `Tag::uv_spawn` (Windows), `FilePollRef::set_flag`, `ExtraPipe::fd`. - The three `Tag` constants that were reported two or three times are reported once. - Six more reports appear, all in `src/sys/lib.rs`, for items that share a name under different `cfg`s, such as `O::NOATIME`, which is defined at three places. Each is a separate unused item. The old key was the same for all of them, so they were merged into one finding. - In total 188 reports become 173. </details> <!-- robobun:evidence:begin --> --- **no test proof** · iteration 0 · no src or test change; test-proof not applicable <!-- robobun:evidence:end -->
2 participants
Problem
mordantjob pinsa1effd3. rename the cfg to mordant scarletindustries/mordant#28 renames the cfg that the driver sets while it lints:--cfg mordantnow,--cfg dylint_lib="mordant"before.mordant-baseline.tomlholds one entry with no finding behind it:unused_pub:src/event_loop/ConcurrentTask.rs.Fix
MORDANT_REVmoves tod0dca0026f0662a94e929a8a697d711be5eafd9b.MORDANT_TOOLCHAINstaysnightly-2026-09-01. Nothing in this repository namesdylint_liborcfg(mordant), so no source file changes.ContextId::raw, whichsrc/jsc/VirtualMachine.rscalls since event loop: remove ManagedTask; each callback is its own task type #43675.a1effd3andd0dca00print the same 485 findings over the same tree (all lints, line by line). A cold run of the job's steps is clean locally.Background
#[cfg_attr(mordant, allow(..))]. That is what the renamed cfg is for. This workspace does not use it, and--cfg mordantraises nounexpected_cfgswarning.Notes
The
mordantcheck can fail on this PR, and on any other, for a reason that is not in the diff.cargo mordantreports three associated constants ofbun_sys::Tag(WriteFile,SetEndOfFile,fchownat) two or three times each. Theunused_pubcount forsrc/sys/lib.rsis 65 or 68 over the same tree, and the baseline records 65. The first run here counted 68.The cause is in mordant. The definition path that identifies an item contains the index of its impl block. That index is
{impl#9}on Linux and macOS and{impl#10}on Windows, because acfg(windows)impl block sits above.cargo mordantsorts the findings of the three targets by position and drops a duplicate only when it is next to its twin. The order of equal positions is the order in which cargo finishes the targets, so the two equal keys are adjacent on some runs and not on others.A commit on this branch recorded 68 by hand and was reverted: the baseline comes from a regeneration only. The fix is a mordant change that matches and deduplicates findings by position, and a later bump picks it up.
no test proof · iteration 0 · no src or test change; test-proof not applicable