| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
EvaluateAsInt() is sometimes called in a constant context. When that's the
case, we need to specify it as so.
llvm-svn: 347364
|
|
|
|
|
|
|
|
|
|
| |
Especially with pointees, a lot of meaningless reports came from uninitialized
regions that were already reported. This is fixed by storing all reported fields
to the GDM.
Differential Revision: https://reviews.llvm.org/D51531
llvm-svn: 347153
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend the alpha.core.Conversion checker to handle implicit converions
where a too large integer value is converted to a floating point type. Each
floating point type has a range where it can exactly represent all integers; we
emit a warning when the integer value is above this range. Although it is
possible to exactly represent some integers which are outside of this range
(those that are divisible by a large enough power of 2); we still report cast
involving those, because their usage may lead to bugs. (For example, if 1<<24
is stored in a float variable x, then x==x+1 holds.)
Patch by: Donát Nagy!
Differential Revision: https://reviews.llvm.org/D52730
llvm-svn: 347006
|
|
|
|
|
|
|
|
|
|
|
|
| |
Interestingly, only about the quarter of the emitter file is used, the DescFile
entry hasn't ever been touched [1], and the entire concept of groups is a
mystery, so I removed them.
[1] http://lists.llvm.org/pipermail/cfe-dev/2018-October/059664.html
Differential Revision: https://reviews.llvm.org/D53995
llvm-svn: 346680
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
have to be registered
One of the reasons why AnalyzerOptions is so chaotic is that options can be
retrieved from the command line whenever and wherever. This allowed for some
options to be forgotten for a looooooong time. Have you ever heard of
"region-store-small-struct-limit"? In order to prevent this in the future, I'm
proposing to restrict AnalyzerOptions' interface so that only checker options
can be retrieved without special getters. I would like to make every option be
accessible only through a getter, but checkers from plugins are a thing, so I'll
have to figure something out for that.
This also forces developers who'd like to add a new option to register it
properly in the .def file.
This is done by
* making the third checker pointer parameter non-optional, and checked by an
assert to be non-null.
* I added new, but private non-checkers option initializers, meant only for
internal use,
* Renamed these methods accordingly (mind the consistent name for once with
getBooleanOption!):
- getOptionAsString -> getCheckerStringOption,
- getOptionAsInteger -> getCheckerIntegerOption
* The 3 functions meant for initializing data members (with the not very
descriptive getBooleanOption, getOptionAsString and getOptionAsUInt names)
were renamed to be overloads of the getAndInitOption function name.
* All options were in some way retrieved via getCheckerOption. I removed it, and
moved the logic to getStringOption and getCheckerStringOption. This did cause
some code duplication, but that's the only way I could do it, now that checker
and non-checker options are separated. Note that the non-checker version
inserts the new option to the ConfigTable with the default value, but the
checker version only attempts to find already existing entries. This is how
it always worked, but this is clunky and I might end reworking that too, so we
can eventually get a ConfigTable that contains the entire configuration of the
analyzer.
Differential Revision: https://reviews.llvm.org/D53483
llvm-svn: 346113
|
|
|
|
|
|
|
|
|
|
|
|
| |
Interestingly, this many year old (when I last looked I remember 2010ish)
checker was committed without any tests, so I thought I'd implement them, but I
was shocked to see how I barely managed to get it working. The code is severely
outdated, I'm not even sure it has ever been used, so I'd propose to move it
back into alpha, and possibly even remove it.
Differential Revision: https://reviews.llvm.org/D53856
llvm-svn: 345990
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm in the process of refactoring AnalyzerOptions. The main motivation behind
here is to emit warnings if an invalid -analyzer-config option is given from
the command line, and be able to list them all.
In this patch, I found some flags that should've been used as checker options,
or have absolutely no mention of in AnalyzerOptions, or are nonexistent.
- NonLocalizedStringChecker now uses its "AggressiveReport" flag as a checker
option
- lib/StaticAnalyzer/Frontend/ModelInjector.cpp now accesses the "model-path"
option through a getter in AnalyzerOptions
- -analyzer-config path-diagnostics-alternate=false is not a thing, I removed it,
- lib/StaticAnalyzer/Checkers/AllocationDiagnostics.cpp and
lib/StaticAnalyzer/Checkers/AllocationDiagnostics.h are weird, they actually
only contain an option getter. I deleted them, and fixed RetainCountChecker
to get it's "leak-diagnostics-reference-allocation" option as a checker option,
- "region-store-small-struct-limit" has a proper getter now.
Differential Revision: https://reviews.llvm.org/D53276
llvm-svn: 345985
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch should not introduce any behavior changes. It consists of
mostly one of two changes:
1. Replacing fall through comments with the LLVM_FALLTHROUGH macro
2. Inserting 'break' before falling through into a case block consisting
of only 'break'.
We were already using this warning with GCC, but its warning behaves
slightly differently. In this patch, the following differences are
relevant:
1. GCC recognizes comments that say "fall through" as annotations, clang
doesn't
2. GCC doesn't warn on "case N: foo(); default: break;", clang does
3. GCC doesn't warn when the case contains a switch, but falls through
the outer case.
I will enable the warning separately in a follow-up patch so that it can
be cleanly reverted if necessary.
Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu
Differential Revision: https://reviews.llvm.org/D53950
llvm-svn: 345882
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
delete.
MallocChecker no longer thinks that operator delete() that accepts the size of
the object to delete (available since C++14 or under -fsized-deallocation)
is some weird user-defined operator. Instead, it handles it like normal delete.
Additionally, it exposes a regression in NewDelete-intersections.mm's
testStandardPlacementNewAfterDelete() test, where the diagnostic is delayed
from before the call of placement new into the code of placement new
in the header. This happens because the check for pass-into-function-after-free
for placement arguments is located in checkNewAllocator(), which happens after
the allocator is inlined, which is too late. Move this use-after-free check
into checkPreCall instead, where it works automagically because the guard
that prevents it from working is useless and can be removed as well.
This commit causes regressions under -analyzer-config
c++-allocator-inlining=false but this option is essentially unsupported
because the respective feature has been enabled by default quite a while ago.
Differential Revision: https://reviews.llvm.org/D53543
llvm-svn: 345802
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inlined code
Trusting summaries of inlined code would require a more thorough work,
as the current approach was causing too many false positives, as the new
example in test. The culprit lies in the fact that we currently escape
all variables written into a field (but not passed off to unknown
functions!), which can result in inconsistent behavior.
rdar://45655344
Differential Revision: https://reviews.llvm.org/D53902
llvm-svn: 345746
|
|
|
|
|
|
|
|
| |
The FP rate seems to be good enough now.
Differential Revision: https://reviews.llvm.org/D53849
llvm-svn: 345745
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A ConstantExpr class represents a full expression that's in a context where a
constant expression is required. This class reflects the path the evaluator
took to reach the expression rather than the syntactic context in which the
expression occurs.
In the future, the class will be expanded to cache the result of the evaluated
expression so that it's not needlessly re-evaluated
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D53475
llvm-svn: 345692
|
|
|
|
|
|
|
|
|
|
| |
We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.
Differential revision: https://reviews.llvm.org/D53547
llvm-svn: 345637
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing padding checker skips classes that have any base classes.
This patch allows the checker to traverse very simple cases:
classes that have no fields and have exactly one base class.
This is important mostly in the case of array declarations.
Patch by Max Bernstein!
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D53206
llvm-svn: 345558
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, OSDynamicCast was modeled as an identity.
This is not correct: the output of OSDynamicCast may be zero even if the
input was not zero (if the class is not of desired type), and thus the
modeling led to false positives.
Instead, we are doing eager state split:
in one branch, the returned value is identical to the input parameter,
and in the other branch, the returned value is zero.
This patch required a substantial refactoring of canEval infrastructure,
as now it can return different function summaries, and not just true/false.
rdar://45497400
Differential Revision: https://reviews.llvm.org/D53624
llvm-svn: 345338
|
|
|
|
|
|
|
|
| |
Remove unused overload. Clean up some usages.
Differential Revision: https://reviews.llvm.org/D53615
llvm-svn: 345101
|
|
|
|
|
|
|
|
| |
Trust generalized annotations for OSObject.
Differential Revision: https://reviews.llvm.org/D53550
llvm-svn: 345100
|
|
|
|
|
|
|
|
| |
Refactor the way in which summaries are consumed for safeMetaCast
Differential Revision: https://reviews.llvm.org/D53549
llvm-svn: 345099
|
|
|
|
|
|
|
|
|
|
|
|
| |
trackNullOrUndefValue is a long and confusing name,
and it does not actually reflect what the function is doing.
Give a function a new name, with a relatively clear semantics.
Also remove some dead code.
Differential Revision: https://reviews.llvm.org/D52758
llvm-svn: 345064
|
|
|
|
|
|
|
|
| |
As rightly pointed out by @NoQ, nonloc::LazyCompoundVals were only used to acquire a constructed object's region, which isn't what LazyCompoundVal was made for.
Differential Revision: https://reviews.llvm.org/D51300
llvm-svn: 344879
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tags.
We don't need a separate node for every symbol, because whenever the first
symbol leaks, a bug is emitted, the analysis is sinked, and the checker
callback immediately returns due to State variable turning into null,
so we never get to see the second leaking symbol.
Additionally, we are no longer able to break normal analysis while experimenting
with debug dumps.
Differential Revision: https://reviews.llvm.org/D52804
llvm-svn: 344538
|
|
|
|
| |
llvm-svn: 344468
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: ilya-biryukov
Subscribers: arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D53135
llvm-svn: 344337
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D53168
llvm-svn: 344312
|
|
|
|
|
|
|
|
|
|
|
| |
For now, tresting the cast as a no-op, and disregarding the case where
the output becomes null due to the type mismatch.
rdar://45174557
Differential Revision: https://reviews.llvm.org/D53156
llvm-svn: 344311
|
|
|
|
|
|
| |
This reverts commit r344262. This was an unintentional commit.
llvm-svn: 344267
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D52502
llvm-svn: 344262
|
|
|
|
|
|
|
|
|
|
|
| |
I've added a new functionality, the checker is now able to
detect and report fields pointing to themselves. I figured
this would fit well into the checker as there's no reason
for a pointer to point to itself instead of being nullptr.
Differential Revision: https://reviews.llvm.org/D51305
llvm-svn: 344242
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D52983
llvm-svn: 344017
|
|
|
|
|
|
|
|
|
|
| |
enough to make the state unfeasible
rdar://43541814
Differential Revision: https://reviews.llvm.org/D52848
llvm-svn: 343735
|
|
|
|
| |
llvm-svn: 343574
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D52502
llvm-svn: 343573
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D52640
llvm-svn: 343353
|
|
|
|
| |
llvm-svn: 343205
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D52502
llvm-svn: 343204
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 343085
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tests introduced in r329780 was disabled in r342317 because these tests
were accidentally testing dump infrastructure, when all they cared about was
how symbols relate to each other. So when dump infrastructure changed,
tests became annoying to maintain.
Add a new feature to ExprInspection: clang_analyzer_denote() and
clang_analyzer_explain(). The former adds a notation to a symbol, the latter
expresses another symbol in terms of previously denoted symbols.
It's currently a bit wonky - doesn't print parentheses and only supports
denoting atomic symbols. But it's even more readable that way.
Differential Revision: https://reviews.llvm.org/D52133
llvm-svn: 343048
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a checker maintains a program state trait that isn't a simple list/set/map, but is a combination of multiple lists/sets/maps (eg., a multimap - which may be implemented as a map from something to set of something), ProgramStateManager only contains the factory for the trait itself. All auxiliary lists/sets/maps need a factory to be provided by the checker, which is annoying.
So far two checkers wanted a multimap, and both decided to trick the
ProgramStateManager into keeping the auxiliary factory within itself
by pretending that it's some sort of trait they're interested in,
but then never using this trait but only using the factory.
Make this trick legal. Define a convenient macro.
One thing that becomes apparent once all pieces are put together is that
these two checkers are in fact using the same factory, because the type that
identifies it, ImmutableMap<const MemRegion *, ImmutableSet<SymbolRef>>,
is the same. This situation is different from two checkers registering similar
primitive traits.
Differential Revision: https://reviews.llvm.org/D51388
llvm-svn: 343035
|
|
|
|
|
|
|
|
| |
ImmutableList
Differential Revision: https://reviews.llvm.org/D51886
llvm-svn: 342834
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Assuming strlcat is used with strlcpy we check as we can if the last argument does not equal os not larger than the buffer.
Advising the proper usual pattern.
Reviewers: george.karpenkov, NoQ, MaskRay
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D49722
llvm-svn: 342832
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modify the RetainCountChecker to perform state "adjustments" in
checkEndFunction, as performing work in PreStmt<ReturnStmt> does not
work with destructors.
The previous version made an implicit assumption that no code runs
after the return statement is executed.
rdar://43945028
Differential Revision: https://reviews.llvm.org/D52338
llvm-svn: 342770
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D52336
llvm-svn: 342767
|
|
|
|
|
|
| |
To fix compiler warning about non-virtual dtor introduced in r342221.
llvm-svn: 342225
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D49437
llvm-svn: 342221
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
it's fields
Based on a suggestion from @george.karpenkov.
In some cases, structs are used as unions with a help of a tag/kind field.
This patch adds a new string flag (a pattern), that is matched against the
fields of a record, and should a match be found, the entire record is ignored.
For more info refer to http://lists.llvm.org/pipermail/cfe-dev/2018-August/058906.html
and to the responses to that, especially http://lists.llvm.org/pipermail/cfe-dev/2018-August/059215.html.
Differential Revision: https://reviews.llvm.org/D51680
llvm-svn: 342220
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since I plan to add a number of new flags, it made sense to encapsulate
them in a new struct, in order not to pollute FindUninitializedFields's
constructor with new boolean options with super long names.
This revision practically reverts D50508, since FindUninitializedFields
now accesses the pedantic flag anyways.
Differential Revision: https://reviews.llvm.org/D51679
llvm-svn: 342219
|
|
|
|
|
|
|
|
| |
record pointees
Differential Revision: https://reviews.llvm.org/D50892
llvm-svn: 342217
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the comments are incorrect, imprecise, or simply nonexistent.
Since I have a better grasp on how the analyzer works, it makes sense
to update most of them in a single swoop.
I tried not to flood the code with comments too much, this amount
feels just right to me.
Differential Revision: https://reviews.llvm.org/D51417
llvm-svn: 342215
|
|
|
|
|
|
|
|
|
|
| |
iThis patch aims to fix derefencing, which has been debated for months now.
Instead of working with SVals, the function now relies on TypedValueRegion.
Differential Revision: https://reviews.llvm.org/D51057
llvm-svn: 342213
|