Labels: bug, checks-crate
Crate: checks
Description
crates/checks/src/vec_growth.rs (lines ~69-89) sets has_len_check = true on any .len() method call found anywhere in the method body, with no correlation to the receiver or to whether it actually gates the push/push_back call:
if method == "len" {
self.has_len_check = true;
}
A .len() call on an unrelated collection (e.g. logging other_vec.len()) suppresses the finding even when the actual storage-backed Vec being grown has no cap at all. This is the same "presence, not gating condition" defect class already tracked for unchecked-arithmetic (issue #278), recurring independently in this check.
Acceptance Criteria
Difficulty: intermediate
Labels: bug, checks-crate
Crate: checks
Description
crates/checks/src/vec_growth.rs(lines ~69-89) setshas_len_check = trueon any.len()method call found anywhere in the method body, with no correlation to the receiver or to whether it actually gates thepush/push_backcall:A
.len()call on an unrelated collection (e.g. loggingother_vec.len()) suppresses the finding even when the actual storage-backedVecbeing grown has no cap at all. This is the same "presence, not gating condition" defect class already tracked forunchecked-arithmetic(issue #278), recurring independently in this check.Acceptance Criteria
.len()call to be on the same receiver/variable as the vector being pushed to (or otherwise demonstrably gate the push), not just present anywhere in the function..len()call plus a genuinely unbounded push, asserting a finding is still produced.Difficulty: intermediate