This is an archive of the discontinued LLVM Phabricator instance.

[-Wunsafe-buffer-usage] Fix assertion failure in case of BindingDecl
ClosedPublic

Authored by t-rasmud on Aug 16 2023, 1:28 PM.

Diff Detail

Event Timeline

t-rasmud created this revision.Aug 16 2023, 1:28 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 16 2023, 1:28 PM
t-rasmud requested review of this revision.Aug 16 2023, 1:28 PM
t-rasmud updated this revision to Diff 550864.Aug 16 2023, 1:30 PM
NoQ added a comment.Aug 16 2023, 1:34 PM

The check to(varDecl()) is repeated in every gadget as well as here, now they go even further out of sync. It probably makes sense to make a reusable matcher toSupportedVariable() that covers all cases we want to cover(?)

t-rasmud updated this revision to Diff 550884.Aug 16 2023, 2:07 PM
NoQ added a comment.Aug 16 2023, 2:15 PM

Aha great! Code reuse!!

I'm further trying to sort out this issue once and for all, because we keep running into it, so I have, uhh, further suggestions.

clang/lib/Analysis/UnsafeBufferUsage.cpp
384

Now, I don't think we actually support BindingDecl yet. We don't really know how to emit a fixit for it, and this is very likely to be as hard as struct member fixits, given that it's about decomposing structs into individual members. Maybe we'll have explicit support for std::pair and std::tuple in the future, but we're not there yet.

So we should probably leave it as to(varDecl()) for now. It's still great that we reused it though!

Another thing we can put there, is the check that the variable is *local*. Then we can remove a lot of manual imperative checks for that in all the getFixits() methods.

699–700

I found one more place where these checks are missing.

t-rasmud updated this revision to Diff 551247.Aug 17 2023, 1:33 PM
NoQ added inline comments.Aug 17 2023, 2:37 PM
clang/lib/Analysis/UnsafeBufferUsage.cpp
384

Another thing we can put there, is the check that the variable is *local*. Then we can remove a lot of manual imperative checks for that in all the getFixits() methods.

As is tradition, I appear to be making it up as there aren't any duplicated checks for local variables in getFixits() methods. They're already deduplicated to like 2 places.

It's definitely a good question who's really responsible to performing these checks; it depends on whether we see it as a strategy thing ("fix this variable with span, but as if it's a global variable, so slap an attribute on it and introduce safe accessors - that's a different strategy from changing the type of a local variable to span, and we can technically choose the local strategy for a static global, or a global-like strategy for a local variable, kinda why not"), or as a fixable thing ("I'm a fixable who knows how to fix a use of a local variable with span, there's supposed to be another fixable who knows how to fix a similar use of a global variable with span, and we never talk to each other").

But as Rashmi correctly pointed out offline, it's not really valuable to resolve this question right away, and trying to make fixables responsible for this check will only get in the way of gathering statistics and improving parts that actually matter.

It's really valuable to have every part of the machine agree what a supported variable is, but not every aspect needs to be actually checked by each gadget.

NoQ accepted this revision.Aug 17 2023, 4:17 PM

Oo you already updated it. LGTM then, thanks!!

This revision is now accepted and ready to land.Aug 17 2023, 4:17 PM
This revision was landed with ongoing or failed builds.Aug 17 2023, 4:18 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptAug 17 2023, 4:18 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript