Fix clippy needless_late_init in txt_helpers - #2332
Conversation
Master fails `cargo clippy -- -D warnings` on lib_ccxr, so format_rust is red on every open pull request regardless of what it changes. Authors have been fixing it inside unrelated PRs to get their CI green, which couples a one-line lint fix to whatever else they are working on. Assign c_len from an if-expression instead of declaring it and filling it in on each branch. Behaviour is identical.
CCExtractor CI platform finished running the test files on linux. 171/237 tests matched the approved output:
66 tests do not match the approved output. That is the pass/fail verdict. Whether this branch caused it is a separate question, answered below.
Compared with the tip of master — test 9514, commit 982586e:
Compared with the commit this branch was cut from: the same run as the tip of master (test 9514), so the comparison above already covers it. No test changes behaviour relative to the tip of master: every failure above fails there too, byte for byte. The approved output for those tests is out of date, which is a baseline to review rather than a regression in this branch. |
CCExtractor CI platform finished running the test files on windows. 171/237 tests matched the approved output:
66 tests do not match the approved output. That is the pass/fail verdict. Whether this branch caused it is a separate question, answered below.
Compared with the tip of master — test 9515, commit 982586e:
Compared with the commit this branch was cut from: the same run as the tip of master (test 9515), so the comparison above already covers it. No test changes behaviour relative to the tip of master: every failure above fails there too, byte for byte. The approved output for those tests is out of date, which is a baseline to review rather than a regression in this branch. |
Why
cargo clippy -- -D warningsfails on master:So
format_rust (./src/rust/lib_ccxr)is red on every open PR regardless of what it changes — #2327, #2329 and #2331 all fail on this line and not on their own code.The side effect is worse than the red tick: authors have been fixing it inside unrelated PRs to get CI green. #2331 carried this exact fix alongside a C string change until it was asked to drop it, at which point its CI went red for a reason that had nothing to do with the PR. That is the wrong shape — a lint fix on shared code should land once, on its own.
What
Assign
c_lenfrom anif-expression rather than declaring it and assigning in every branch. Semantically identical; clippy stops objecting.The added comment records why the final
elseyields 1: a byte matching no UTF-8 lead pattern is consumed singly so the loop always advances. That is the one branch whose value is not obvious from the pattern above it.Testing
cargo clippy -- -D warningsclean on both crates (lib_ccxrandsrc/rust); master fails the firstcargo fmt --checkcleanlib_ccxrtests pass982586e8): 59 samples ×--out=ttxtand--out=srt, 112 outputs byte-identical, 0 differences, 0 exit-code changes (6 produced no output on either side)Once this lands, #2327/#2329/#2331-style PRs go green on their own merits, and the next PR touching Rust does not have to carry someone else's lint fix.