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
For a pointer type expression `e` of the form `++DRE`, if `e` is under
an Unspecified Pointer Context (UPC) and `DRE` is suppose to be
transformed to have std:span type, we generate fix-its that transform `e` to
`(DRE = DRE.subspan(1)).data()`.
For reference, `e` is in an UPC if `e` is
- an argument of a function call (except the callee has [[unsafe_buffer_usage]] attribute), or
- the operand of a cast-to-(Integer or Boolean) operation; or
- the operand of a pointer subtraction operation; or
- the operand of a pointer comparison operation;
We may extend the definition of UPC by adding more cases later.
Reviewed by: NoQ (Artem Dergachev)
Differential revision: https://reviews.llvm.org/D144304
Add two new unique cases to the Unspecified Pointer Context (UPC),
under which we match unsafe operation patterns:
- A pointer being casted to a boolean value is in a UPC;
- A pointer participating in pointer subtraction is in a UPC.
Reviewed by: NoQ (Artem Dergachev), malavikasamak (Malavika Samak)
Differential revision: https://reviews.llvm.org/D144064
For a local pointer declaration of the form `T * p = 0` or `T * p = std::nullptr`,
Before this patch, we generate fix-its that convert the declaration to
`std::span<T> p{nullptr, <# placeholder #>}`, in cases where `p` is
used in some unsafe operations. This patch improves the fix-its to
result in a simpler form `std::span<T> p`. It gets rid of the
placeholder and keeps the result concise.
Reviewed by: NoQ (Artem Dergachev)
Differential Revision: https://reviews.llvm.org/D143680
This patch introduces UPCStandalonePointerGadget, a FixableGadget that emits fixits to
handle cases where a pointer identified as unsafe is simply referenced. An example of
such a case is when the pointer is input as an argument to a method call, where we can
not change the type of the argument. For cases where the strategy for the unsafe pointer is
to use std::span, the idea is to extract the underlying pointer by invoking the "data()"
method on the span instance.
For example, the gadget emits a fixit for S3, where S1, S2 are handled by other gadgets:
S1: int *ptr = new int[10];
S2: int val1 = ptr[k]; // Unsafe operation on ptr
S3: foo(ptr); // Some method that accepts raw pointer => FIXIT: foo(ptr.data());
Reviewed by: NoQ, ziqingluo-90, jkorous
Differential revision: https://reviews.llvm.org/D143676
For an expression of the form `&DRE[any]` under an Unspecified
Pointer Context (UPC), we generate a fix-it for it with respect to a
strategy. In case the strategy is `std::span` (it is the only supported
one for now), the fix-it replaces the expression with
`&DRE.data()[any]`.
A UPC includes at least the contexts where
- the expression is being casted to an integer; and
- the expression is an argument of a call to a function that is not marked unsafe.
Reviewed by: NoQ, malavikasamak, t-rasmud, jkorous
Differential revision: https://reviews.llvm.org/D143128
This patch introduces PointerDereferenceGadget, a FixableGadget that emits
fixits to handle cases where a pointer that is identified as unsafe is
dereferenced. The current implementation only handles cases where the strategy
is to change the type of the raw pointer to std::span. The fixit for this
strategy is to fetch the first element from the corresponding span instance.
For example for the code below, the PointerDereferenceGadget emits a fixit for
S3 (S1, S2 are to be handled by other gadgets):
S1: int *ptr = new int[10];
S2: int val1 = ptr[k]; // Unsafe operation
S3: int val2 = *ptr; => Fixit: int val2 = ptr[0];
Differential revision: https://reviews.llvm.org/D143206
For each expression `e` of the form `*(DRE + n)` (or `*(n + DRE)`), where
`DRE` has a pointer type and `n` is an integer literal, `e` will be
transformed to `DRE[n]` (or `n[DRE]` respectively), if
- `e` is at the left-hand side of an assignment or is an lvalue being casted to an rvalue; and
- the variable referred by `DRE` is going to be transformed to be of `std::span` type.
Reviewed by: jkorous, NoQ
Differential revision: https://reviews.llvm.org/D142795
The -Wunsafe-buffer-usage analysis outputs diagnostics in the order of
pointer values to associated `VarDecl`s. This creates non-determinism
in the order of diagnostics in output since the order cannot be
guaranteed in pointer values. However, our fix-it tests were written
under the assumption that diagnostics are output in source location
order. This results in non-deterministic failures in our tests. This
patch fixes the problem by keeping analysis results sorted by source
locations.
Reviewed by: jkorous, NoQ
Differential revision: https://reviews.llvm.org/D145993
Let generate fix-its to make assignments' left-hand side of the form
`dre[e]` safe if `e` is known to be non-negative.
Commit on behalf of jkorous (Jan Korous)
Reviewed by: NoQ (Artem Dergachev)
Differential revision: https://reviews.llvm.org/D142794
The transformation strategy we are bringing up heavily relies on std::span which was introduced as part of C++20.
Differential Revision: https://reviews.llvm.org/D143455
Add a pair of clang pragmas:
- `#pragma clang unsafe_buffer_usage begin` and
- `#pragma clang unsafe_buffer_usage end`,
which specify the start and end of an (unsafe buffer checking) opt-out
region, respectively.
Behaviors of opt-out regions conform to the following rules:
- No nested nor overlapped opt-out regions are allowed. One cannot
start an opt-out region with `... unsafe_buffer_usage begin` but never
close it with `... unsafe_buffer_usage end`. Mis-use of the pragmas
will be warned.
- Warnings raised from unsafe buffer operations inside such an opt-out
region will always be suppressed. This behavior CANNOT be changed by
`clang diagnostic` pragmas or command-line flags.
- Warnings raised from unsafe operations outside of such opt-out
regions may be reported on declarations inside opt-out
regions. These warnings are NOT suppressed.
- An un-suppressed unsafe operation warning may be attached with
notes. These notes are NOT suppressed as well regardless of whether
they are in opt-out regions.
The implementation maintains a separate sequence of location pairs
representing opt-out regions in `Preprocessor`. The `UnsafeBufferUsage`
analyzer reads the region sequence to check if an unsafe operation is
in an opt-out region. If it is, discard the warning raised from the
operation immediately.
This is a re-land after I reverting it at 9aa00c8a30.
The compilation error should be resolved.
Reviewed by: NoQ
Differential revision: https://reviews.llvm.org/D140179
Add a pair of clang pragmas:
- `#pragma clang unsafe_buffer_usage begin` and
- `#pragma clang unsafe_buffer_usage end`,
which specify the start and end of an (unsafe buffer checking) opt-out
region, respectively.
Behaviors of opt-out regions conform to the following rules:
- No nested nor overlapped opt-out regions are allowed. One cannot
start an opt-out region with `... unsafe_buffer_usage begin` but never
close it with `... unsafe_buffer_usage end`. Mis-use of the pragmas
will be warned.
- Warnings raised from unsafe buffer operations inside such an opt-out
region will always be suppressed. This behavior CANNOT be changed by
`clang diagnostic` pragmas or command-line flags.
- Warnings raised from unsafe operations outside of such opt-out
regions may be reported on declarations inside opt-out
regions. These warnings are NOT suppressed.
- An un-suppressed unsafe operation warning may be attached with
notes. These notes are NOT suppressed as well regardless of whether
they are in opt-out regions.
The implementation maintains a separate sequence of location pairs
representing opt-out regions in `Preprocessor`. The `UnsafeBufferUsage`
analyzer reads the region sequence to check if an unsafe operation is
in an opt-out region. If it is, discard the warning raised from the
operation immediately.
Reviewed by: NoQ
Differential revision: https://reviews.llvm.org/D140179
Two fix-its conflict if they have overlapping source ranges. We shall
not emit conflicting fix-its. This patch checks conflicts in 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.
Reviewed by: NoQ
Differential revision: https://reviews.llvm.org/D141338
Use clang fix-its to transform declarations of local variables, which
are used for buffer access , to be of std::span type.
We placed a few limitations to keep the solution simple:
- it only transforms local variable declarations (no parameter declaration);
- it only considers single level pointers, i.e., pointers of type T * regardless of whether T is again a pointer;
- it only transforms to std::span types (no std::array, or std::span::iterator, or ...);
- it can only transform a VarDecl that belongs to a DeclStmt whose has a single child.
One of the purposes of keeping this patch simple enough is to first
evaluate if fix-it is an appropriate approach to do the
transformation.
This commit was reverted by 622be09c81
for a compilation warning and now it is fixed.
Reviewed by: NoQ, jkorous
Differential revision: https://reviews.llvm.org/D139737
Use clang fix-its to transform declarations of local variables, which are used for buffer access , to be of std::span type.
We placed a few limitations to keep the solution simple:
- it only transforms local variable declarations (no parameter declaration);
- it only considers single level pointers, i.e., pointers of type T * regardless of whether T is again a pointer;
- it only transforms to std::span types (no std::array, or std::span::iterator, or ...);
- it can only transform a VarDecl that belongs to a DeclStmt whose has a single child.
One of the purposes of keeping this patch simple enough is to first
evaluate if fix-it is an appropriate approach to do the
transformation.
Reviewed by: NoQ, jkorous
Differential revision: https://reviews.llvm.org/D139737
We have WIP Fixables for local variables and this central part of the machinery
was dropping Fixables attached to local variables instead of keeping those and
dropping everything else.
We are in the process of rewriting our patches for emitting fixits after we
discovered a conceptual problem in our design.
That is why there's currently no tests that would've detected the issue but
that will change very shortly.
