This is an archive of the discontinued LLVM Phabricator instance.

[-Wunsafe-buffer-usage] Filter out conflicting fix-its
ClosedPublic

Authored by ziqingluo-90 on Jan 9 2023, 5:37 PM.

Details

Summary

Two fix-its conflict if they have overlapping source ranges. We shall not emit conflicting fix-its.
This patch adds a class to find all conflicting fix-its (as well as their associated gadgets or declarations).

Diff Detail

Event Timeline

ziqingluo-90 created this revision.Jan 9 2023, 5:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 9 2023, 5:37 PM
Herald added a subscriber: mgrang. · View Herald Transcript
ziqingluo-90 requested review of this revision.Jan 9 2023, 5:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 9 2023, 5:38 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
ziqingluo-90 retitled this revision from [-Wunsafe-buffer-usage] Filter out conflicting fix-its to [WIP][-Wunsafe-buffer-usage] Filter out conflicting fix-its.Jan 9 2023, 5:38 PM
NoQ added a comment.Jan 10 2023, 5:43 PM

Looks awesome!

I'm worried that the test is going to rapidly become stale as you develop fixits for DeclStmt further. It might make sense to write some unittests for this class directly, to put into clang/unittest/Analysis/.... Then you can create some fixits defined by hand, without invoking UnsafeBufferUsage analysis, and feed them to this class directly and verify the results.

Also let's explain motivation a bit more. Normally compiler warnings don't need such machine because the fixits they come with are very simple and hand-crafted. However, unsafe buffer usage analysis is a large emergent behavior machine that may fix different parts of user code, and different parts of the machine that can produce parts of such fixits aren't necessarily aware of each other. In some cases no progress can be made without making sure these parts of the machine talk to each other. However, every time the machine does emit individual fixits, they're actually correct; conflicts between such fixits are entirely a representation problem (we're unable to present overlapping fixits to the user because this requires us to resolve the merge conflict), not an underlying correctness problem. So @ziqingluo-90 is implementing a bailout for the situation when the fixits were perfectly correct in isolation but can't be properly displayed to the user due to merge conflicts between them. This makes it possible for such "merge conflicts" detection to be purely SourceRange-based, so it doesn't need to take the details of the underlying AST into account.

clang/lib/Analysis/UnsafeBufferUsage.cpp
488

Result is unused here!

Looks awesome!

I'm worried that the test is going to rapidly become stale as you develop fixits for DeclStmt further. It might make sense to write some unittests for this class directly, to put into clang/unittest/Analysis/.... Then you can create some fixits defined by hand, without invoking UnsafeBufferUsage analysis, and feed them to this class directly and verify the results.

Also let's explain motivation a bit more. Normally compiler warnings don't need such machine because the fixits they come with are very simple and hand-crafted. However, unsafe buffer usage analysis is a large emergent behavior machine that may fix different parts of user code, and different parts of the machine that can produce parts of such fixits aren't necessarily aware of each other. In some cases no progress can be made without making sure these parts of the machine talk to each other. However, every time the machine does emit individual fixits, they're actually correct; conflicts between such fixits are entirely a representation problem (we're unable to present overlapping fixits to the user because this requires us to resolve the merge conflict), not an underlying correctness problem. So @ziqingluo-90 is implementing a bailout for the situation when the fixits were perfectly correct in isolation but can't be properly displayed to the user due to merge conflicts between them. This makes it possible for such "merge conflicts" detection to be purely SourceRange-based, so it doesn't need to take the details of the underlying AST into account.

Thanks for adding the motivation here!

I updated the revision by getting rid of things we don't need for now.
At this point, we just need to tell if there is any conflict in the fix-its generated for one variable (including variable declaration fix-its and variable usage fix-its). If there is any, we do NOT emit any fix-it for that variable.

At some point later, we may want to know the exact conflicting subsets. That will be another patch.

NoQ added a comment.Jan 12 2023, 9:32 PM

Looks awesome!

clang/include/clang/Analysis/Analyses/UnsafeBufferUsage.h
55–58

Maybe we should put it into some namespace, so that it didn't look like it's part of our public interface?

clang/lib/Analysis/UnsafeBufferUsage.cpp
939–940

Nitpicks.

clang/unittests/Analysis/UnsafeBufferUsageTest.cpp
18

Oh my, you constructed it just like that and it worked? This is awesome!

ziqingluo-90 retitled this revision from [WIP][-Wunsafe-buffer-usage] Filter out conflicting fix-its to [-Wunsafe-buffer-usage] Filter out conflicting fix-its.Jan 19 2023, 2:24 PM

Rebase the change

NoQ accepted this revision.Feb 3 2023, 1:45 PM

Looks great!

clang/lib/Analysis/UnsafeBufferUsage.cpp
984
This revision is now accepted and ready to land.Feb 3 2023, 1:45 PM
This revision was landed with ongoing or failed builds.Feb 7 2023, 4:15 PM
This revision was automatically updated to reflect the committed changes.