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
Summary:
This patch moves the last method in `Z3ConstraintManager` to `SMTConstraintManager`: `canReasonAbout()`.
The `canReasonAbout()` method checks if a given `SVal` can be encoded in SMT. I've added a new method to the SMT API to return true if a solver can encode floating-point arithmetics and it was enough to make `canReasonAbout()` solver independent.
As an annoying side-effect, `Z3ConstraintManager` is pretty empty now and only (1) creates the Z3 solver object by calling `CreateZ3Solver()` and (2) instantiates `SMTConstraintManager`. Maybe we can get rid of this class altogether in the future: a `CreateSMTConstraintManager()` method that does (1) and (2) and returns the constraint manager object?
Reviewers: george.karpenkov, NoQ
Reviewed By: george.karpenkov
Subscribers: mehdi_amini, xazax.hun, szepet, a.sidorin, dexonsmith, Szelethus, donat.nagy, dkrupp
Differential Revision: https://reviews.llvm.org/D53694
llvm-svn: 345284
Summary:
Getting an `APSInt` from the model always returned an unsigned integer because of the unused parameter.
This was not breaking any test case because no code relies on the actual value of the integer returned here, but rather it is only used to check if a symbol has more than one solution in `getSymVal`.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin, Szelethus, donat.nagy, dkrupp
Differential Revision: https://reviews.llvm.org/D53637
llvm-svn: 345283
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
This patch is a part of https://reviews.llvm.org/D48456 in an attempt to split
the casting logic up into smaller patches. This contains the code for casting
from fixed point types to boolean types.
Differential Revision: https://reviews.llvm.org/D53308
llvm-svn: 345063
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
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.
This first NFC patch contains small modifications to make AnalyzerOptions.cpp a
little more consistent.
Differential Revision: https://reviews.llvm.org/D53274
llvm-svn: 344870
The GDMIndex functions return a pointer that's used as a key for looking up
data, but addresses of local statics defined in header files aren't the same
across shared library boundaries and the result is that analyzer plugins
can't access this data.
Event types are uniqued by using the addresses of a local static defined
in a header files, but it isn't the same across shared library boundaries
and plugins can't currently handle ImplicitNullDerefEvents.
Patches by Joe Ranieri!
Differential Revision: https://reviews.llvm.org/D52905
Differential Revision: https://reviews.llvm.org/D52906
llvm-svn: 344823
In C++17, when class C has large alignment value, a special case of
overload resolution rule kicks in for expression new C that causes the aligned
version of operator new() to be called. The aligned new has two arguments:
size and alignment. However, the new-expression has only one "argument":
the construct-expression for C(). This causes a false positive in
core.CallAndMessage's check for matching number of arguments and number
of parameters.
Update CXXAllocatorCall, which is a CallEvent sub-class for operator new calls
within new-expressions, so that the number of arguments always matched
the number of parameters.
rdar://problem/44738501
Differential Revision: https://reviews.llvm.org/D52957
llvm-svn: 344539
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
This patch is a part of https://reviews.llvm.org/D48456 in an attempt to
split them up. This contains the code for casting between fixed point types
and other fixed point types.
The method for converting between fixed point types is based off the convert()
method in APFixedPoint.
Differential Revision: https://reviews.llvm.org/D50616
llvm-svn: 344530
Summary:
Enhanced support for Z3 in the cmake configuration of clang; now it is possible to specify any arbitrary Z3 install prefix (CLANG_ANALYZER_Z3_PREFIX) to cmake with lib (or bin) and include folders. Before the patch only in cmake default locations
were searched (https://cmake.org/cmake/help/v3.4/command/find_path.html).
Specifying any CLANG_ANALYZER_Z3_PREFIX will force also CLANG_ANALYZER_BUILD_Z3 to ON.
Removed also Z3 4.5 version requirement since it was not checked, and now Clang works with Z3 4.7
Reviewers: NoQ, george.karpenkov, mikhail.ramalho
Reviewed By: george.karpenkov
Subscribers: rnkovacs, NoQ, esteffin, george.karpenkov, delcypher, ddcc, mgorny, xazax.hun, szepet, a.sidorin, Szelethus
Tags: #clang
Differential Revision: https://reviews.llvm.org/D50818
llvm-svn: 344464
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
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
Doesn't do much despite sounding quite bad, but fixes an exotic test case where
liveness of a nonloc::LocAsInteger array index is now evaluated correctly.
Differential Revision: https://reviews.llvm.org/D52667
llvm-svn: 343631
I intend to add a new flag macro-expnasions-as-events, and unfortunately
I'll only be able to convert the macro piece into an event one once I'm
about to emit it, due to the lack of an avaible Preprocessor object in
the BugReporter.
Differential Revision: https://reviews.llvm.org/D52787
llvm-svn: 343620
Summary:
Several improvements in preparation for the new backends.
Refactoring:
- Removed duplicated methods `fromBoolean`, `fromAPSInt`, `fromInt` and `fromAPFloat`. The methods `mkBoolean`, `mkBitvector` and `mkFloat` are now used instead.
- The names of the functions that convert BVs to FPs were swapped (`mkSBVtoFP`, `mkUBVtoFP`, `mkFPtoSBV`, `mkFPtoUBV`).
- Added a couple of comments in function calls.
Crosscheck encoding:
- Changed how constraints are encoded in the refutation manager so it doesn't start with (false OR ...). This change introduces one duplicated line (see file `BugReporterVisitors.cpp`, the `SMTConv::getRangeExpr is called twice, so I can remove this change if the duplication is a problem.
Reviewers: george.karpenkov, NoQ
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin, Szelethus
Differential Revision: https://reviews.llvm.org/D52365
llvm-svn: 343581
This is patch is a preparation for the proposed inclusion of macro expansions in the plist output.
Differential Revision: https://reviews.llvm.org/D52735
llvm-svn: 343511
Dumping graphs instead of opening them is often very useful,
e.g. for transfer or converting to SVG.
Basic sanity check for generated exploded graphs.
Differential Revision: https://reviews.llvm.org/D52637
llvm-svn: 343352
Commit r340984 causes a crash when a pointer to a completely unrelated type
UnrelatedT (eg., opaque struct pattern) is being casted from base class BaseT to
derived class DerivedT, which results in an ill-formed region
Derived{SymRegion{$<UnrelatedT x>}, DerivedT}.
Differential Revision: https://reviews.llvm.org/D52189
llvm-svn: 343051
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
Combine the two constructor overrides into a single ArrayRef constructor
to allow easier brace initializations and simplify how the respective field
is used internally.
Differential Revision: https://reviews.llvm.org/D51390
llvm-svn: 343037
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
This patch is a band-aid. A proper solution would be too change
trackNullOrUndefValue to only try to dereference the pointer when it is
relevant to the problem.
Differential Revision: https://reviews.llvm.org/D52435
llvm-svn: 342920
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
If the non-sink report is generated at the exit node, it will be
suppressed by the current functionality in isInevitablySinking, as it
only checks the successors of the block, but not the block itself.
The bug shows up in RetainCountChecker checks.
Differential Revision: https://reviews.llvm.org/D52284
llvm-svn: 342766
Fixes a number of issues:
- Global variables are not used for communication
- Trait should be defined on a graph, not on a node
- Defining the trait on a graph allows us to use a correct allocator,
no longer crashing while printing trimmed graphs
Differential Revision: https://reviews.llvm.org/D52183
llvm-svn: 342413
Those are not created in the allocator.
Since they are created fairly rarely, a counter overhead should not
affect the memory consumption.
Differential Revision: https://reviews.llvm.org/D51827
llvm-svn: 342314
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
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
This patch adds support for the following operations in the iterator checkers: assign, clear, insert, insert_after, emplace, emplace_after, erase and erase_after. This affects mismatched iterator checks ("this" and parameter must match) and invalidation checks (according to the standard).
Differential Revision: https://reviews.llvm.org/D32904
llvm-svn: 341794
This patch adds support for the following operations in the iterator checkers: push_back, push_front, emplace_back, emplace_front, pop_back and pop_front. This affects iterator range checks (range is extended after push and emplace and reduced after pop operations) and invalidation checks (according to the standard).
Differential Revision: https://reviews.llvm.org/D32902
llvm-svn: 341793
Extension of the mismatched iterator checker for constructors taking range of first..last (first and last must be iterators of the same container) and also for comparisons of iterators of different containers (one does not compare iterators of different containers, since the set of iterators is partially ordered, there are no relations between iterators of different containers, except that they are always non-equal).
Differential Revision: https://reviews.llvm.org/D32860
llvm-svn: 341792
If a container is moved by its move assignment operator, according to the standard all their iterators except the past-end iterators remain valid but refer to the new container. This patch introduces support for this case in the iterator checkers.
Differential Revision: https://reviews.llvm.org/D32859
llvm-svn: 341791
New check added to the checker which checks whether iterator parameters of template functions typed by the same template parameter refer to the same container.
Differential Revision: https://reviews.llvm.org/D32845
llvm-svn: 341790
The "derived" symbols indicate children fields of a larger symbol.
As parents do not have pointers to their children, the garbage
collection algorithm the analyzer currently uses adds such symbols into
a "postponed" category, and then keeps running through the worklist
until the fixed point is reached.
The current patch rectifies that by instead using a helper map which
stores pointers from parents to children, so that no fixed point
calculation is necessary.
The current patch yields ~5% improvement in running time on sqlite.
Differential Revision: https://reviews.llvm.org/D51397
llvm-svn: 341722
A node is considered to be trivial if it only has one successor, one
predecessor, and a state equal to the predecessor.
Can drastically (> 2x) reduce the size of the generated exploded
graph.
Differential Revision: https://reviews.llvm.org/D51665
llvm-svn: 341616
Ubigraph project has been dead since about 2008, and to the best of my
knowledge, no one was using it.
Previously, I wasn't able to launch the existing binary at all.
Differential Revision: https://reviews.llvm.org/D51655
llvm-svn: 341601
Return value of dyn_cast_or_null should be checked before use.
Otherwise we may put a null pointer into the map as a key and eventually
crash in checkDeadSymbols.
Differential Revision: https://reviews.llvm.org/D51385
llvm-svn: 341092
Introduce a new MemRegion sub-class, CXXDerivedObjectRegion, which is
the opposite of CXXBaseObjectRegion, to represent such casts. Such region is
a bit weird because it is by design bigger than its super-region.
But it's not harmful when it is put on top of a SymbolicRegion
that has unknown extent anyway.
Offset computation for CXXDerivedObjectRegion and proper modeling of casts
still remains to be implemented.
Differential Revision: https://reviews.llvm.org/D51191
llvm-svn: 340984
Don't try to understand what's going on when there's a C++ method called eg.
CFRetain().
Refactor the checker a bit, to use more modern APIs.
Differential Revision: https://reviews.llvm.org/D50866
llvm-svn: 340982
The analyzer doesn't make use of them anyway and they seem to have
pretty weird AST from time to time, so let's just skip them for now.
Fixes a crash reported as pr37769.
Differential Revision: https://reviews.llvm.org/D50855
llvm-svn: 340977
By making sure the returned value from getKnownSVal is consistent with
the value used inside expression engine.
PR38427
Differential Revision: https://reviews.llvm.org/D51252
llvm-svn: 340965
We add check for invalidation of iterators. The only operation we handle here
is the (copy) assignment.
Differential Revision: https://reviews.llvm.org/D32747
llvm-svn: 340805
Summary:
With this patch, the SMT backend is almost completely detached from the CSA.
Unfortunate consequence is that we missed the `ConditionTruthVal` from the CSA and had to use `Optional<bool>`.
The Z3 solver implementation is still in the same file as the `Z3ConstraintManager`, in `lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp` though, but except for that, the SMT API can be moved to anywhere in the codebase.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin, Szelethus
Differential Revision: https://reviews.llvm.org/D50772
llvm-svn: 340534
Summary:
By making SMTConstraintManager a template and passing the SMT constraint type and expr, we can further move code from the Z3ConstraintManager class to the generic SMT constraint Manager.
Now, each SMT specific constraint manager only needs to implement the method `bool canReasonAbout(SVal X) const`.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: mgorny, xazax.hun, szepet, a.sidorin, Szelethus
Differential Revision: https://reviews.llvm.org/D50770
llvm-svn: 340533
Summary: There is no reason to have a base class for a context anymore as each SMT object carries a reference to the specific solver context.
Reviewers: NoQ, george.karpenkov, hiraditya
Reviewed By: hiraditya
Subscribers: hiraditya, xazax.hun, szepet, a.sidorin, Szelethus
Differential Revision: https://reviews.llvm.org/D50768
llvm-svn: 340532
Tracking those can help to provide much better diagnostics in many cases.
In general, most of the visitor machinery should be refactored to allow
tracking the origin of arbitrary values.
rdar://36039765
Differential Revision: https://reviews.llvm.org/D51131
llvm-svn: 340475
Summary:
`CallDecription` can only handle function for the time being. If we want to match c++ method, we can only use method name to match and can't improve the matching accuracy through the qualifiers.
This patch add the support for `QualifiedName` matching to improve the matching accuracy.
Reviewers: xazax.hun, NoQ, george.karpenkov, rnkovacs
Reviewed By: xazax.hun, NoQ, rnkovacs
Subscribers: Szelethus, szepet, rnkovacs, a.sidorin, mikhail.ramalho, cfe-commits, MTC
Differential Revision: https://reviews.llvm.org/D48027
llvm-svn: 340407
For the following example:
struct Base {
int x;
};
// In a different translation unit
struct Derived : public Base {
Derived() {}
};
For a call to Derived::Derived(), we'll receive a note that
this->x is uninitialized. Since x is not a direct field of Derived,
it could be a little confusing. This patch aims to fix this, as well
as the case when the derived object has a field that has the name as
an inherited uninitialized data member:
struct Base {
int x; // note: uninitialized field 'this->Base::x'
};
struct Derived : public Base {
int x = 5;
Derived() {}
};
Differential Revision: https://reviews.llvm.org/D50905
llvm-svn: 340272
Now that it has it's own file, it makes little sense for
isPointerOrReferenceUninit to be this large, so I moved
dereferencing to a separate function.
Differential Revision: https://reviews.llvm.org/D50509
llvm-svn: 340265
Turns out it can't be removed from the analyzer since it relies on CallEvent.
Moving to staticAnalyzer/core
Differential Revision: https://reviews.llvm.org/D51023
llvm-svn: 340247
Specifically, AttributedType now tracks a regular attr::Kind rather than
having its own parallel Kind enumeration, and AttributedTypeLoc now
holds an Attr* instead of holding an ad-hoc collection of Attr fields.
Differential Revision: https://reviews.llvm.org/D50526
This reinstates r339623, reverted in r339638, with a fix to not fail
template instantiation if we instantiate a QualType with no associated
type source information and we encounter an AttributedType.
llvm-svn: 340215
ARCMigrator is using code from RetainCountChecker, which is a layering
violation (and it also does it badly, by using a different header, and
then relying on implementation being present in a header file).
This change splits up RetainSummaryManager into a separate library in
lib/Analysis, which can be used independently of a checker.
Differential Revision: https://reviews.llvm.org/D50934
llvm-svn: 340114
A lot of code in RetainCountChecker deals with GC mode.
Given that GC mode is deprecated, Apple does not ship runtime for it,
and modern compiler toolchain does not support it, it makes sense to
remove the code dealing with it in order to aid understanding of
RetainCountChecker.
Differential Revision: https://reviews.llvm.org/D50747
llvm-svn: 340091
Once CFG-side support for argument construction contexts landed in r338436,
the analyzer could make use of them to evaluate argument constructors properly.
When evaluated as calls, constructors of arguments now use the variable region
of the parameter as their target. The corresponding stack frame does not yet
exist when the parameter is constructed, and this stack frame is created
eagerly.
Construction of functions whose body is unavailable and of virtual functions
is not yet supported. Part of the reason is the analyzer doesn't consistently
use canonical declarations o identify the function in these cases, and every
re-declaration or potential override comes with its own set of parameter
declarations. Also it is less important because if the function is not
inlined, there's usually no benefit in inlining the argument constructor.
Differential Revision: https://reviews.llvm.org/D49443
llvm-svn: 339745
- 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: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Differential Revision: https://reviews.llvm.org/D49722
llvm-svn: 339641
This breaks compiling atlwin.h in Chromium. I'm sure the code is invalid
in some way, but we put a lot of work into accepting it, and I'm sure
rejecting it was not an intended consequence of this refactoring. :)
llvm-svn: 339638
Specifically, AttributedType now tracks a regular attr::Kind rather than
having its own parallel Kind enumeration, and AttributedTypeLoc now
holds an Attr* instead of holding an ad-hoc collection of Attr fields.
Differential Revision: https://reviews.llvm.org/D50526
llvm-svn: 339623
Before this patch, FieldChainInfo used a spaghetti: it took care of way too many cases,
even though it was always meant as a lightweight wrapper around
ImmutableList<const FieldRegion *>.
This problem is solved by introducing a lightweight polymorphic wrapper around const
FieldRegion *, FieldNode. It is an interface that abstracts away special cases like
pointers/references, objects that need to be casted to another type for a proper note
messages.
Changes to FieldChainInfo:
* Now wraps ImmutableList<const FieldNode &>.
* Any pointer/reference related fields and methods were removed
* Got a new add method. This replaces it's former constructors as a way to create a
new FieldChainInfo objects with a new element.
Changes to FindUninitializedField:
* In order not to deal with dynamic memory management, when an uninitialized field is
found, the note message for it is constructed and is stored instead of a
FieldChainInfo object. (see doc around addFieldToUninits).
Some of the test files are changed too, from now on uninitialized pointees of references
always print "uninitialized pointee" instead of "uninitialized field" (which should've
really been like this from the beginning).
I also updated every comment according to these changes.
Differential Revision: https://reviews.llvm.org/D50506
llvm-svn: 339599
In this patch, the following classes and functions have been moved to a header file:
FieldChainInfo
FindUninitializedFields
isPrimitiveType
This also meant that they moved from anonymous namespace to clang::ento.
Code related to pointer chasing now relies in its own file.
There's absolutely no functional change in this patch -- its literally just copy pasting.
Differential Revision: https://reviews.llvm.org/D50504
llvm-svn: 339595
This patch is the first part of a series of patches to refactor UninitializedObjectChecker. The goal of this effort is to
Separate pointer chasing from the rest of the checker,
Increase readability and reliability,
Don't impact performance (too bad).
In this one, ImmutableList's factory is moved to FindUninitializedFields.
Differential Revision: https://reviews.llvm.org/D50503
llvm-svn: 339591
If we get an item from a dictionary, we know that the item is non-null
if and only if the key is non-null.
This patch is a rather hacky way to record this implication, because
some logic needs to be duplicated from the solver.
And yet, it's pretty simple, performant, and works.
Other possible approaches:
- Record the implication, in future rely on Z3 to pick it up.
- Generalize the current code and move it to the constraint manager.
rdar://34990742
Differential Revision: https://reviews.llvm.org/D50124
llvm-svn: 339482
Lambdas can affect static locals even without an explicit capture.
rdar://39537031
Differential Revision: https://reviews.llvm.org/D50368
llvm-svn: 339459
This patch fixed an issue where the dynamic type of pointer/reference
object was known by the analyzer, but wasn't obtained in the checker,
which resulted in false negatives. This should also increase reliability
of the checker, as derefencing is always done now according to the
dynamic type (even if that happens to be the same as the static type).
Special thanks to Artem Degrachev for setting me on the right track.
Differential Revision: https://reviews.llvm.org/D49199
llvm-svn: 339240
As of now, all constructor calls are ignored that are being called
by a constructor. The point of this was not to analyze the fields
of an object, so an uninitialized field wouldn't be reported
multiple times.
This however introduced false negatives when the two constructors
were in no relation to one another -- see the test file for a neat
example for this with singletons. This patch aims so fix this issue.
Differential Revision: https://reviews.llvm.org/D48436
llvm-svn: 339237
Summary:
The loop-widening code processes c++ methods looking for `this` pointers. In
the case of static methods (which do not have `this` pointers), an assertion
was triggering. This patch avoids trying to process `this` pointers for
static methods, and thus avoids triggering the assertion .
Reviewers: dcoughlin, george.karpenkov, NoQ
Reviewed By: NoQ
Subscribers: NoQ, xazax.hun, szepet, a.sidorin, mikhail.ramalho, cfe-commits
Differential Revision: https://reviews.llvm.org/D50408
llvm-svn: 339201
Even for a checker being in alpha, some reports about pointees held so little
value to the user that it's safer to disable pointer/reference chasing for now.
It can be enabled with a new flag, in which case checker should function as it
has always been. This can be set with `CheckPointeeInitialization`.
Differential Revision: https://reviews.llvm.org/D49438
llvm-svn: 339135
Some checkers require ASTContext. Having it in the constructor saves a
lot of boilerplate of having to pass it around.
Differential Revision: https://reviews.llvm.org/D50111
llvm-svn: 339079
For InnerPointerChecker to function properly, both the checker itself
and parts of MallocChecker that handle relevant use-after-free problems
need to be turned on. So far, the latter part has been developed within
MallocChecker's NewDelete sub-checker, often causing warnings to appear
under that name. This patch defines a new CheckKind within MallocChecker
for the inner pointer checking functionality, so that the correct name
is displayed in warnings and in the ExplodedGraph.
Tested on clang-tidy.
Differential Review: https://reviews.llvm.org/D50211
llvm-svn: 339067
Objects local to a function are destroyed right after the statement returning
(part of) them is executed in the analyzer. This patch enables MallocChecker to
warn in these cases.
Differential Revision: https://reviews.llvm.org/D49361
llvm-svn: 338780
The CoreEngine only gives us a ReturnStmt if the last element in the
CFGBlock is a CFGStmt, otherwise the ReturnStmt is nullptr.
This patch adds support for the case when the last element is a
CFGAutomaticObjDtor, by returning its TriggerStmt as a ReturnStmt.
Differential Revision: https://reviews.llvm.org/D49811
llvm-svn: 338777
Newly added methods allow reasoning about the stack frame of the call (as
opposed to the stack frame on which the call was made, which was always
available) - obtain the stack frame context, obtain parameter regions - even if
the call is not going to be (or was not) inlined, i.e. even if the analysis
has never actually entered the stack frame.
Differential Revision: https://reviews.llvm.org/D49715
llvm-svn: 338474
Because of incomplete support for CXXDefaultArgExpr, we cannot yet commit to
asserting that the same destructor won't be elided twice.
Suppress the assertion failure for now. Proper support is still an open problem.
Differential Revision: https://reviews.llvm.org/D49213
llvm-svn: 338441
This is a refactoring patch; no functional change intended.
The common part of ConstructionContextLayer and ConstructedObjectKey is
factored out into a new structure, ConstructionContextItem.
Various sub-kinds of ConstructionContextItem are enumerated in order to
provide richer information about construction contexts.
Differential Revision: https://reviews.llvm.org/D49210.
llvm-svn: 338439
In r330377 and r338425 we have already identified what constitutes function
argument constructors and added stubs in order to prevent confusing them
with other temporary object constructors.
Now we implement a ConstructionContext sub-class to carry all the necessary
information about the construction site, namely call expression and argument
index.
On the analyzer side, the patch interacts with the recently implemented
pre-C++17 copy elision support in an interesting manner. If on the CFG side we
didn't find a construction context for the elidable constructor, we build
the CFG as if the elidable constructor is not elided, and the non-elided
constructor within it is a simple temporary. But the same problem may occur
in the analyzer: if the elidable constructor has a construction context but
the analyzer doesn't implement such context yet, the analyzer should also
try to skip copy elision and still inline the non-elided temporary constructor.
This was implemented by adding a "roll back" mechanism: when elision fails,
roll back the changes and proceed as if it's a simple temporary. The approach
is wonky, but i'm fine with that as long as it's merely a defensive mechanism
that should eventually go away once all construction contexts become supported.
Differential Revision: https://reviews.llvm.org/D48681.
llvm-svn: 338436
This fix is similar to r337769 and addresses a regression caused by r337167.
When an operation between a nonloc::LocAsInteger and a non-pointer symbol
is performed, the LocAsInteger-specific part of information is lost.
When the non-pointer symbol is collapsing into a constant, we cannot easily
re-evaluate the result, because we need to recover the missing
LocAsInteger-specific information (eg., integer type, or the very fact that
this pointer was at some point converted to an integer).
Add one more defensive check to prevent crashes on trying to simplify a
SymSymExpr with different Loc-ness of operands.
Differential Revision:
llvm-svn: 338420
When emitting a bug report, it is important to highlight which argument of the
call-expression is causing the problem.
Before:
warning: Null pointer argument in call to string comparison function
strcmp(a, b);
^~~~~~~~~~~~
After:
warning: Null pointer argument in call to string comparison function
strcmp(a, b);
^ ~
Affects other output modes as well, not just text.
Differential Revision: https://reviews.llvm.org/D50028
llvm-svn: 338333
Do not warn when the other message-send-expression is correctly wrapped
in a different autorelease pool.
Differential Revision: https://reviews.llvm.org/D49921
llvm-svn: 338314
After cleaning up program state maps in `checkDeadSymbols()`,
a transition should be added to generate the new state.
Differential Revision: https://reviews.llvm.org/D47417
llvm-svn: 338263
According to the standard, pointers referring to the elements of a
`basic_string` may be invalidated if they are used as an argument to
any standard library function taking a reference to non-const
`basic_string` as an argument. This patch makes InnerPointerChecker warn
for these cases.
Differential Revision: https://reviews.llvm.org/D49656
llvm-svn: 338259
The analyzer may consider a container region as dead while it still has live
iterators. We must defer deletion of the data belonging to such containers
until all its iterators are dead as well to be able to compare the iterator
to the begin and the end of the container which is stored in the container
data.
Differential Revision: https://reviews.llvm.org/D48427
llvm-svn: 338234
The note is added in the following situation:
- We are throwing a nullability-related warning on an IVar
- The path goes through a method which *could have* (syntactically
determined) written into that IVar, but did not
rdar://42444460
Differential Revision: https://reviews.llvm.org/D49689
llvm-svn: 338149
Summary:
This patch replaces the current method of getting an `APSInt` from Z3's model by calling generic API method `getBitvector` instead of `Z3_get_numeral_uint64`.
By calling `getBitvector`, there's no need to handle bitvectors with bit width == 128 separately.
And, as a bonus, clang now compiles correctly with Z3 4.7.1.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49818
llvm-svn: 338020
Summary:
Update the documentation of all the classes introduced with the new generic SMT API, most of them were referencing Z3 and how previous operations were being done (like including the context as parameter in a few methods).
Renamed the following methods, so it's clear that the operate on bitvectors:
*`mkSignExt` -> `mkBVSignExt`
*`mkZeroExt` -> `mkBVZeroExt`
*`mkExtract` -> `mkBVExtract`
*`mkConcat` -> `mkBVConcat`
Removed the unecessary methods:
* `getDataExpr`: it was an one line method that called `fromData`
* `mkBitvector(const llvm::APSInt Int)`: it was not being used anywhere
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49799
llvm-svn: 337954
Summary:
The macro was manually expanded in the Z3 backend and this patch adds it back.
Adding the expanded code is dangerous as the macro may change in the future and the expanded code might be left outdated.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49769
llvm-svn: 337923
Summary:
Third patch in the refactoring series, to decouple the SMT Solver from the Refutation Manager (1st: D49668, 2nd: D49767).
The refutation API in the `SMTConstraintManager` was a hack to allow us to create an SMT solver and verify the constraints; it was conceptually wrong from the start. Now, we don't actually need to use the `SMTConstraintManager` and can create an SMT object directly, add the constraints and check them.
While updating the Falsification visitor, I inlined the two functions that were used to collect the constraints and add them to the solver.
As a result of this patch, we could move the SMT API elsewhere and as it's not really dependent on the CSA anymore. Maybe we can create a new dir (utils/smt) for Z3 and future solvers?
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49768
llvm-svn: 337922
Summary:
This is the second part of D49668, and moves all the code that's not specific to a ConstraintManager to SMTSolver.
No functional change intended.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49767
llvm-svn: 337921
George Karpenkov