NoQ added inline comments.
================
Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:11786
+ "%select{"
+ "unsafe operation on raw pointer in expression|"
+ "unsafe arithmetic on raw pointer|"
----------------
NoQ wrote:
> malavikasamak wrote:
> > NoQ wrote:
> > > The first mode doesn't show up in any tests and it's probably dead code
> > > at this point.
> > What do you think of specifying the variable name in these warnings? It
> > could be helpful when there are more than one DREs in a statement.
> These warnings are emitted only when we *cannot* identify the variable;
> either because it's not there at all, or we don't know how to find it. If we
> could figure out the variable, we'd be emitting `warn_unsafe_buffer_variable`
> instead. IIRC, in all of the provided test cases the operand isn't a DRE.
>
> That said, I totally agree that it's a great idea to try a few other things
> to point out the specific subexpression, even if we don't connect the warning
> gadget to a variable. Say, we can try to blame `MemberExpr`s or `CallExpr`s
> the same way we blame DREs, and include their name in the warning. I'll try a
> few things real quick and see how bad it gets.
>
> Note that these are also the things for which we may eventually start
> providing constructive solutions. Say, an unsafe operation on `CallExpr` can
> be a reason to autofix the callee to return a `std::span`. So hopefully these
> warnings will eventually be replaced by better warnings in more and more
> cases.
Wait nvm, the whole point of this patch is to warn when variable discovery is
manually turned off! I'm an idiot, this absolutely deserves more effort.
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D146773/new/
https://reviews.llvm.org/D146773
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
