This fixes a bug where the performance-unnecessary-value-param check suggests a fix to move the parameter inside of a loop which could be invoked multiple times.
Details
- Reviewers
aaron.ballman alexfh sbenza - Commits
- rG519de4b69205: [clang-tidy] Do not move parameter if only DeclRefExpr occurs inside of a loop
rCTE289912: [clang-tidy] Do not move parameter if only DeclRefExpr occurs inside of a loop
rL289912: [clang-tidy] Do not move parameter if only DeclRefExpr occurs inside of a loop
Diff Detail
Event Timeline
clang-tidy/utils/DeclRefExprUtils.cpp | ||
---|---|---|
127 | Why would this not work? Could you give an example? The way the function is written it handles my the use case for identifying when moving the parameter is not safe, so I could also just move it into the UnnecessaryValueParamCheck. |
clang-tidy/utils/DeclRefExprUtils.cpp | ||
---|---|---|
127 | I was thinking about a case where a loop this matcher finds is outside of the function definition and shouldn't be considered: void F() { for (;;) { struct C { void f(ExpensiveMovableType E) { auto F = E; } }; } } |
clang-tidy/utils/DeclRefExprUtils.cpp | ||
---|---|---|
127 | This case is not an issue in the check as we're passing f's body statement to the hasLoopStmtAncestor function, so the search is scoped to f's body. If you're concerned about the case where someone calls this with F's body but expects it to be scoped to f I can just move this function into the check and make it an implementation detail. |
LG modulo comment.
clang-tidy/utils/DeclRefExprUtils.cpp | ||
---|---|---|
127 | Making it an implementation detail until other potential users appear sounds good. |
How will this work with lambdas / local classes declared inside a loop? Not sure if this case is going to happen in real code, but we'd better be clear about the limitations of the implementation.