At least LibreOffice has, for mainly historic reasons that would be hard to change now, a class Any with an overloaded operator >>= that semantically does not assign to the LHS but rather extracts into the (by-reference) RHS. Which thus caused false positive -Wunused-but-set-parameter and -Wunused-but-set-variable after those have been introduced recently.
This change is more conservative about the assumed semantics of overloaded operators, excluding compound assignment operators but keeping plain operator = ones. At least for LibreOffice, that strikes a good balance of not producing false positives but still finding lots of true ones.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
For reasons that I never looked into, GCC never warned for any of these cases. The Clang implementation appears to be way more aggressive (in a positive sense) to begin with.
clang/lib/Sema/SemaExprCXX.cpp | ||
---|---|---|
7811–7816 | Would you mind elaborating on the need for this code? IIUC, you're concerned about overloaded operators, but won't such operators always be covered by the CXXOperatorCallExpr case below? |
clang/lib/Sema/SemaExprCXX.cpp | ||
---|---|---|
7811–7816 | That's what I would initially have thought too (see my unanswered https://lists.llvm.org/pipermail/llvm-dev/2021-June/150875.html "[llvm-dev] BinaryOperator vs. CXXOperatorCallExpr in template code"; but which, I notice now, I accidentally sent to llvm-dev rather than cfe-dev). But e.g. the template f4 test code in warn-unused-but-set-variables-cpp.cpp turns the += into a BinaryOperator. |
Would you mind elaborating on the need for this code? IIUC, you're concerned about overloaded operators, but won't such operators always be covered by the CXXOperatorCallExpr case below?