| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
buffers."
This reverts commit 200007ec85f81122fd260a4e68308e54607ca37a.
|
|
This is the initial commit for -Wunsafe-buffer-usage, a warning that helps
codebases (especially modern C++ codebases) transition away from raw buffer
pointers.
The warning is implemented in libAnalysis as it's going to become a non-trivial
analysis, mostly the fixit part where we try to figure out if we understand
a variable's use pattern well enough to suggest a safe container/view
as a replacement. Some parts of this analsysis may eventually prove useful
for any similar fixit machine that tries to change types of variables.
The warning is disabled by default.
RFC/discussion in https://discourse.llvm.org/t/rfc-c-buffer-hardening/65734
Differential Revision: https://reviews.llvm.org/D137346
|
|
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D130403
|
|
|
|
If no capability is held, or the capability expression is invalid, there
is obviously no capability kind and so none would be reported.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D124132
|
|
Identified with readability-redundant-member-init.
|
|
After 04f30795f16638, -Wreturn-type has an effect on functions that
contain @try/@catch statements. CheckFallThrough() was missing
a case for ObjCAtTryStmts, leading to a false positive.
(What about the other two places in CheckFallThrough() that handle
CXXTryStmt but not ObjCAtTryStmts?
- I think the last use of CXXTryStmt is dead in practice: 04c6851cd made it so
that calls never add edges to try bodies, and the CFG block for a try
statement is always an empty block containing just the try element itself as
terminator (the try body itself is part of the normal flow of the function
and not connected to the block for the try statement itself. The try statment
cfg block is only connected to the catch bodies, and only reachable from
throw expressions within the try body.)
- The first use of CXXTryStmt might be important. It looks similar to
the code that adds all cfg blocks for try statements as roots of
the reachability graph for the reachability warnings, but I can't
find a way to trigger it. So I'm omitting it for now. The CXXTryStmt
code path seems to only be hit by try statements that are function
bodies without a surrounding compound statements
(`f() try { ... } catch ...`), and those don't exist for ObjC
@try statements.
)
Fixes PR52473.
Differential Revfision: https://reviews.llvm.org/D114660
|
|
|
|
|
|
CFGBuilder::addStmt() implicitly passes AddStmtChoice::AlwaysAdd
to Visit() already, so this should have no behavior change.
Differential Revision: https://reviews.llvm.org/D111570
|
|
|
|
|
|
The Linux kernel has a macro called IS_ENABLED(), which evaluates to a
constant 1 or 0 based on Kconfig selections, allowing C code to be
unconditionally enabled or disabled at build time. For example:
int foo(struct *a, int b) {
switch (b) {
case 1:
if (a->flag || !IS_ENABLED(CONFIG_64BIT))
return 1;
__attribute__((fallthrough));
case 2:
return 2;
default:
return 3;
}
}
There is an unreachable warning about the fallthrough annotation in the
first case because !IS_ENABLED(CONFIG_64BIT) can be evaluated to 1,
which looks like
return 1;
__attribute__((fallthrough));
to clang.
This type of warning is pointless for the Linux kernel because it does
this trick all over the place due to the sheer number of configuration
options that it has.
Add -Wunreachable-code-fallthrough, enabled under -Wunreachable-code, so
that projects that want to warn on unreachable code get this warning but
projects that do not care about unreachable code can still use
-Wimplicit-fallthrough without having to make changes to their code
base.
Fixes PR51094.
Reviewed By: aaron.ballman, nickdesaulniers
Differential Revision: https://reviews.llvm.org/D107933
|
|
Objective-C++ is not yet suppoerted.
rdar://76729552
Differential Revision: https://reviews.llvm.org/D100955
|
|
This patch introduces a very simple inter-procedural analysis
between blocks and enclosing functions.
We always analyze blocks first (analysis is done as part of semantic
analysis that goes side-by-side with the parsing process), and at the
moment of reporting we don't know how that block will be actually
used.
This patch introduces new logic delaying reports of the "never called"
warnings on blocks. If we are not sure that the block will be called
exactly once, we shouldn't warn our users about that. Double calls,
however, don't require such delays. While analyzing the enclosing
function, we can actually decide what we should do with those
warnings.
Additionally, as a side effect, we can be more confident about blocks
in such context and can treat them not as escapes, but as direct
calls.
rdar://74090107
Differential Revision: https://reviews.llvm.org/D98688
|
|
This commit introduces a new attribute `called_once`.
It can be applied to function-like parameters to signify that
this parameter should be called exactly once. This concept
is particularly widespread in asynchronous programs.
Additionally, this commit introduce a new group of dataflow
analysis-based warnings to check this property. It identifies
and reports the following situations:
* parameter is called twice
* parameter is never called
* parameter is not called on one of the paths
Current implementation can also automatically infer `called_once`
attribute for completion handler paramaters that should follow the
same principle by convention. This behavior is OFF by default and
can be turned on by using `-Wcompletion-handler`.
Differential Revision: https://reviews.llvm.org/D92039
rdar://72812043
|
|
device functions"
This recommits 7f1f89ec8d9944559042bb6d3b1132eabe3409de and
40df06cdafc010002fc9cfe1dda73d689b7d27a6 with bug fixes for
memory sanitizer failure and Tensile build failure.
|
|
host device functions""
This reverts commit e39da8ab6a286ac777d5fe7799f1eb782cf99938.
This depends on a change that needs additional design review and needs
to be reverted.
|
|
device functions"
This recommits 7f1f89ec8d9944559042bb6d3b1132eabe3409de and
40df06cdafc010002fc9cfe1dda73d689b7d27a6 after fixing memory
sanitizer failure.
|
|
functions"
This reverts commit 7f1f89ec8d9944559042bb6d3b1132eabe3409de.
This reverts commit 40df06cdafc010002fc9cfe1dda73d689b7d27a6.
|
|
In CUDA/HIP a function may become implicit host device function by
pragma or constexpr. A host device function is checked in both
host and device compilation. However it may be emitted only
on host or device side, therefore the diagnostics should be
deferred until it is known to be emitted.
Currently clang is only able to defer certain diagnostics. This causes
false alarms and limits the usefulness of host device functions.
This patch lets clang defer all overloading resolution diagnostics for host device functions.
An option -fgpu-defer-diag is added to control this behavior. By default
it is off.
It is NFC for other languages.
Differential Revision: https://reviews.llvm.org/D84364
|
|
Other warning messages for negative capabilities also mention their
kind, and the double space was ugly.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D84603
|
|
`OS << ND->getDeclName();` is equivalent to `OS << ND->getNameAsString();`
without the extra temporary string.
This is not quite a NFC since two uses of `getNameAsString` in a
diagnostic are replaced, which results in the named entity being
quoted with additional "'"s (ie: 'var' instead of var).
|
|
Summary:
When getting a warning that we release a capability that isn't held it's
sometimes not clear why. So just like we do for double locking, we add a
note on the previous release operation, which marks the point since when
the capability isn't held any longer.
We can find this previous release operation by looking up the
corresponding negative capability.
Reviewers: aaron.ballman, delesley
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D81352
|
|
const reference parameters to a function
Summary:
Add a new warning -Wuninitialized-const-reference as a subgroup of -Wuninitialized to address a bug filed here: https://bugs.llvm.org/show_bug.cgi?id=45624
This warning is controlled by -Wuninitialized and can be disabled by -Wno-uninitialized-const-reference.
The warning is diagnosed when passing uninitialized variables as const reference parameters to a function.
Differential Revision: https://reviews.llvm.org/D79895
|
|
This reverts commit 398b4ed87d488b42032c8d0304324dce76ba9b66.
As requested in https://bugs.llvm.org/show_bug.cgi?id=43465#c37 .
|
|
The regex can be extended if needed, but this should probably handle
most of the cases.
Differential Revision: https://reviews.llvm.org/D73852
|
|
This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall.
Differential Revision: https://reviews.llvm.org/D71529
|
|
Taking a value and the bitwise-or it with a non-zero constant will always
result in a non-zero value. In a boolean context, this is always true.
if (x | 0x4) {} // always true, intended '&'
This patch creates a new warning group -Wtautological-bitwise-compare for this
warning. It also moves in the existing tautological bitwise comparisons into
this group. A few other changes were needed to the CFGBuilder so that all bool
contexts would be checked. The warnings in -Wtautological-bitwise-compare will
be off by default due to using the CFG.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=42666
Differential Revision: https://reviews.llvm.org/D66046
llvm-svn: 375318
|
|
Summary: Fixed extraneous matches of non-NullStmt
Reviewers: aaron.ballman, rsmith, efriedma, xbolva00
Reviewed By: aaron.ballman, rsmith, xbolva00
Subscribers: riccibruno, arphaman, ziangwan, ojeda, xbolva00, nickdesaulniers, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64838
llvm-svn: 369414
|
|
function scope.
This removes one of the last few cases where we build expressions in the
wrong function scope context. No functionality change intended.
llvm-svn: 362178
|
|
Turn it into a variant class instead. This conversion does indeed save some code
but there's a plan to add support for more kinds of terminators that aren't
necessarily based on statements, and with those in mind it becomes more and more
confusing to have CFGTerminators implicitly convertible to a Stmt *.
Differential Revision: https://reviews.llvm.org/D61814
llvm-svn: 361586
|
|
where either the modification or the other access is unreachable.
This reverts r359984 (which reverted r359962). The bug in clang-tidy's
test suite exposed by the original commit was fixed in r360009.
llvm-svn: 360010
|
|
false positives
where either the modification or the other access is unreachable.
........
Try to fix buildbots
llvm-svn: 359984
|
|
where either the modification or the other access is unreachable.
llvm-svn: 359962
|
|
recursively captured.
Under ARC, a block variable is zero-initialized when it is recursively
captured by the block literal initializer.
rdar://problem/11022762
llvm-svn: 359049
|
|
See D59455.
llvm-svn: 356430
|
|
Summary:
Similar to D56967, we add the existing diag::note_locked_here to tell
the user where we saw the locking that isn't matched correctly.
Reviewers: aaron.ballman, delesley
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59455
llvm-svn: 356427
|
|
Summary:
When this was rewritten in D43737, the logic changed to better explore infinite loops. The check for a reachable exit block was deleted which accidentally introduced false positives in case the exit node was unreachable.
We were testing for cases like this, but @steven_wu provided an additional test case that I've included in the regression tests for this patch.
Reviewers: steven_wu, rtrieu
Reviewed By: steven_wu, rtrieu
Subscribers: cfe-commits, steven_wu
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58122
llvm-svn: 353984
|
|
Summary:
We use the existing diag::note_locked_here to tell the user where we saw
the first locking.
Reviewers: aaron.ballman, delesley
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D56967
llvm-svn: 352549
|
|
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
Summary:
This fixes ASTContext's parent map for nodes in such classes (e.g. operator()).
https://bugs.llvm.org/show_bug.cgi?id=39949
This also changes the observed shape of the AST for implicit RAVs.
- this includes AST MatchFinder: cxxRecordDecl() now matches lambda classes,
functionDecl() matches the call operator, and the parent chain is body -> call
operator -> lambda class -> lambdaexpr rather than body -> lambdaexpr.
- this appears not to matter for the ASTImporterLookupTable builder
- this doesn't matter for the other RAVs in-tree.
In order to do this, we remove the TraverseLambdaBody hook. The problem is it's
hard/weird to ensure this hook is called when traversing via the implicit class.
There were just two users of this hook in-tree, who use it to skip bodies.
I replaced these with explicitly traversing the captures only. Another approach
would be recording the bodies when the lambda is visited, and then recognizing
them later.
I'd be open to suggestion on how to preserve this hook, instead.
Reviewers: aaron.ballman, JonasToth
Subscribers: cfe-commits, rsmith, jdennett
Differential Revision: https://reviews.llvm.org/D56444
llvm-svn: 351047
|
|
It seems the two failing tests can be simply fixed after r348037
Fix 3 cases in Analysis/builtin-functions.cpp
Delete the bad CodeGen/builtin-constant-p.c for now
llvm-svn: 348053
|
|
Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp
while we are investigating why the following snippet fails:
extern char extern_var;
struct { int a; } a = {__builtin_constant_p(extern_var)};
llvm-svn: 348039
|
|
This was reverted in r347656 due to me thinking it caused a miscompile of
Chromium. Turns out it was the Chromium code that was broken.
llvm-svn: 347756
|
|
This caused a miscompile in Chrome (see crbug.com/908372) that's
illustrated by this small reduction:
static bool f(int *a, int *b) {
return !__builtin_constant_p(b - a) || (!(b - a));
}
int arr[] = {1,2,3};
bool g() {
return f(arr, arr + 3);
}
$ clang -O2 -S -emit-llvm a.cc -o -
g() should return true, but after r347417 it became false for some reason.
This also reverts the follow-up commits.
r347417:
> Re-Reinstate 347294 with a fix for the failures.
>
> Don't try to emit a scalar expression for a non-scalar argument to
> __builtin_constant_p().
>
> Third time's a charm!
r347446:
> The result of is.constant() is unsigned.
r347480:
> A __builtin_constant_p() returns 0 with a function type.
r347512:
> isEvaluatable() implies a constant context.
>
> Assume that we're in a constant context if we're asking if the expression can
> be compiled into a constant initializer. This fixes the issue where a
> __builtin_constant_p() in a compound literal was diagnosed as not being
> constant, even though it's always possible to convert the builtin into a
> constant.
r347531:
> A "constexpr" is evaluated in a constant context. Make sure this is reflected
> if a __builtin_constant_p() is a part of a constexpr.
llvm-svn: 347656
|
|
Don't try to emit a scalar expression for a non-scalar argument to
__builtin_constant_p().
Third time's a charm!
llvm-svn: 347417
|
|
llvm-svn: 347389
|
|
EvaluateAsInt() is sometimes called in a constant context. When that's the
case, we need to specify it as so.
llvm-svn: 347364
|
|
Summary: The convenience wrapper in STLExtras is available since rL342102.
Reviewers: rsmith, #clang, dblaikie
Reviewed By: rsmith, #clang
Subscribers: mgrang, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D52576
llvm-svn: 343147
|
