feat(lint): add enumerable loop removal

[0xMars42]

This adds the remaining High-severity enumerable-loop-removal lint from #14381. It reports a semantically resolved EnumerableSet.remove when the same storage set is read with at at a bare ascending cadence and the loop body matches the conservative flow-free shape: the cadence has no unsupported writes and the body has no branches, jumps, reverts, inline assembly, try, or nested loops. Both method and library-qualified calls are recognized, while storage aliases, struct fields, literal mapping keys, and unknown operands are handled conservatively.

Review feedback tightened cadence invalidation across declarations, tuple assignments, resets, decrements, and deletes; restricted at to the bare cadence identifier; excluded every unmodeled exit shape; and documented descending, control-flow, expression-arm, and remove-argument precision limits. Permanent positive and negative fixtures cover each corrected case.

The user documentation is in foundry-rs/book#1987, with the review-aligned follow-up in foundry-rs/book#1992.

Prepared with assistance from OpenAI Codex.

[mattsse]

No actionable findings from my pass.

[0xMars42]

Thanks for the thorough passes. Each round I added a layer (cadence direction, copy propagation, an exit-and-branch exemption) to keep a report while dodging the last false positive, and each layer grew the next false negative you then found. Rather than add a fourth, I reworked the detector around a single rule it can judge without a flow analysis, pushed in 9db3decca.

Reported now: an unconditional ascending cadence (i++, i += 1, i = i + 1), an at read at that cadence, a remove on the same set, and a straight-line body (no if, try, break, continue, return, or nested loop). The type-checker call resolution and the storage-path set identity from the earlier rounds are kept. The synthetic condition guard the lowering wraps every loop in is peeled so its break and the for's next-step read for what they are.

This drops every false positive you raised, by construction:

• swap-and-pop filter (i++ only in the no-removal branch): the cadence is under a branch, so it is not an unconditional ascending cadence.
• short-circuit exit (remove(t) && flag then break) and negated exit (!remove(v) then break): the body has a break.
• no-op step (i += 0): not a positive step, so no ascending cadence.
• killed copy (idx = i reassigned before the read): copy propagation is gone; the index must be the cadence variable.
• nested removal then outer exit: a nested loop is not straight-line.

The false negatives you flagged become documented limitations, in the docs and the fixture: the descending drain of a different value, an eventual exit reading a shifted slot, composite index arithmetic, and a member/opaque cursor are all cases where telling the corruption from a safe lookalike needs the flow analysis this pass does not run, so it stays silent instead of guessing. The canonical ascending remove-as-you-go is still reported.

This is the conservative-but-precise version on the control-flow axis: it never warns on the safe swap-and-pop and drain-and-exit forms it can read from the loop's structure, and in exchange it misses the corruptions that hide behind control flow. It can still over-report on the set-identity axis, unchanged from the earlier rounds: an operand it cannot read statically (a varying mapping key, a conditionally-rebound alias) is matched against every set, reporting a possibly-safe removal rather than missing an unsafe one.

If you would rather have the control-flow corruptions caught and accept the flow analysis it takes (reaching definitions for the cadence, correlating the mutating path with the exiting branch, polarity, short-circuit), I am happy to build that out instead. Your call on which trade you want.