This is an archive of the discontinued LLVM Phabricator instance.

[-Wunsafe-buffer-usage] Refactor to let local variable fix-its and parameter fix-its share common code
ClosedPublic

Authored by ziqingluo-90 on Jul 24 2023, 5:21 PM.

Details

Summary

Refactor the code for local variable fix-its so that it reuses the code for parameter fix-its, which is in general better. For example, cv-qualifiers are supported.

Diff Detail

Event Timeline

ziqingluo-90 created this revision.Jul 24 2023, 5:21 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 24 2023, 5:21 PM
ziqingluo-90 requested review of this revision.Jul 24 2023, 5:21 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 24 2023, 5:21 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
ziqingluo-90 added inline comments.Jul 24 2023, 5:32 PM
clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-local-var-span.cpp
242

We no longer generate fix-its for a variable declaration where the type specifier is just auto. This is to avoid that fix-its may become incorrect when the adopting codebase changes. For example,

int x;
auto p = &x;

If we fix the declaration of p to std::span<int> p{&x, 1}, and later int x is changed to long x, the program becomes incorrect and the programmer may not know that the type of p should simply follow the type of x.

t-rasmud added inline comments.Jul 25 2023, 1:09 PM
clang/lib/Analysis/UnsafeBufferUsage.cpp
1860

When will this condition be satisfied? I just want to understand if there are code examples where there is no identifier text or is it that getVarDeclIdentifierText fails.

ziqingluo-90 added inline comments.Jul 25 2023, 3:11 PM
clang/lib/Analysis/UnsafeBufferUsage.cpp
1860

!IdentText if getVarDeclIdentifierText fails.

getVarDeclIdentifierText assumes that the identifier text is a single token. It starts with the begin location of the identifier and tries to obtain the end location via Lexer::getLocForEndOfToken.
So it could fail if 1) the identifier text is not a single token or 2) any unexpected failure happens in obtaining valid source locations.

Case 2) could be rare I think since I don't know when it could happen. We just need to assume that it is NOT always successful in manipulating source locations.

For case 1), I originally thought that if the identifier is expanded from a macro with parameters, e.g.,

#define MACRO(x)  name
int * MACRO(x);

, MACRO(x) is not a single token. But it seems I was wrong---it is one token to the Lexer. See my test at warn-unsafe-buffer-usage-fixits-local-var-span.cpp:186--206.

In conclusion, getVarDeclIdentifierText could fail but it should be rare.

ziqingluo-90 marked an inline comment as done.Jul 25 2023, 3:11 PM
t-rasmud accepted this revision.Aug 10 2023, 11:32 AM
This revision is now accepted and ready to land.Aug 10 2023, 11:32 AM
NoQ accepted this revision.Aug 17 2023, 4:08 PM

LGTM! I have minor suggestions for comments.

clang/lib/Analysis/UnsafeBufferUsage.cpp
1829–1833
1861

Should we start adding debug notes to all these early-returns? Or are they already covered by a catch-all debug note down the line?

clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-local-var-span.cpp
20–23
42–45
This revision was landed with ongoing or failed builds.Aug 21 2023, 2:50 PM
This revision was automatically updated to reflect the committed changes.
ziqingluo-90 marked 4 inline comments as done.

Addressed comments and have landed this patch.