[all-commits] [llvm/llvm-project] dfde6a: [clang-tidy] Fix redundant-branch-condition false ...

[Mamadou Wane via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: dfde6ac69e6e0c5a717042de3fa7f118eea7d830
      https://github.com/llvm/llvm-project/commit/dfde6ac69e6e0c5a717042de3fa7f118eea7d830
  Author: Mamadou Wane <mamadouswane at gmail.com>
  Date:   2026-09-27 (Sun, 27 Sep 2026)

  Changed paths:
    M clang-tools-extra/clang-tidy/bugprone/RedundantBranchConditionCheck.cpp
    M clang-tools-extra/docs/ReleaseNotes.md
    M clang-tools-extra/test/clang-tidy/checkers/bugprone/redundant-branch-condition.cpp

  Log Message:
  -----------
  [clang-tidy] Fix redundant-branch-condition false positive in loops (#225827)

Fixes #205685.

`bugprone-redundant-branch-condition` decides whether the condition
variable changes between the outer and inner `if` by comparing source
positions. When a loop sits between the two, a mutation that comes after
the inner `if` in the source still runs before the inner condition is
evaluated again on the next iteration, so the check reports a redundant
condition that isn't, and the fix-it changes behavior.

The fix walks the parents of the inner `if` up to the outer `if` and
finds the outermost enclosing loop. If the variable is mutated anywhere
in that loop, the check does not warn. This follows NagyDonat's
suggestion in the issue: the existing check already covers mutations
between the outer condition and the loop, so only the loop itself needs
the extra query. The walk passes through declarations, so an inner `if`
inside a lambda stored in a variable is handled too, and it stops at the
enclosing function. I chose a syntactic walk instead of the CFG
(`utils::ExprSequence`), since it covers the range the issue asks for
without building a CFG on every match.

Tests cover `for`, `while`, `do`, and range-based `for`, a mutation in a
`do`/`while` condition, a lambda stored in a variable inside the loop,
and an inner loop whose enclosing loop does the mutation. Each of these
warns without the patch. Three positive cases confirm the warning is
kept when the loop never mutates the variable, when the mutation comes
after the loop, and when the loop encloses both `if` statements.

Limitations:
- Any mutation in the loop suppresses the warning, including one
followed by an exit from the loop (`break`, `return`, `throw`) or one
that cannot make the condition false. The inner condition is still
redundant in those cases; telling them apart needs the CFG. I added the
`break` case under Unhandled Cases. The change only removes warnings, so
it adds no new false positives.
- Loops built with `goto` and Objective-C `for ... in` loops are not
recognized, so the false positive remains there.

I used Claude to help write the code. I tested and reviewed all of it
myself, and worked through the approach and suggestions with Claude.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications