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|"
----------------
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.
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
