This is an archive of the discontinued LLVM Phabricator instance.

[NFC] Fix unnecessary copy with auto.
AbandonedPublic

Authored by srividya-sundaram on Aug 4 2023, 12:13 PM.

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald Transcript
srividya-sundaram requested review of this revision.Aug 4 2023, 12:13 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 4 2023, 12:13 PM
steakhal requested changes to this revision.Aug 4 2023, 12:31 PM

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.

This revision now requires changes to proceed.Aug 4 2023, 12:31 PM

Added 'const' type qualifiers per review comments.

steakhal requested changes to this revision.Aug 7 2023, 1:16 AM

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.
Taking by ref would definitely not help the situation.

clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp
2621

8 + 16 bytes. Basically 3 pointers.

clang/lib/StaticAnalyzer/Checkers/LocalizationChecker.cpp
851–852

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.
But we should still prefer const ref over 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 don't think we would benefit from taking this by ref - even though in total it's around 48 bytes.

This revision now requires changes to proceed.Aug 7 2023, 1:16 AM
tahonermann requested changes to this revision.Aug 8 2023, 9:16 AM

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.

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.

Thank you, @steakhal for the detailed feedback.
Based on your comments, and after discussing with @tahonermann, I am abandoning this patch.

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.