- Use Strategy to determine whether to fix a parameter
- Fix the `Strategy` construction so that only variables on the graph
are assigned the `std::span` strategy
Reviewed by: t-rasmud (Rashmi Mudduluru), NoQ (Artem Dergachev)
Differential revision: https://reviews.llvm.org/D157441
For a function `F` whose parameters need to be fixed, we group fix-its
of F's parameters together so that either all of the parameters get
fixed or none of them gets fixed.
Reviewed by: NoQ (Artem Dergachev), t-rasmud (Rashmi Mudduluru), jkorous (Jan Korous)
Differential revision: https://reviews.llvm.org/D153059
We have to give up on fixing a variable declaration if it has
specifiers that are not supported yet. We could support these
specifiers incrementally using the same approach as how we deal with
cv-qualifiers. If a fixing variable declaration has a storage
specifier, instead of trying to find out the source location of the
specifier or to avoid touching it, we add the keyword to a
canonicalized place in the fix-it text that replaces the whole
declaration.
Reviewed by: NoQ (Artem Dergachev), jkorous (Jan Korous)
Differential revision: https://reviews.llvm.org/D156192
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.
Reviewed by: NoQ (Artem Dergachev), t-rasmud (Rashmi Mudduluru)
Differential revision: https://reviews.llvm.org/D156189
This breaks the clang check-format on CI.
+ grep -rnI '[[:blank:]]$' clang/lib clang/include clang/docs
clang/lib/Analysis/UnsafeBufferUsage.cpp:2277:#endif
This reverts commit ac9a76d7487b9af1ace626eb90064194cb12c53d.
Previously an abstract class has no pure virtual function. It causes build error on some bots.
Slightly refactor and optimize the code in preparation for
implementing grouping parameters for a single fix-it.
Reviewed by: NoQ (Artem Dergachev), t-rasmud (Rashmi Mudduluru)
Differential revision: https://reviews.llvm.org/D156474
- Factor out the code that will be shared by both parameter and local variable fix-its
- Add a check to ensure that a TypeLoc::isNull is false before using the TypeLoc
- Remove the special check for whether a fixing variable involves unnamed types. This check is unnecessary now.
- Move tests for cv-qualified parameters and unnamed types out of the "...-unsupported.cpp" test file.
Reviewed by: NoQ (Artem Dergachev)
Differential revision: https://reviews.llvm.org/D156188
Fix the linting problems which causes `clang/utils/ci/run-buildbot check-format` to return 1.
Also make a correction for the email address of the author of
0fd4175907b40fe63131482c162d7e0f76000521:
The correct email address is "ar.ashouri999@gmail.com", not "ar.ashouri999@google.com".
Reviewed by: ziqingluo-90 (Ziqing Luo)
Differential revision: https://reviews.llvm.org/D155814
`FixableGadget`s are not always associated with variables that are unsafe
(warned). For example, they could be associated with variables whose
unsafe operations are suppressed or that are not used in any unsafe
operation. Such `FixableGadget`s will not be fixed. Removing these
`FixableGadget` as early as possible helps improve the performance
and stability of the analysis.
Reviewed by: NoQ (Artem Dergachev), t-rasmud (Rashmi Mudduluru)
Differential revision: https://reviews.llvm.org/D155524
The safe-buffer analysis analyzes TypeLocs of types of variable
declarations in order to get source locations of them.
However, in some cases, the source locations of a TypeLoc are not
valid. Using invalid source locations results in assertion violation
or incorrect analysis or fix-its.
It is still not clear to me in what circumstances a TypeLoc does not
have valid source locations (it looks like a bug in Clang to me, but
it is not our responsibility to fix it). So we will conservatively
give up the analysis when required source locations are not valid.
Reviewed By: NoQ (Artem Dergachev)
Differential Revision: https://reviews.llvm.org/D155667
It is possible that a function parameter does not have a name even in
a function definition. This patch deals with such cases in generating
function overload fix-its for safe buffers.
Reviewed by: NoQ (Artem Dergachev)
Differential revision: https://reviews.llvm.org/D155641
For a fix-it that inserts the `[[clang::unsafe_buffer_usage]]`
attribute, it will lookup existing macros defined for the attribute
and use the (last defined such) macro directly. Fix-its will use raw
`[[clang::unsafe_buffer_usage]]` if no such macro is defined.
The implementation mimics how a similar machine for the
`[[fallthrough]]` attribute was implemented.
Reviewed by: NoQ (Artem Dergachev)
Differential revision: https://reviews.llvm.org/D150338
Generate fix-its for function parameters that are raw pointers used
unsafely. Currently, the analyzer fixes one parameter at a time.
Fix-its for a function parameter includes:
- Fix the parameter declaration of the definition, result in a new
overload of the function. We call the function with the original
signature the old overload.
- For any other existing declaration of the old overload, mark it with
the [[unsafe_buffer_usage]] attribute and generate a new overload
declaration next to it.
- Creates a new definition for the old overload, which is simply
defined by a call to the new overload.
Reviewed by: NoQ (Artem Dergachev), t-rasmud (Rashmi Mudduluru), and
jkorous (Jan Korous)
Differential revision: https://reviews.llvm.org/D143048
This patch implements a new clang driver flag -fsafe-buffer-usage-suggestions
which allows turning the smart suggestion machine on and off (defaults to off).
This is valuable for stability reasons, as the machine is being rapidly improved\
and we don't want accidental breakages to ruin the build for innocent users.
It is also arguably useful in general because it enables separation of concerns
between project contributors: some users will actively update the code to
conform to the programming model, while others simply want to make sure that
they aren't regressing it. Finally, there could be other valid reasons to
opt out of suggestions entirely on some codebases (while continuing to enforce
-Wunsafe-buffer-usage warnings), such as lack of access to hardened libc++
(or even to the C++ standard library in general) on the target platform.
When the flag is disabled, the unsafe buffer usage analysis is reduced to
an extremely minimal mode of operation that contains virtually no smarts:
not only it doesn't offer automatic fixits, but also textual suggestions
such as "change the type of this variable to std::span to preserve bounds
information" are not displayed, and in fact the machine doesn't even try
to blame specific variables in the first place, it simply warns on
the operations and leaves everything else to the user. So this flag turns off
a lot more of our complex machinery than what we already turn off in presence
of say -fno-diagnostic-fixit-info.
The flag is discoverable: when it's off, the warnings are accompanied by a note:
telling the user that there's a flag they can use.
Differential Revision: https://reviews.llvm.org/D146669
This patch adds missing copy/move assignment operator to the class which has user-defined copy/move constructor.
Reviewed By: tahonermann
Differential Revision: https://reviews.llvm.org/D149718
When macros get expanded, the source location for the expanded code received by the Fixable
gadgets is invalid. We do not want to emit fixits for macro expanded code and it currently
crashes the analysis. This patch fixes the assertion violations that were introduced for
handling code with such invalid locations.
Reviewed by: NoQ, ziqingluo-90, jkorous
Differential revision: https://reviews.llvm.org/D146450
This patch handles unevaluated contexts to ensure no warnings are produced by the machinery
for buffer access made within an unevaluated contexts. However, such accesses must be
considered by a FixableGadget and produce the necessary fixits.
Reviewed by: NoQ, ziqingluo-90, jkorous
Differential revision: https://reviews.llvm.org/D144905
Reported by Coverity:
Copy without assign
This class has a user-defined copy constructor but no user-defined assignment operator. If the copy constructor is necessary to manage owned resources then a corresponding assignment operator is usually required. If an object of this type is assigned memory leaks and/or use-after-free errors may occur. Note that a compiler-generated assignment operator will perform only a bit-wise copy for any fields that do not have their own assignment operators defined.
Class has user-written copy constructor but no user-written assignment operator
copy_without_assign: Class <unnamed>::DeclUseTracker has a user-written copy constructor <unnamed>::DeclUseTracker::DeclUseTracker(<unnamed>::DeclUseTracker const &) =delete but no corresponding user-written assignment operator.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D148189
