fix(stdlib): gate Unix-only format_mode behind cfg(unix) — unblocks the nightly Windows build - #684
Conversation
`format_mode` (src/stdlib/filesystem.rs), added in #676 with the file-mode support for issue #666, has both of its call sites inside `#[cfg(unix)]` blocks — Windows has no mode bits to format, so the `#[cfg(not(unix))]` branches return the documented read-only approximation instead. The function itself was not gated, so on Windows it is dead code and `cargo clippy --all-targets --all-features -- -D warnings` fails: error: function `format_mode` is never used --> src\stdlib\filesystem.rs:502:4 = note: `-D dead-code` implied by `-D warnings` That has failed the nightly Windows build on 2026-08-01 and 2026-08-02 (runs 30686979106, 30735206598), skipping the release job both nights, so no nightly artifacts have been published for main @150c8a76. Gating the function with `#[cfg(unix)]` matches the cfg structure of its callers. No behaviour change on either platform. This is the same failure class as #633 (platform-conditional dead code in crates/wflpkg) and the same coverage gap: ci.yml runs clippy on Ubuntu only, so Windows-only lints are caught first by the nightly.
📝 WalkthroughWalkthrough
ChangesFilesystem platform gating
Estimated code review effort: 1 (Trivial) | ~2 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| /// Format a raw permission bit set as the 4-character octal string WFL uses. | ||
| /// | ||
| /// Unix-only: both call sites live behind `#[cfg(unix)]`, because Windows has | ||
| /// no mode bits to format. Without this gate the function is dead code on | ||
| /// Windows and `cargo clippy -- -D warnings` fails the nightly build. | ||
| #[cfg(unix)] |
There was a problem hiding this comment.
🔍 Windows dead-code exposure is not fully eliminated by this fix pattern
The underlying gap called out in the description — clippy runs only on Ubuntu in ci.yml — means any future helper added for the unix branch will reproduce this exact nightly failure. A Windows clippy lane (or a --target x86_64-pc-windows-msvc clippy check) would catch it at review time; worth tracking separately since this is the third recurrence.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Pull request overview
This PR fixes a Windows-only clippy failure by making the Unix-only format_mode helper in the filesystem stdlib compile only on Unix targets, matching its existing #[cfg(unix)]-guarded call sites and unblocking the nightly Windows build.
Changes:
- Add
#[cfg(unix)]toformat_modeso it doesn’t compile as dead code on Windows. - Add an explanatory doc comment clarifying why the function is Unix-only and how it relates to the Windows clippy lane.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@- |
Why
The Nightly Build has failed three nights running (2026-07-31, 08-01, 08-02) and has published no artifacts for
mainsincenightly-2026-07-30.Build WFL for Windowsfailed at step 8,Run clippy, after 75sCheck formatting:Incorrect newline style in src\interpreter\error.rs); formatting has passed since.Create or Update Nightly Releaseneeds:the Windows job, so it has been skipped each night.Root cause
format_modelanded in #676 (file modes for #666). Both of its call sites —native_file_mode(line 571) andnative_set_file_mode(line 624) — sit inside#[cfg(unix)]blocks, because Windows has no mode bits and the#[cfg(not(unix))]branches return the documented read-only approximation instead. The function itself was never gated, so on Windows it compiles to dead code and-D warningsrejects it.parse_modeis not affected — it is called at line 603, above thecfgsplit, so it is live on both platforms.What changed
One attribute, one file:
No behaviour change on either platform. This mirrors the cfg structure of the callers rather than papering over it with
#[allow(dead_code)].Verification
cargo fmt --all -- --check— cleancargo check --lib— cleancargo clippy --lib -- -D warnings— clean (Linux/unix path:format_modeis still live and still used)grep -rn format_mode src/returns exactly the definition plus the two#[cfg(unix)]-guarded call sites, so gating the definition cannot orphan a reference. A cross-target--target x86_64-pc-windows-msvcclippy run was attempted and abandoned — the sandbox ran out of disk building the Windows dependency tree.nightly.ymlis the only lane that runs clippy on Windows. Aworkflow_dispatchagainst this branch was deliberately NOT triggered: thereleasejob has no branch guard, so it would publish anightly-2026-08-02release from a non-mainsha. Merge this, then the next scheduled nightly (or a dispatch frommain) confirms it.cargo clippy --target x86_64-pc-windows-msvcwas also attempted and could not complete in the sandbox:aws-lc-sysv0.42.0 needs a Windows build toolchain its build script cannot find. Stated plainly rather than claimed.Testing policy
Risk class R0: a
cfgattribute with no behavioural surface. Per §"pure CI mechanics" in the testing policy, no manufactured failing test — the existing Windows clippy gate is the failing test, and it is red onmainright now.Standing issue this re-exposes
This is the third instance of KB #625 / #633:
ci.ymlruns clippy on Ubuntu only, so platform-conditional lints reachmainand are caught post-merge by the nightly. A Windows clippy lane inci.ymlwould have failed #676 at review time in ~4 minutes.Posted by the WFL repo warden (automated triage pass).
Summary by CodeRabbit