Summary
linux-rs's scripts/run_c2rust_baseline.py (this project's baseline-triage harness, not this repo) added a turnaround-time optimization: skip files whose per-declaration translated status has been unchanged across the last 3 c2rust revisions, on the theory that most of the 542-file corpus isn't touched by any given fix.
This works correctly for reliability fixes (crash/dropped_decls fixes) — those by definition flip a declaration's translated status for the files they actually change.
It does not work for idiom-rule changes (WARN_ON/fls-family/swap-mem-swap/future rules gated behind --enable-rule). An idiom rule changes what Rust gets emitted inside a declaration that was already succeeding (or already failing for an unrelated reason) — it never flips whether that declaration transpiles at all. Confirmed directly: drivers/base/class.c registered as "stable" immediately after the WARN_ON fix that changed its actual emitted output, because every declaration in the file kept the same pass/fail status throughout.
Impact
None on this repo directly — this is a linux-rs-side harness limitation, not a c2rust bug. Filed here (rather than only as a code comment) so it's tracked as a known gap in the verification methodology, in case a future idiom-rule change needs a real per-declaration content diff (not just pass/fail) to be caught by routine runs rather than requiring an explicit full sweep every time.
Current mitigation
linux-rs always passes --include-stable (full corpus sweep, bypassing the exclusion) when verifying an idiom-rule change specifically, and only relies on the default stability-filtered routine run for reliability work. This is a manual discipline, not an automated guarantee — documented in run_c2rust_baseline.py's stable_files() docstring and its --include-stable CLI help text.
Possible future fix
A real content-level stability signal (e.g. a hash of each declaration's emitted Rust text, not just its translated boolean) would close this gap properly — out of scope for now.
Summary
linux-rs's
scripts/run_c2rust_baseline.py(this project's baseline-triage harness, not this repo) added a turnaround-time optimization: skip files whose per-declarationtranslatedstatus has been unchanged across the last 3 c2rust revisions, on the theory that most of the 542-file corpus isn't touched by any given fix.This works correctly for reliability fixes (crash/dropped_decls fixes) — those by definition flip a declaration's
translatedstatus for the files they actually change.It does not work for idiom-rule changes (
WARN_ON/fls-family/swap-mem-swap/future rules gated behind--enable-rule). An idiom rule changes what Rust gets emitted inside a declaration that was already succeeding (or already failing for an unrelated reason) — it never flips whether that declaration transpiles at all. Confirmed directly:drivers/base/class.cregistered as "stable" immediately after theWARN_ONfix that changed its actual emitted output, because every declaration in the file kept the same pass/fail status throughout.Impact
None on this repo directly — this is a linux-rs-side harness limitation, not a c2rust bug. Filed here (rather than only as a code comment) so it's tracked as a known gap in the verification methodology, in case a future idiom-rule change needs a real per-declaration content diff (not just pass/fail) to be caught by routine runs rather than requiring an explicit full sweep every time.
Current mitigation
linux-rs always passes
--include-stable(full corpus sweep, bypassing the exclusion) when verifying an idiom-rule change specifically, and only relies on the default stability-filtered routine run for reliability work. This is a manual discipline, not an automated guarantee — documented inrun_c2rust_baseline.py'sstable_files()docstring and its--include-stableCLI help text.Possible future fix
A real content-level stability signal (e.g. a hash of each declaration's emitted Rust text, not just its translated boolean) would close this gap properly — out of scope for now.