Fix #15021 FN redundantInitialization with structured binding

[chrchr-github]

Best viewed with whitespace changes hidden.

[danmar]

This is an AI review. Take it with a grain of salt and feel free to reject it by resolving the comment.

Looks good to me. I built it and checked that reference bindings don't produce false positives: auto& [x, y] = s; x = 1;, auto&& [x, y] = std::move(s);, for (auto& [k, v] : m) v = 0; and auto& [x, y] = arr; all stay silent. auto [x, y] = p; with a std::pair is reported.

Question: the ticket and the PR title say "FN redundantInitialization", but since isInitialization is only set for split ; %var% = declarations, the structured binding is reported as redundantAssignment ("is reassigned a value before the old one has been used", with notes "x is assigned" / "x is overwritten"). Semantically auto [x, y] = s; is an initialization. Should isInitialization be set for the structured binding case so that redundantInitialization is reported, including the existing "trivial rhs" handling? If redundantAssignment is intended, maybe adjust the title so the history matches.

[dmcppcheck]

Test results for commit 7ae3dd4 (tools/test-my-pr.py, main compared to this PR):

Test: http://ec2-16-170-140-253.eu-north-1.compute.amazonaws.com/pr-8847/
packages: 100
Differing warnings: 0 (+0 -0)
Timing: -0.0% (http://ec2-16-170-140-253.eu-north-1.compute.amazonaws.com/pr-8847/2026-09-30_08-54-05-7ae3dd410277_timing.html)

_{Posted automatically by the cppcheck PR test runner. +N: warnings only with this PR, -N: warnings only with main. The AI review is written by Claude and can be wrong.}

[danmar]

I didn't read the AI review carefully.. if you feel we can ignore that then feel free to merge this.

[dmcppcheck]

This pull request has merge conflicts that must be resolved.

[dmcppcheck]

@claude review

[claude]

Possible FP with reference bindings: the isReference() bailout above (// todo: check references) runs on tok->astOperand1(), which is the [ token here and has no variable. So it never applies to the bound names. With auto& [x, y] = s; x = 1;, x is an alias for s.a and the write is observable, so it isn't redundant. The same applies to tuple-like types whose elements are references (e.g. auto [a, b] = std::tie(i, j);).

I'd suggest skipping elements whose variable()->isReference() is true (or bailing out when the declaration is auto&/auto&&), and adding a negative test for auto& [x, y] = s; x = 1; y = 2;.

[claude]

Now that this runs inside the loop, there are two problems for structured bindings:

• diag(tok) inserts tok the first time, so only the first bound element can ever get this diagnostic.
• The message still uses tok->astOperand1()->expressionString(), which would print [x,y] instead of the element name. It should use exprTok/tokenToCheck, like the other diagnostics below.

[claude]

Review summary:

• Possible FP: reference bindings (auto& [x, y] = s; x = 1;) aren't excluded. The existing isReference() bailout checks the [ token, not the bound variables. A negative test for this would help.
• Same-value diagnostic in the loop: diag(tok) limits it to the first bound element, and the message uses [x,y] instead of the element name.
• Title vs. test: the title says redundantInitialization, but the new test only expects redundantAssignment. Is that intended?

I couldn't build locally, so these come from reading the code.

🤖 Generated with Claude Code