Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I can only vouch for the SttaticAnalyzer portion.
Those parts makes sense to me.
However, I've seen cases where it doesn't resonate.
As a rule of thumb, if we are "copying" only at most 3 pointers, I'd rather still just make a copy instead of by reference.
Please check if your recommended changes reflect this.
If you decide to take it by reference, prefer taking it also by const.
Let me know if you oppose.
I went over the patch and I found only a single debatable case for taking by reference.
To clarify why I would prefer taking by value: value semantics is good for local reasoning; thus improves maintainability. We should only deviate from that when there is actual benefit for doing so.
Static analysis tools, such as Coverity, have false-positives. Some rules are better than others.
As a static analysis tool developer myself, I'd recommend carefully evaluating the findings before taking action for resolving them.
And if you find anything interesting, tool vendors are generally happy to receive feedback about their tool. I guess, they should as well understand that taking a pointer by reference doesn't improve anything.
clang/include/clang/Analysis/FlowSensitive/StorageLocation.h | ||
---|---|---|
129 | This is only 2 pointers. I'd rather take them by value. | |
clang/lib/AST/Interp/ByteCodeEmitter.cpp | ||
64 | Only 2 pointers. | |
clang/lib/AST/RecordLayoutBuilder.cpp | ||
3728 | It's 24 bytes, which is like 3 pointers. | |
clang/lib/Analysis/FlowSensitive/RecordOps.cpp | ||
38 | 2 pointers. | |
86 | 2 pointers. | |
clang/lib/Sema/SemaRISCVVectorLookup.cpp | ||
305 | It's just a single long. 8 bytes. | |
clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp | ||
2621 | 8 + 16 bytes. Basically 3 pointers. | |
clang/lib/StaticAnalyzer/Checkers/LocalizationChecker.cpp | ||
851–853 | size_t and a pointer. 16 bytes in total. | |
clang/lib/StaticAnalyzer/Checkers/MacOSKeychainAPIChecker.cpp | ||
534 | 8 + 16 bytes. | |
clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp | ||
2821 | 8 + 16 bytes. | |
3081 | 8 + 16 bytes. | |
3558 | 8 + 16 bytes. | |
clang/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp | ||
945 | 16 + 24 bytes. Okay, this is basically the first case where it actually makes sense to take by ref. | |
1373 | 8 + 16 bytes. | |
clang/lib/StaticAnalyzer/Checkers/ObjCSelfInitChecker.cpp | ||
365 | 8 + 4 bytes. | |
clang/lib/StaticAnalyzer/Checkers/ObjCUnusedIVarsChecker.cpp | ||
154 | 8 + 4 bytes. | |
clang/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountChecker.cpp | ||
169 | 16 bytes. | |
clang/lib/StaticAnalyzer/Checkers/SimpleStreamChecker.cpp | ||
166 | 8 + 4 bytes. | |
clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp | ||
1196–1198 | Here we are talking about some generator of some pointers and indexes. |
I agree with the analysis done by @steakhal. The static analyzer being used (which I'm not allowed to name) is being too noisy in these cases; it complains about every case where an object of class type is copied regardless of size. An issue has been reported to the static analysis vendor about this. These complaints from the static analyzer will need to be moderated until the vendor satisfactorily addresses the reported issue.
Thank you, @steakhal for the detailed feedback.
Based on your comments, and after discussing with @tahonermann, I am abandoning this patch.
Btw, it helps reviewers if you explicitly abandon the patch in Phabricator. There's a drop-down menu that says "Add Action..." and you can choose to abandon the review from there.
I did spend a good amount of time trying to figure out how to abandon this review and gave up eventually.
Even after your comment, I had to search a bit for the "Add Action.." drop down. Clearly, I'm UI challenged.
This is only 2 pointers. I'd rather take them by value.