Summary: Clang does not have a corresponding QualType for a 1-bit APSInt, so use the BoolTy and extend the APSInt. Split from D35450. Fixes PR37622.
Reviewers: george.karpenkov, NoQ
Subscribers: mikhail.ramalho, xazax.hun, szepet, rnkovacs, cfe-commits, a.sidorin
Differential Revision: https://reviews.llvm.org/D47603
llvm-svn: 333704
Memoize simplification so that we didn't need to simplify the same symbolic
expression twice within the same program state.
Gives ~25% performance boost on the artificial test in test/Analysis/hangs.c.
Differential Revision: https://reviews.llvm.org/D47402
llvm-svn: 333671
When neither LHS nor RHS of a binary operator expression can be simplified,
return the original expression instead of re-evaluating the binary operator.
Such re-evaluation was causing recusrive re-simplification which caused
the algorithmic complexity to explode.
Differential Revision: https://reviews.llvm.org/D47155
llvm-svn: 333670
Previously, the checker was using the nullability of the expression,
which is nonnull IFF both receiver and method are annotated as _Nonnull.
However, the receiver could be known to the analyzer to be nonnull
without being explicitly marked as _Nonnull.
rdar://40635584
Differential Revision: https://reviews.llvm.org/D47510
llvm-svn: 333612
Summary: Since the `addTransitionImpl()` has a check about same state transition, there is no need to check it in `ArrayBoundCheckerV2.cpp`.
Reviewers: NoQ, xazax.hun, george.karpenkov
Reviewed By: NoQ
Subscribers: szepet, rnkovacs, a.sidorin, cfe-commits, MTC
Differential Revision: https://reviews.llvm.org/D47451
llvm-svn: 333531
Summary: If the access is out of bounds, return UndefinedVal. If it is missing an explicit init, return the implicit zero value it must have.
Reviewers: NoQ, xazax.hun, george.karpenkov
Reviewed By: NoQ
Subscribers: szepet, rnkovacs, a.sidorin, cfe-commits
Differential Revision: https://reviews.llvm.org/D46823
llvm-svn: 333417
These functions are obsolete. The analyzer would advice to replace them with
memcmp(), memcpy() or memmove(), or memset().
Patch by Tom Rix!
Differential Revision: https://reviews.llvm.org/D41881
llvm-svn: 333326
Because template parameter lists were not displayed
in the plist output, it was difficult to decide in
some cases whether a given checker found a true or a
false positive. This patch aims to correct this.
Differential Revision: https://reviews.llvm.org/D46933
llvm-svn: 333275
Summary: I could also move `RangedConstraintManager.h` under `include/` if you agree as it seems slightly out of place under `lib/`.
Patch by Réka Kovács
Reviewers: NoQ, george.karpenkov, dcoughlin, rnkovacs
Reviewed By: NoQ
Subscribers: mikhail.ramalho, whisperity, xazax.hun, baloghadamsoftware, szepet, a.sidorin, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D45920
llvm-svn: 333179
Again, strlc* does not return a pointer so the zero size case doest not fit.
Reviewers: NoQ, george.karpenkov
Reviewed by: NoQ
Differential Revision: https://reviews.llvm.org/D47007
llvm-svn: 333060
Since there is no perfect way bind the non-zero value with the default binding, this patch only considers the case where buffer's offset is zero and the char value is 0. And according to the value for overwriting, decide how to update the string length.
Reviewers: dcoughlin, NoQ, xazax.hun, a.sidorin, george.karpenkov
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D44934
llvm-svn: 332463
Previously plist-html output produced multi-file HTML reports
but only single-file Plist reports.
Change plist-html output to produce multi-file Plist reports as well.
Differential Revision: https://reviews.llvm.org/D46902
llvm-svn: 332417
The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM
Explicitly avoided changing the strings in the clang-format tests.
Differential Revision: https://reviews.llvm.org/D44975
llvm-svn: 332350
A common pattern is that the code in the block does not write into the
variable explicitly, but instead passes it to a helper function which
performs the write.
Differential Revision: https://reviews.llvm.org/D46772
llvm-svn: 332300
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
llvm-svn: 331834
We weren't invalidating our unions correctly. The previous behavior in
invalidateRegionsWorker::VisitCluster() was to direct-bind an UnknownVal
to the union (at offset 0).
For that reason we were never actually loading default bindings from our unions,
because there never was any default binding to load, and the value
that is presumed when there's no default binding to load
is usually completely incorrect (eg. UndefinedVal for stack unions).
The new behavior is to default-bind a conjured symbol (of irrelevant type)
to the union that's being invalidated, similarly to what we do for structures
and classes. Then it becomes safe to load the value properly.
Differential Revision: https://reviews.llvm.org/D45241
llvm-svn: 331563
C allows us to write any bytes into any memory region. When loading weird bytes
from memory regions of known types, the analyzer is required to make sure that
the loaded value makes sense by casting it to an appropriate type.
Fix such cast for loading values that represent void pointers from non-void
pointer type places.
Differential Revision: https://reviews.llvm.org/D46415
llvm-svn: 331562
The bindDefault() API of the ProgramState allows setting a default value
for reads from memory regions that were not preceded by writes.
It was used for implementing C++ zeroing constructors (i.e. default constructors
that boil down to setting all fields of the object to 0).
Because differences between zeroing consturctors and other forms of default
initialization have been piling up (in particular, zeroing constructors can be
called multiple times over the same object, probably even at the same offset,
requiring a careful and potentially slow cleanup of previous bindings in the
RegionStore), we split the API in two: bindDefaultInitial() for modeling
initial values and bindDefaultZero() for modeling zeroing constructors.
This fixes a few assertion failures from which the investigation originated.
The imperfect protection from both inability of the RegionStore to support
binding extents and lack of information in ASTRecordLayout has been loosened
because it's, well, imperfect, and it is unclear if it fixing more than it
was breaking.
Differential Revision: https://reviews.llvm.org/D46368
llvm-svn: 331561
Many glvalue expressions aren't of their respective reference type -
they are simply glvalues of their value type.
This was causing problems when we were trying to obtain type of the original
expression while evaluating certain glvalue bit-casts.
Fixed by artificially forging a reference type to provide to the casting
procedure.
Differential Revision: https://reviews.llvm.org/D46224
llvm-svn: 331558
When loading from a variable or a field that is declared as constant,
the analyzer will try to inspect its initializer and constant-fold it.
Upon success, the analyzer would skip normal load and return the respective
constant.
The new behavior also applies to fields/elements of brace-initialized structures
and arrays.
Patch by Rafael Stahl!
Differential Revision: https://reviews.llvm.org/D45774
llvm-svn: 331556
FunctionProtoType.
We previously re-evaluated the expression each time we wanted to know whether
the type is noexcept or not. We now evaluate the expression exactly once.
This is not quite "no functional change": it fixes a crasher bug during AST
deserialization where we would try to evaluate the noexcept specification in a
situation where we have not deserialized sufficient portions of the AST to
permit such evaluation.
llvm-svn: 331428
The return values of the newly supported functions were not handled correctly:
strlcpy()/strlcat() return string sizes rather than pointers.
Differential Revision: https://reviews.llvm.org/D45177
llvm-svn: 331401
Summary:
The filename is currently taken from the start of the path, while the
line and column are taken from the end of the path.
This didn't matter until cross-file path reporting was added.
Reviewers: george.karpenkov, dcoughlin, vlad.tsyrklevich
Reviewed By: george.karpenkov, vlad.tsyrklevich
Subscribers: xazax.hun, szepet, a.sidorin, cfe-commits
Differential Revision: https://reviews.llvm.org/D45611
llvm-svn: 331361
Summary: Add `TaintBugVisitor` to the ArrayBoundV2, DivideZero, VLASize to be able to indicate where the taint information originated from.
Reviewers: NoQ, george.karpenkov, xazax.hun, a.sidorin
Reviewed By: NoQ
Subscribers: szepet, rnkovacs, cfe-commits, MTC
Differential Revision: https://reviews.llvm.org/D46007
llvm-svn: 331345
When a '>>' token is split into two '>' tokens (in C++11 onwards), or (as an
extension) when we do the same for other tokens starting with a '>', we can't
just use a location pointing to the first '>' as the location of the split
token, because that would result in our miscomputing the length and spelling
for the token. As a consequence, for example, a refactoring replacing 'A<X>'
with something else would sometimes replace one character too many, and
similarly diagnostics highlighting a template-id source range would highlight
one character too many.
Fix this by creating an expansion range covering the first character of the
'>>' token, whose spelling is '>'. For this to work, we generalize the
expansion range of a macro FileID to be either a token range (the common case)
or a character range (used in this new case).
llvm-svn: 331155
Avoid crash when the sub-expression of operator delete[] is of array type.
This is not the same as simply using a delete[] syntax.
We're still not properly calling destructors in this case in the analyzer.
Differential Revision: https://reviews.llvm.org/D46146
llvm-svn: 331014
If 'A' is a C++ aggregate with a reference field of type 'C', in code like
A a = { C() };
C() is lifetime-extended by 'a'. The analyzer wasn't expecting this pattern and
crashing. Additionally, destructors aren't added in the CFG for this case,
so for now we shouldn't be inlining the constructor for C().
Differential Revision: https://reviews.llvm.org/D46037
llvm-svn: 330882
Normally the analyzer begins path-sensitive analysis from functions within
the main file, even though the path is allowed to go through any functions
within the translation unit.
When a recent version of WebKit is compiled, the "unified sources" technique
is used, that assumes #including multiple code files into a single main file.
Such file would have no functions defined in it, so the analyzer wouldn't be
able to find any entry points for path-sensitive analysis.
This patch pattern-matches unified file names that are similar to those
used by WebKit and allows the analyzer to find entry points in the included
code files. A more aggressive/generic approach is being planned as well.
Differential Revision: https://reviews.llvm.org/D45839
llvm-svn: 330876
Note diagnostic pieces are an additional way of highlighting code sections to
the user. They aren't part of the normal path diagnostic sequence. They can
also be attached to path-insensitive reports.
Notes are already supported by the text output and scan-build.
Expanding our machine-readable plist output format to be able to represent notes
opens up the possibility for various analyzer GUIs to pick them up.
Patch by Umann Kristóf!
Differential Revision: https://reviews.llvm.org/D45407
llvm-svn: 330766
Printing of ConcreteInts with size >64 bits resulted in assertion failure
in get[Z|S]ExtValue() because these methods are only allowed to be used
with integers of 64 max bit width. This patch fixes the issue.
llvm-svn: 330605
Summary: `TaintBugVisitor` is a universal visitor, and many checkers rely on it, such as `ArrayBoundCheckerV2.cpp`, `DivZeroChecker.cpp` and `VLASizeChecker.cpp`. Moving `TaintBugVisitor` to `BugReporterVisitors.h` enables other checker can also track where `tainted` value came from.
Reviewers: NoQ, george.karpenkov, xazax.hun
Reviewed By: george.karpenkov
Subscribers: szepet, rnkovacs, a.sidorin, cfe-commits, MTC
Differential Revision: https://reviews.llvm.org/D45682
llvm-svn: 330596
If a pointer cast fails (evaluates to an UnknownVal, i.e. not implemented in the
analyzer) and such cast is in fact the last use of the pointer, the pointer
symbol is no longer referenced by the program state and a leak is
(mis-)diagnosed.
"Escape" the pointer upon a failed cast, i.e. inform the checker that we can no
longer reliably track it.
Differential Revision: https://reviews.llvm.org/D45698
llvm-svn: 330380
r315736 added support for the misplaced CF_RETURNS_RETAINED annotation on
CFRetain() wrappers. It works by trusting the function's name (seeing if it
confirms to the CoreFoundation naming convention) rather than the annotation.
There are more false positives caused by users using a different naming
convention, namely starting the function name with "retain" or "release"
rather than suffixing it with "retain" or "release" respectively.
Because this isn't according to the naming convention, these functions
are usually inlined and the annotation is therefore ignored, which is correct.
But sometimes we run out of inlining stack depth and the function is
evaluated conservatively and then the annotation is trusted.
Add support for the "alternative" naming convention and test the situation when
we're running out of inlining stack depth.
rdar://problem/18270122
Differential Revision: https://reviews.llvm.org/D45117
llvm-svn: 330375
Summary:
Clean carriage returns from lib/ and include/. NFC.
(I have to make this change locally in order for `git diff` to show sane output after I edit a file, so I might as well ask for it to be committed. I don't have commit privs myself.)
(Without this patch, `git rebase`ing any change involving SemaDeclCXX.cpp is a real nightmare. :( So while I have no right to ask for this to be committed, geez would it make my workflow easier if it were.)
Here's the command I used to reformat things. (Requires bash and OSX/FreeBSD sed.)
git grep -l $'\r' lib include | xargs sed -i -e $'s/\r//'
find lib include -name '*-e' -delete
Reviewers: malcolm.parsons
Reviewed By: malcolm.parsons
Subscribers: emaste, krytarowski, cfe-commits
Differential Revision: https://reviews.llvm.org/D45591
Patch by Arthur O'Dwyer.
llvm-svn: 330112
Summary:
`this` pointer is not an l-value, although we have modeled `CXXThisRegion` for `this` pointer, we can only bind it once, which is when we start to inline method. And this patch fixes https://bugs.llvm.org/show_bug.cgi?id=35506.
In addition, I didn't find any other cases other than loop-widen that could invalidate `this` pointer.
Reviewers: NoQ, george.karpenkov, a.sidorin, seaneveson, szepet
Reviewed By: NoQ
Subscribers: xazax.hun, rnkovacs, cfe-commits, MTC
Differential Revision: https://reviews.llvm.org/D45491
llvm-svn: 330095
Expression rearrangement in SValBuilder (see rL329780) crashes with an assert if the type of the integer is different from the type of the symbol. This fix adds a check that prevents rearrangement in such cases.
Differential Revision: https://reviews.llvm.org/D45557
llvm-svn: 330064
Since the range-based constraint manager (default) is weak in handling comparisons where symbols are on both sides it is wise to rearrange them to have symbols only on the left side. Thus e.g. A + n >= B + m becomes A - B >= m - n which enables the constraint manager to store a range m - n .. MAX_VALUE for the symbolic expression A - B. This can be used later to check whether e.g. A + k == B + l can be true, which is also rearranged to A - B == l - k so the constraint manager can check whether l - k is in the range (thus greater than or equal to m - n).
The restriction in this version is the the rearrangement happens only if both the symbols and the concrete integers are within the range [min/4 .. max/4] where min and max are the minimal and maximal values of their type.
The rearrangement is not enabled by default. It has to be enabled by using -analyzer-config aggressive-relational-comparison-simplification=true.
Co-author of this patch is Artem Dergachev (NoQ).
Differential Revision: https://reviews.llvm.org/D41938
llvm-svn: 329780
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
removeUnneededCalls() is responsible for removing path diagnostic pieces within
functions that don't contain "interesting" events. It makes bug reports
much tidier.
When a stack frame is known to be interesting, the function doesn't descend
into it to prune anything within it, even other callees that are totally boring.
Fix the function to prune boring callees in interesting stack frames.
Differential Revision: https://reviews.llvm.org/D45117
llvm-svn: 329102
Summary:
The original implementation in the `LoopUnrolling.cpp` didn't consider the case where the counter is unsigned. This case is only handled in `simpleCondition()`, but this is not enough, we also need to deal with the unsinged counter with the counter initialization.
Since `IntegerLiteral` is `signed`, there is a `ImplicitCastExpr<IntegralCast>` in `unsigned counter = IntergerLiteral`. This patch add the `ignoringParenImpCasts()` in the `IntegerLiteral` matcher.
Reviewers: szepet, a.sidorin, NoQ, george.karpenkov
Reviewed By: szepet, george.karpenkov
Subscribers: xazax.hun, rnkovacs, cfe-commits, MTC
Differential Revision: https://reviews.llvm.org/D45086
llvm-svn: 328919
Achieves almost a 200% speedup on the example where the performance of
visitors was problematic.
Performance on sqlite3 is unaffected.
rdar://38818362
Differential Revision: https://reviews.llvm.org/D45113
llvm-svn: 328911
Pointer arithmetic on null or undefined pointers results in null or undefined
pointers. This is obvious for undefined pointers; for null pointers it follows
from our incorrect-but-somehow-working approach that declares that 0 (Loc)
doesn't necessarily represent a pointer of numeric address value 0, but instead
it represents any pointer that will cause a valid "null pointer dereference"
issue when dereferenced.
For now we've been seeing through pointer arithmetic at the original dereference
expression, i.e. in bugreporter::getDerefExpr(), but not during further
investigation of the value's origins in bugreporter::trackNullOrUndefValue().
The patch fixes it.
Differential Revision: https://reviews.llvm.org/D45071
llvm-svn: 328896
Not enough work has been done so far to ensure correctness of construction
contexts in the CFG when C++17 copy elision is in effect, so for now we
should drop construction contexts in the CFG and in the analyzer when
they seem different from what we support anyway.
This includes initializations with conditional operators and return values
across multiple stack frames.
Differential Revision: https://reviews.llvm.org/D44854
llvm-svn: 328893
r327219 added wrappers to std::sort which randomly shuffle the container before
sorting. This will help in uncovering non-determinism caused due to undefined
sorting order of objects having the same key.
To make use of that infrastructure we need to invoke llvm::sort instead of
std::sort.
llvm-svn: 328636
Extended the matched assignment operators when checking for bound changes in a body of the loop by using the freshly added isAssignmentOperator matcher.
This covers all the (current) possible assignments, tests added as well.
Differential Revision: https://reviews.llvm.org/D38921
llvm-svn: 328619
Changes the analyzer to believe that methods annotated with _Nonnull
from system frameworks indeed return non null objects.
Local methods with such annotation are still distrusted.
rdar://24291919
Differential Revision: https://reviews.llvm.org/D44341
llvm-svn: 328282
Current location is very confusing, especially because there is already
WorkList.h, and other code in CoreEngine.cpp is not related to work list
implementation.
Differential Revision: https://reviews.llvm.org/D44759
llvm-svn: 328280
When a temporary is constructed with a proper construction context, it should
be safe to inline the destructor. We have added suppressions for some of the
common false positives caused by such inlining, so there should be - and from my
observations there indeed is - more benefit than harm from enabling destructor
inlining.
Differential Revision: https://reviews.llvm.org/D44721
llvm-svn: 328258
CXXCtorInitializer-based constructors are also affected by the C++17 mandatory
copy elision, like variable constructors and return value constructors.
Extend r328248 to support those.
Differential Revision: https://reviews.llvm.org/D44763
llvm-svn: 328255
Function return values can be constructed directly in variables or passed
directly into return statements, without even an elidable copy in between.
This is how the C++17 mandatory copy elision AST behaves. The behavior we'll
have in such cases is the "old" behavior that we've had before we've
implemented destructor inlining and proper lifetime extension support.
Differential Revision: https://reviews.llvm.org/D44755
llvm-svn: 328253
In C++17 copy elision is mandatory for variable and return value constructors
(as long as it doesn't involve type conversion) which results in AST that does
not contain elidable constructors in their usual places. In order to provide
construction contexts in this scenario we need to cover more AST patterns.
This patch makes the CFG prepared for these scenarios by:
- Fork VariableConstructionContext and ReturnedValueConstructionContext into
two different sub-classes (each) one of which indicates the C++17 case and
contains a reference to an extra CXXBindTemporaryExpr.
- Allow CFGCXXRecordTypedCall element to accept VariableConstructionContext and
ReturnedValueConstructionContext as its context.
Differential Revision: https://reviews.llvm.org/D44597
llvm-svn: 328248
r326249 wasn't quite enough because we often run out of inlining stack depth
limit and for that reason fail to see the atomics we're looking for.
Add a more straightforward false positive suppression that is based on the name
of the class. I.e. if we're releasing a pointer in a destructor of a "something
shared/intrusive/reference/counting something ptr/pointer something", then any
use-after-free or double-free that occurs later would likely be a false
positive.
rdar://problem/38013606
Differential Revision: https://reviews.llvm.org/D44281
llvm-svn: 328066
When the loop has a null terminator statement and sets 'widen-loops=true', 'invalidateRegions' will constructs the 'SymbolConjured' with null 'Stmt'. And this will lead to a crash in 'IteratorChecker.cpp'. This patch use 'dyn_cast_or_null<>' instead of 'dyn_cast<>' in IteratorChecker.cpp.
Differential Revision: https://reviews.llvm.org/D44606
llvm-svn: 327962
Also use the opportunity to clean up the code and remove unnecessary duplication.
rdar://37625895
Differential Revision: https://reviews.llvm.org/D44594
llvm-svn: 327926
For other regions, the error message contains a good indication of the
problem, and there, in general, nothing helpful we can print.
Error pointer to the problematic expression seems enough.
rdar://37323555
Differential Revision: https://reviews.llvm.org/D44409
llvm-svn: 327727
My compiler (clang-3.8) complains that the RCC variable is unused.
That's not really true, as it's checked by the if-declaration, but it's
also kinda true, because we don't need to declaration if we only check
it in the if statement.
In reality, all this means that the dyn_cast<> can be replaced by isa<>,
so that's what I do here.
llvm-svn: 327491
Properly perform destruction and lifetime extension of such temporaries.
C++ object-type return values of conservatively evaluated functions are now
represented as compound values of well-defined temporary object regions. The
function creates a region that represents the temporary object and will later
be used for destruction or materialization, invalidates it, and returns the
invalidated compound value of the object.
Differential Revision: https://reviews.llvm.org/D44131
llvm-svn: 327348
This patch uses the newly added CFGCXXRecordTypedCall element at the call site
of the caller to construct the return value within the callee directly into the
caller's stack frame. This way it is also capable of populating the temporary
destructor and lifetime extension maps for the temporary, which allows
temporary destructors and lifetime extension to work correctly.
This patch does not affect temporaries that were returned from conservatively
evaluated functions.
Differential Revision: https://reviews.llvm.org/D44124
llvm-svn: 327345
This patch adds a new CFGStmt sub-class, CFGCXXRecordTypedCall, which replaces
the regular CFGStmt for the respective CallExpr whenever the CFG has additional
information to provide regarding the lifetime of the returned value.
This additional call site information is represented by a ConstructionContext
(which was previously used for CFGConstructor elements) that provides references
to CXXBindTemporaryExpr and MaterializeTemporaryExpr that surround the call.
This corresponds to the common C++ calling convention solution of providing
the target address for constructing the return value as an auxiliary implicit
argument during function call.
One of the use cases for such extra context at the call site would be to perform
any sort of inter-procedural analysis over the CFG that involves functions
returning objects by value. In this case the elidable constructor at the return
site would construct the object explained by the context at the call site, and
its lifetime would also be managed by the caller, not the callee.
The extra context would also be useful for properly handling the return-value
temporary at the call site, even if the callee is not being analyzed
inter-procedurally.
Differential Revision: https://reviews.llvm.org/D44120
llvm-svn: 327343
This patch adds two new CFG elements CFGScopeBegin and CFGScopeEnd that indicate
when a local scope begins and ends respectively. We use first VarDecl declared
in a scope to uniquely identify it and add CFGScopeBegin and CFGScopeEnd elements
into corresponding basic blocks.
Differential Revision: https://reviews.llvm.org/D16403
llvm-svn: 327258
mprotect() allows setting memory access flags similarly to mmap(),
causing similar security issues if these flags are needlessly broad.
Patch by David Carlier!
Differential Revision: https://reviews.llvm.org/D44250
llvm-svn: 327098
Previously, iteration through nil objects which resulted from
objc-messages being set to nil were modeled incorrectly.
There are a couple of notes about this patch:
In principle, ExprEngineObjC might be left untouched IFF osx.loops
checker is enabled.
I however think that we should not do something
completely incorrect depending on what checkers are left on.
We should evaluate and potentially remove altogether the isConsumedExpr
performance heuristic, as it seems very fragile.
rdar://22205149
Differential Revision: https://reviews.llvm.org/D44178
llvm-svn: 326982
Proper modeling still remains to be done.
Note that BindingDecl#getHoldingVar() is almost always null, and this
should probably be handled by dealing with DecompositionDecl beforehand.
rdar://36852163
Differential Revision: https://reviews.llvm.org/D44183
llvm-svn: 326951
Summary: `CheckBufferAccess()` calls `CheckNonNull()`, so there are some calls to `CheckNonNull()` that are useless.
Reviewers: dcoughlin, NoQ, xazax.hun, cfe-commits, george.karpenkov
Reviewed By: NoQ
Subscribers: szepet, rnkovacs, MTC, a.sidorin
Differential Revision: https://reviews.llvm.org/D44075
llvm-svn: 326782
Summary:
There is a problem with analyzer that a wrong value is given when modeling the increment operator of the operand with type bool. After `rL307604` is applied, a unsigned overflow may occur.
Example:
```
void func() {
bool b = true;
// unsigned overflow occur, 2 -> 0 U1b
b++;
}
```
The use of an operand of type bool with the ++ operators is deprecated but valid untill C++17. And if the operand of the increment operator is of type bool, it is set to true.
This patch includes two parts:
- If the operand of the increment operator is of type bool or type _Bool, set to true.
- Modify `BasicValueFactory::getTruthValue()`, use `getIntWidth()` instead `getTypeSize()` and use `unsigned` instead `signed`.
Reviewers: alexshap, NoQ, dcoughlin, george.karpenkov
Reviewed By: NoQ
Subscribers: xazax.hun, szepet, a.sidorin, cfe-commits, MTC
Differential Revision: https://reviews.llvm.org/D43741
llvm-svn: 326776
rdar://37312818
NB: The checker does not care about the ordering of callbacks, see the
relevant FIXME in tests.
Differential Revision: https://reviews.llvm.org/D44059
llvm-svn: 326746
Summary:
GenericTaintChecker can't recognize stdin in some cases. The reason is that `if (PtrTy->getPointeeType() == C.getASTContext().getFILEType()` does not hold when stdin is encountered.
My platform is ubuntu16.04 64bit, gcc 5.4.0, glibc 2.23. The definition of stdin is as follows:
```
__BEGIN_NAMESPACE_STD
/* The opaque type of streams. This is the definition used elsewhere. */
typedef struct _IO_FILE FILE;
___END_NAMESPACE_STD
...
/* The opaque type of streams. This is the definition used elsewhere. */
typedef struct _IO_FILE __FILE;
...
/* Standard streams. */
extern struct _IO_FILE *stdin; /* Standard input stream. */
extern struct _IO_FILE *stdout; /* Standard output stream. */
extern struct _IO_FILE *stderr; /* Standard error output stream. */
```
The type of stdin is as follows AST:
```
ElaboratedType 0xc911170'struct _IO_FILE'sugar
`-RecordType 0xc911150'struct _IO_FILE'
`-CXXRecord 0xc923ff0'_IO_FILE'
```
`C.getASTContext().GetFILEType()` is as follows AST:
```
TypedefType 0xc932710 'FILE' sugar
|-Typedef 0xc9111c0 'FILE'
`-ElaboratedType 0xc911170 'struct _IO_FILE' sugar
`-RecordType 0xc911150 'struct _IO_FILE'
`-CXXRecord 0xc923ff0 '_IO_FILE'
```
So I think it's better to use `getCanonicalType()`.
Reviewers: zaks.anna, NoQ, george.karpenkov, a.sidorin
Reviewed By: zaks.anna, a.sidorin
Subscribers: a.sidorin, cfe-commits, xazax.hun, szepet, MTC
Differential Revision: https://reviews.llvm.org/D39159
llvm-svn: 326709
```
if (NSNumber* x = ...)
```
is a reasonable pattern in objc++, we should not warn on it.
rdar://35152234
Differential Revision: https://reviews.llvm.org/D44044
llvm-svn: 326619
The patch fixes a number of bugs related to parameter indexing in
attributes:
* Parameter indices in some attributes (argument_with_type_tag,
pointer_with_type_tag, nonnull, ownership_takes, ownership_holds,
and ownership_returns) are specified in source as one-origin
including any C++ implicit this parameter, were stored as
zero-origin excluding any this parameter, and were erroneously
printing (-ast-print) and confusingly dumping (-ast-dump) as the
stored values.
* For alloc_size, the C++ implicit this parameter was not subtracted
correctly in Sema, leading to assert failures or to silent failures
of __builtin_object_size to compute a value.
* For argument_with_type_tag, pointer_with_type_tag, and
ownership_returns, the C++ implicit this parameter was not added
back to parameter indices in some diagnostics.
This patch fixes the above bugs and aims to prevent similar bugs in
the future by introducing careful mechanisms for handling parameter
indices in attributes. ParamIdx stores a parameter index and is
designed to hide the stored encoding while providing accessors that
require each use (such as printing) to make explicit the encoding that
is needed. Attribute declarations declare parameter index arguments
as [Variadic]ParamIdxArgument, which are exposed as ParamIdx[*]. This
patch rewrites all attribute arguments that are processed by
checkFunctionOrMethodParameterIndex in SemaDeclAttr.cpp to be declared
as [Variadic]ParamIdxArgument. The only exception is xray_log_args's
argument, which is encoded as a count not an index.
Differential Revision: https://reviews.llvm.org/D43248
llvm-svn: 326602
Don't enable c++-temp-dtor-inlining by default yet, due to this reference
counting pointe problem.
Otherwise the new mode seems stable and allows us to incrementally fix C++
problems in much less hacky ways.
Differential Revision: https://reviews.llvm.org/D43804
llvm-svn: 326461
Originally submitted as r326323 and r326324.
Reverted in r326432.
Reverting the commit was a mistake.
The breakage was due to invalid build files in our internal buildsystem,
CMakeLists did not have any cyclic dependencies.
llvm-svn: 326439
Also revert "[analyzer] Fix a compiler warning"
This reverts commits r326323 and r326324.
Reason: the commits introduced a cyclic dependency in the build graph.
This happens to work with cmake, but breaks out internal integrate.
llvm-svn: 326432
So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and
`dyn_cast`s for fun. This is a portion of what it found for clang; I
plan to do similar cleanups in LLVM and other subprojects when I find
time.
Because of the volume of changes, I explicitly avoided making any change
that wasn't highly local and obviously correct to me (e.g. we still have
a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading
is a thing and the cast<Bar> did actually change the type -- just up the
class hierarchy).
I also tried to leave the types we were cast<>ing to somewhere nearby,
in cases where it wasn't locally obvious what we were dealing with
before.
llvm-svn: 326416
This is a security check that warns when both PROT_WRITE and PROT_EXEC are
set during mmap(). If mmap()ed memory is both writable and executable, it makes
it easier for the attacker to execute arbitrary code when contents of this
memory are compromised. Some applications require such mmap()s though, such as
different sorts of JIT.
Re-applied after a revert in r324167.
Temporarily stays in the alpha package because it needs a better way of
determining macro values that are not immediately available in the AST.
Patch by David Carlier!
Differential Revision: https://reviews.llvm.org/D42645
llvm-svn: 326405
The aim of this patch is to be minimal to enable incremental development of
the feature on the top of the tree. This patch should be an NFC when the
feature is turned off. It is turned off by default and still considered as
experimental.
Technical details are available in the EuroLLVM Talk:
http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#7
Note that the initial prototype was done by A. Sidorin et al.: http://lists.llvm.org/pipermail/cfe-dev/2015-October/045730.html
Contributions to the measurements and the new version of the code: Peter Szecsi, Zoltan Gera, Daniel Krupp, Kareem Khazem.
Differential Revision: https://reviews.llvm.org/D30691
llvm-svn: 326323
When a class forgets to initialize a field in the constructor, and then gets
copied around, a warning is emitted that the value assigned to a specific field
is undefined.
When the copy/move constructor is implicit (not written out in the code) but not
trivial (is not a trivial memory copy, eg. because members have an explicit copy
constructor), the body of such constructor is auto-generated in the AST.
In this case the checker's warning message is squeezed at the top of
the class declaration, and it gets hard to guess which field is at fault.
Fix the warning message to include the name of the field.
Differential Revision: https://reviews.llvm.org/D43798
llvm-svn: 326258
Throw away MallocChecker warnings that occur after releasing a pointer within a
destructor (or its callees) after performing C11 atomic fetch_add or fetch_sub
within that destructor (or its callees).
This is an indication that the destructor's class is likely a
reference-counting pointer. The analyzer is not able to understand that the
original reference count is usually large enough to avoid most use-after-frees.
Even when the smart pointer is a local variable, we still have these false
positives that this patch suppresses, because the analyzer doesn't currently
support atomics well enough.
Differential Revision: https://reviews.llvm.org/D43791
llvm-svn: 326249
The SVal for any empty C++ object is an UnknownVal. Because RegionStore does
not have binding extents, binding an empty object to an UnknownVal may
potentially overwrite existing bindings at the same offset.
Therefore, when performing a trivial copy of an empty object, don't try to
take the value of the object and bind it to the copy. Doing nothing is accurate
enough, and it doesn't screw any existing bindings.
Differential Revision: https://reviews.llvm.org/D43714
llvm-svn: 326247
Sometimes it is not known at compile time which temporary objects will be
constructed, eg. 'x ? A() : B()' or 'C() || D()'. In this case we track which
temporary was constructed to know how to properly call the destructor.
Once the construction context for temporaries was introduced, we moved the
tracking code to the code that investigates the construction context.
Bring back the old mechanism because construction contexts are not always
available yet - eg. in the case where a temporary is constructed without a
constructor expression, eg. returned from a function by value. The mechanism
should still go away eventually.
Additionally, fix a bug in the temporary cleanup code for the case when
construction contexts are not available, which could lead to temporaries
staying in the program state and increasing memory consumption.
Differential Revision: https://reviews.llvm.org/D43666
llvm-svn: 326246
If a variable or an otherwise a concrete typed-value region is being
placement-new'ed into, its dynamic type may change in arbitrary manners. And
when the region is used, there may be a third type that's different from both
the static and the dynamic type. It cannot be *completely* different from the
dynamic type, but it may be a base class of the dynamic type - and in this case
there isn't (and shouldn't be) any indication anywhere in the AST that there is
a derived-to-base cast from the dynamic type to the third type.
Perform a generic cast (evalCast()) from the third type to the dynamic type
in this case. From the point of view of the SVal hierarchy, this would have
produced non-canonical SVals if we used such generic cast in the normal case,
but in this case there doesn't seem to be a better option.
Differential Revision: https://reviews.llvm.org/D43659
llvm-svn: 326245
Automatic destructors are missing in the CFG in situations like
const int &x = C().x;
For now it's better to disable construction inlining, because inlining
constructors while doing nothing on destructors is very bad.
Differential Revision: https://reviews.llvm.org/D43689
llvm-svn: 326240
ConstructionContext is moved into a separate translation unit and is separated
into multiple classes. The "old" "raw" ConstructionContext is renamed into
ConstructionContextLayer - which corresponds to the idea of building the context
gradually layer-by-layer, but it isn't easy to use in the clients. Once
CXXConstructExpr is reached, layers that we've gathered so far are transformed
into the actual, "new-style" "flat" ConstructionContext, which is put into the
CFGConstructor element and has no layers whatsoever (until it actually needs
them, eg. aggregate initialization). The new-style ConstructionContext is
instead presented as a variety of sub-classes that enumerate different ways of
constructing an object in C++. There are 5 of these supported for now,
which is around a half of what needs to be supported.
The layer-by-layer buildup process is still a little bit weird, but it hides
all the weirdness in one place, that sounds like a good thing.
Differential Revision: https://reviews.llvm.org/D43533
llvm-svn: 326238
This patch uses the reference to MaterializeTemporaryExpr stored in the
construction context since r326014 in order to model that expression correctly.
When modeling MaterializeTemporaryExpr, instead of copying the raw memory
contents from the sub-expression's rvalue to a completely new temporary region,
that we conjure up for the lack of better options, we now have the better
option to recall the region into which the object was originally constructed
and declare that region to be the value of the expression, which is semantically
correct.
This only works when the construction context is available, which is worked on
independently.
The temporary region's liveness (in the sense of removeDeadBindings) is extended
until the MaterializeTemporaryExpr is resolved, in order to keep the store
bindings around, because it wouldn't be referenced from anywhere else in the
program state.
Differential Revision: https://reviews.llvm.org/D43497
llvm-svn: 326236
Fixes https://bugs.llvm.org/show_bug.cgi?id=36474
In general, getSVal API should be changed so that it does not crash on
some non-obvious conditions.
It should either be updated to require a type, or to return Optional<SVal>.
Differential Revision: https://reviews.llvm.org/D43801
llvm-svn: 326233
See D42775 for discussion. Turns out, just exploring nodes which
weren't explored first is not quite enough, as e.g. the first quick
traversal resulting in a report can mark everything as "visited", and
then subsequent traversals of the same region will get all the pitfalls
of DFS.
Priority queue-based approach in comparison shows much greater
increase in coverage and even performance, without sacrificing memory.
Differential Revision: https://reviews.llvm.org/D43354
llvm-svn: 326136
Bison/YACC generated files result in a very large number of (presumably)
false positives from the analyzer.
These false positives are "true" in a sense of the information analyzer
sees: assuming that the lexer can return any token at any point a number
of uninitialized reads does occur.
(naturally, the analyzer can not capture a complex invariant that
certain tokens can only occur under certain conditions).
Current fix simply stops analysis on those files.
I have examined a very large number of such auto-generated files, and
they do all start with such a comment.
Conversely, user code is very unlikely to contain such a comment.
rdar://33608161
Differential Revision: https://reviews.llvm.org/D43421
llvm-svn: 326135
Addresses https://bugs.llvm.org/show_bug.cgi?id=36206
rdar://37159026
A proper fix would be much harder, and would involve changing the
appropriate code in ExprEngine to be aware of the size limitations of
the type used for addressing.
Differential Revision: https://reviews.llvm.org/D43218
llvm-svn: 326122
The assertion gets exposed when changing the exploration order.
This is a quick hacky fix, but the intention is that if the nodes do
merge, it should not matter which predecessor should be traverse.
A proper fix would be not to traverse predecessors at all, as all
information relevant for any decision should be avilable locally.
rdar://37540480
Differential Revision: https://reviews.llvm.org/D42773
llvm-svn: 325977
In the wild, many cases of null pointer dereference, or uninitialized
value read occur because the value was meant to be initialized by the
inlined function, but did not, most often due to error condition in the
inlined function.
This change highlights the return branch taken by the inlined function,
in order to help user understand the error report and see why the value
was uninitialized.
rdar://36287652
Differential Revision: https://reviews.llvm.org/D41848
llvm-svn: 325976
When viewing the report in the collapsed mode the label signifying where
did the execution go is often necessary for properly understanding the
context.
Differential Revision: https://reviews.llvm.org/D43145
llvm-svn: 325975
The checker marks the locations where the analyzer creates sinks. However, it
can happen that the sink was created because of a loop which does not contain
condition statement, only breaks in the body. The exhausted block is the block
which should contain the condition but empty, in this case.
This change only emits this marking in order to avoid the undefined behavior.
Differential Revision: https://reviews.llvm.org/D42266
llvm-svn: 325693
Array destructors, like constructors, need to be called for each element of the
array separately. We do not have any mechanisms to do this in the analyzer,
so for now all we do is evaluate a single constructor or destructor
conservatively and give up. It automatically causes the necessary invalidation
and pointer escape for the whole array, because this is how RegionStore works.
Implement this conservative behavior for temporary destructors. This fixes the
crash on the provided test.
Differential Revision: https://reviews.llvm.org/D43149
llvm-svn: 325286
Temporary destructors fire at the end of the full-expression. It is reasonable
to attach the path note for entering/leaving the temporary destructor to its
CXXBindTemporaryExpr. This would not affect lifetime-extended temporaries with
their automatic destructors which aren't temporary destructors.
The path note may be confusing in the case of destructors after elidable copy
constructors.
Differential Revision: https://reviews.llvm.org/D43144
llvm-svn: 325284
Inline them if possible - a separate flag is added to control this.
The whole thing is under the cfg-temporary-dtors flag, off by default so far.
Temporary destructors are called at the end of full-expression. If the
temporary is lifetime-extended, automatic destructors kick in instead,
which are not addressed in this patch, and normally already work well
modulo the overally broken support for lifetime extension.
The patch operates by attaching the this-region to the CXXBindTemporaryExpr in
the program state, and then recalling it during destruction that was triggered
by that CXXBindTemporaryExpr. It has become possible because
CXXBindTemporaryExpr is part of the construction context since r325210.
Differential revision: https://reviews.llvm.org/D43104
llvm-svn: 325282
Don't look at the parent statement to figure out if the cxx-allocator-inlining
flag should kick in and prevent us from inlining the constructor within
a new-expression. We now have construction contexts for that purpose.
llvm-svn: 325278
Since r325210, in cfg-temporary-dtors mode, we can rely on the CFG to tell us
that we're indeed constructing a temporary, so we can trivially construct a
temporary region and inline the constructor.
Much like r325202, this is only done under the off-by-default
cfg-temporary-dtors flag because the temporary destructor, even if available,
will not be inlined and won't have the correct object value (target region).
Unless this is fixed, it is quite unsafe to inline the constructor.
If the temporary is lifetime-extended, the destructor would be an automatic
destructor, which would be evaluated with a "correct" target region - modulo
the series of incorrect relocations performed during the lifetime extension.
It means that at least, values within the object are guaranteed to be properly
escaped or invalidated.
Differential Revision: https://reviews.llvm.org/D43062
llvm-svn: 325211
EvalCallOptions were introduced in r324018 for allowing various parts of
ExprEngine to notify the inlining mechanism, while preparing for evaluating a
function call, of possible difficulties with evaluating the call that they
foresee. Then mayInlineCall() would still be a single place for making the
decision.
Use that mechanism for destructors as well - pass the necessary flags from the
CFG-element-specific destructor handlers.
Part of this patch accidentally leaked into r324018, which led into a change in
tests; this change is reverted now, because even though the change looked
correct, the underlying behavior wasn't. Both of these commits were not intended
to introduce any function changes otherwise.
Differential Revision: https://reviews.llvm.org/D42991
llvm-svn: 325209
This only affects the cfg-temporary-dtors mode - in this mode we begin inlining
constructors that are constructing function return values. These constructors
have a correct construction context since r324952.
Because temporary destructors are not only never inlined, but also don't have
the correct target region yet, this change is not entirely safe. But this
will be fixed in the subsequent commits, while this stays off behind the
cfg-temporary-dtors flag.
Lifetime extension for return values is still not modeled correctly.
Differential Revision: https://reviews.llvm.org/D42875
llvm-svn: 325202
In CFG, every DeclStmt has exactly one decl, which is always a variable.
It is also pointless to check that the initializer is the constructor because
that's how construction contexts work now.
llvm-svn: 325201
See reviews.llvm.org/M1 for evaluation, and
lists.llvm.org/pipermail/cfe-dev/2018-January/056718.html for
discussion.
Differential Revision: https://reviews.llvm.org/D42775
llvm-svn: 324956
Massive false positives were known to be caused by continuing the analysis
after a destructor with a noreturn attribute has been executed in the program
but not modeled in the analyzer due to being missing in the CFG.
Now that work is being done on enabling the modeling of temporary constructors
and destructors in the CFG, we need to make sure that the heuristic that
suppresses these false positives keeps working when such modeling is disabled.
In particular, different code paths open up when the corresponding constructor
is being inlined during analysis.
Differential Revision: https://reviews.llvm.org/D42779
llvm-svn: 324802
The analyzer was relying on peeking the next CFG element during analysis
whenever it was trying to figure out what object is being constructed
by a given constructor. This information is now available in the current CFG
element in all cases that were previously supported by the analyzer,
so no complicated lookahead is necessary anymore.
No functional change intended - the context in the CFG should for now be
available if and only if it was previously discoverable via CFG lookahead.
Differential Revision: https://reviews.llvm.org/D42721
llvm-svn: 324800
This expression may or may not be evaluated in compile time, so tracking the
result symbol is of potential interest. However, run-time offsetof is not yet
supported by the analyzer, so for now this callback is only there to assist
future implementation.
Patch by Henry Wong!
Differential Revision: https://reviews.llvm.org/D42300
llvm-svn: 324790
This builtin is evaluated in compile time. But in the analyzer we don't yet
automagically evaluate all calls that can be evaluated in compile time.
Patch by Felix Kostenzer!
Differential Revision: https://reviews.llvm.org/D42745
llvm-svn: 324789
Even though most of the inconsistencies in MallocChecker's bug categories were
fixed in r302016, one more was introduced in r301913 which was later missed.
Patch by Henry Wong!
Differential Revision: https://reviews.llvm.org/D43074
llvm-svn: 324680
This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces
the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional
information to provide regarding what sort of object is being constructed.
It is useful for figuring out what memory is initialized in client of the
CFG such as the Static Analyzer, which do not operate by recursive AST
traversal, but instead rely on the CFG to provide all the information when they
need it. Otherwise, the statement that triggers the construction and defines
what memory is being initialized would normally occur after the
construct-expression, and the client would need to peek to the next CFG element
or use statement parent map to understand the necessary facts about
the construct-expression.
As a proof of concept, CFGConstructors are added for new-expressions
and the respective test cases are provided to demonstrate how it works.
For now, the only additional data contained in the CFGConstructor element is
the "trigger statement", such as new-expression, which is the parent of the
constructor. It will be significantly expanded in later commits. The additional
data is organized as an auxiliary structure - the "construction context",
which is allocated separately from the CFGElement.
Differential Revision: https://reviews.llvm.org/D42672
llvm-svn: 324668
It makes it easier to discriminate between values of similar expressions
in different stack frames.
It also makes the separate backtrace section in ExplodedGraph dumps redundant.
Differential Revision: https://reviews.llvm.org/D42552
llvm-svn: 324660
Due to Buildbot failures - most likely that's because target triples were not
specified in the tests, even though the checker behaves differently with
different target triples.
llvm-svn: 324167
This is a security check which is disabled by default but will be enabled
whenever the user consciously enables the security package. If mmap()ed memory
is both writable and executable, it makes it easier for the attacker to execute
arbitrary code when contents of this memory are compromised. Some applications
require such mmap()s though, such as different sorts of JIT.
Patch by David Carlier!
Differential Revision: https://reviews.llvm.org/D42645
llvm-svn: 324166
We already suppress such reports for inlined functions, we should then
get the same behavior for macros.
The underlying reason is that the same macro, can be called from many
different contexts, and nullability can only be expected in _some_ of
them.
Assuming that the macro can return null in _all_ of them sometimes leads
to a large number of false positives.
E.g. consider the test case for the dynamic cast implementation in
macro: in such cases, the bug report is unwanted.
Tracked in rdar://36304776
Differential Revision: https://reviews.llvm.org/D42404
llvm-svn: 324161
No in-tree checkers use this callback so far, hence no tests. But better fix
this now than remember to fix this when the checkers actually appear.
Patch by Henry Wong!
Differential Revision: https://reviews.llvm.org/D42785
llvm-svn: 324053
If the return statement is stored, we might as well allow querying
against it.
Also fix the bug where the return statement is not stored
if there is no return value.
This change un-merges two ExplodedNodes during call exit when the state
is otherwise identical - the CallExitBegin node itself and the "Bind
Return Value"-tagged node.
And expose the return statement through
getStatement helper function.
Differential Revision: https://reviews.llvm.org/D42130
llvm-svn: 324052
We use CXXTempObjectRegion exclusively as a bailout value for construction
targets when we are unable to find the correct construction region.
Sometimes it works correctly, but rather accidentally than intentionally.
Now that we want to increase the amount of situations where it works correctly,
the first step is to introduce a different way of communicating our failure
to find the correct construction region. EvalCallOptions are introduced
for this purpose.
For now EvalCallOptions are communicating two kinds of problems:
- We have been completely unable to find the correct construction site.
- We have found the construction site correctly, and there's more than one of
them (i.e. array construction which we currently don't support).
Accidentally find and fix a test in which the new approach to communicating
failures produces better results.
Differential Revision: https://reviews.llvm.org/D42457
llvm-svn: 324018
Do not attempt to get the pointee of void* while generating a bug report
(otherwise it will trigger an assert inside RegionStoreManager::getBinding
assert(!T->isVoidType() && "Attempting to dereference a void pointer!")).
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D42396
llvm-svn: 323382
This allows the analyzer to analyze ("inline") custom operator new() calls and,
even more importantly, inline constructors of objects that were allocated
by any operator new() - not necessarily a custom one.
All changes in the tests in the current commit are intended improvements,
even if they didn't carry any explicit FIXME flag.
It is possible to restore the old behavior via
-analyzer-config c++-allocator-inlining=false
(this flag is supported by scan-build as well, and it can be into a clang
--analyze invocation via -Xclang .. -Xclang ..). There is no intention to
remove the old behavior for now.
Differential Revision: https://reviews.llvm.org/D42219
rdar://problem/12180598
llvm-svn: 323373
I.e. not after. In the c++-allocator-inlining=true mode, we need to make the
assumption that the conservatively evaluated operator new() has returned a
non-null value. Previously we did this on CXXNewExpr, but now we have to do that
before calling the constructor, because some clever constructors are sometimes
assuming that their "this" is null and doing weird stuff. We would also crash
upon evaluating CXXNewExpr when the allocator was inlined and returned null and
had a throw specification; this is UB even for custom allocators, but we still
need not to crash.
Added more FIXME tests to ensure that eventually we fix calling the constructor
for null return values.
Differential Revision: https://reviews.llvm.org/D42192
llvm-svn: 323370
Analyzing problems which appear in scan-build results can be very
difficult, as after the launch no exact invocation is stored, and it's
super-hard to launch the debugger.
With this patch, the exact analyzer invocation appears in the footer,
and can be copied to debug/check reproducibility/etc.
rdar://35980230
llvm-svn: 323245
The check (inside StackHintGeneratorForSymbol::getMessage)
if (!N)
return getMessageForSymbolNotFound()
is moved to the beginning of the function.
Differential revision: https://reviews.llvm.org/D42388
Test plan: make check-all
llvm-svn: 323146
Fix an assertion failure caused by a missing CheckName. The malloc checker
enables "basic" support in the CStringChecker, which causes some CString
bounds checks to be enabled. In this case, make sure that we have a
valid CheckName for the BugType.
llvm-svn: 323052
MemRegion::getString() is a wrapper around MemRegion::dump(), which is not
user-friendly and should never be used for diagnostic messages.
Actual cases where raw dumps were reaching the user were unintentionally fixed
in r315736; these were noticed accidentally and shouldn't be reproducible
anymore. For now RetainCountChecker only tracks pointers through variable
regions, and for those dumps are "fine". However, we should still use a less
dangerous method for producing our path notes.
This patch replaces the dump with printing a variable name, asserting that this
is indeed a variable.
Differential Revision: https://reviews.llvm.org/D42015
llvm-svn: 322799
PreStmt<CXXNewExpr> was never called.
Additionally, under c++-allocator-inlining=true, PostStmt<CXXNewExpr> was
called twice when the allocator was inlined: once after evaluating the
new-expression itself, once after evaluating the allocator call which, for the
lack of better options, uses the new-expression as the call site.
This patch fixes both problems.
Differential Revision: https://reviews.llvm.org/D41934
rdar://problem/12180598
llvm-svn: 322797
Add PostAllocatorCall program point to represent the moment in the analysis
between the operator new() call and the constructor call. Pointer cast from
"void *" to the correct object pointer type has already happened by this point.
The new program point, unlike the previously used PostImplicitCall, contains a
reference to the new-expression, which allows adding path diagnostics over it.
Differential Revision: https://reviews.llvm.org/D41800
rdar://problem/12180598
llvm-svn: 322796
Pointer escape event notifies checkers that a pointer can no longer be reliably
tracked by the analyzer. For example, if a pointer is passed into a function
that has no body available, or written into a global, MallocChecker would
no longer report memory leaks for such pointer.
In case of operator new() under -analyzer-config c++-allocator-inlining=true,
MallocChecker would start tracking the pointer allocated by operator new()
only to immediately meet a pointer escape event notifying the checker that the
pointer has escaped into a constructor (assuming that the body of the
constructor is not available) and immediately stop tracking it. Even though
it is theoretically possible for such constructor to put "this" into
a global container that would later be freed, we prefer to preserve the old
behavior of MallocChecker, i.e. a memory leak warning, in order to
be able to find any memory leaks in C++ at all. In fact, c++-allocator-inlining
*reduces* the amount of false positives coming from this-pointers escaping in
constructors, because it'd be able to inline constructors in some cases.
With other checkers working similarly, we simply suppress the escape event for
this-value of the constructor, regardless of analyzer options.
Differential Revision: https://reviews.llvm.org/D41797
rdar://problem/12180598
llvm-svn: 322795
Implements finding appropriate source locations for intermediate diagnostic
pieces in path-sensitive bug reports that need to descend into an inlined
operator new() call that was called via new-expression. The diagnostics have
worked correctly when operator new() was called "directly".
Differential Revision: https://reviews.llvm.org/D41409
rdar://problem/12180598
llvm-svn: 322791
The callback runs after operator new() and before the construction and allows
the checker to access the casted return value of operator new() (in the
sense of r322780) which is not available in the PostCall callback for the
allocator call.
Update MallocChecker to use the new callback instead of PostStmt<CXXNewExpr>,
which gets called after the constructor.
Differential Revision: https://reviews.llvm.org/D41406
rdar://problem/12180598
llvm-svn: 322787
Make sure that with c++-allocator-inlining=true we have the return value of
conservatively evaluated operator new() in the correct memory space (heap).
This is a regression/omission that worked well in c++-allocator-inlining=false.
Heap regions are superior to regular symbolic regions because they have
stricter aliasing constraints: heap regions do not alias each other or global
variables.
Differential Revision: https://reviews.llvm.org/D41266
rdar://problem/12180598
llvm-svn: 322780
According to [basic.stc.dynamic.allocation], the return type of any C++
overloaded operator new() is "void *". However, type of the new-expression
"new T()" and the type of "this" during construction of "T" are both "T *".
Hence an implicit cast, which is not present in the AST, needs to be performed
before the construction. This patch adds such cast in the case when the
allocator was indeed inlined. For now, in the case where the allocator was *not*
inlined we still use the same symbolic value (which is a pure SymbolicRegion of
type "T *") because it is consistent with how we represent the casts and causes
less surprise in the checkers after switching to the new behavior.
The better approach would be to represent that value as a cast over a
SymbolicRegion of type "void *", however we have technical difficulties
conjuring such region without any actual expression of type "void *" present in
the AST.
Differential Revision: https://reviews.llvm.org/D41250
rdar://problem/12180598
llvm-svn: 322777
Represent the symbolic value for results of pointer arithmetic on void pointers
in a different way: instead of making void-typed element regions, make
char-typed element regions.
Add an assertion that ensures that no void-typed regions are ever constructed.
This is a refactoring of internals that should not immediately affect
the analyzer's (default) behavior.
Differential Revision: https://reviews.llvm.org/D40939
llvm-svn: 322775
The -analyzer-config c++-allocator-inlining experimental option allows the
analyzer to reason about C++ operator new() similarly to how it reasons about
regular functions. In this mode, operator new() is correctly called before the
construction of an object, with the help of a special CFG element.
However, the subsequent construction of the object was still not performed into
the region of memory returned by operator new(). The patch fixes it.
Passing the value from operator new() to the constructor and then to the
new-expression itself was tricky because operator new() has no call site of its
own in the AST. The new expression itself is not a good call site because it
has an incorrect type (operator new() returns 'void *', while the new expression
is a pointer to the allocated object type). Additionally, lifetime of the new
expression in the environment makes it unsuitable for passing the value.
For that reason, an additional program state trait is introduced to keep track
of the return value.
Finally this patch relaxes restrictions on the memory region class that are
required for inlining the constructor. This change affects the old mode as well
(c++-allocator-inlining=false) and seems safe because these restrictions were
an overkill compared to the actual problems observed.
Differential Revision: https://reviews.llvm.org/D40560
rdar://problem/12180598
llvm-svn: 322774
In most cases using
`N->getState()->getSVal(E, N->getLocationContext())`
is ugly, verbose, and also opens up more surface area for bugs if an
inconsistent location context is used.
This patch introduces a helper on an exploded node, and ensures
consistent usage of either `ExplodedNode::getSVal` or
`CheckContext::getSVal` across the codebase.
As a result, a large number of redundant lines is removed.
Differential Revision: https://reviews.llvm.org/D42155
llvm-svn: 322753
All usages of isSubRegionOf separately check for reflexive case, and in
any case, set theory tells us that each set is a subset of itself.
Differential Revision: https://reviews.llvm.org/D42140
llvm-svn: 322752
HTML diagnostics can be an overwhelming blob of pages of code.
This patch adds a checkbox which filters this list down to only the
lines *relevant* to the counterexample by e.g. skipping branches which
analyzer has assumed to be infeasible at a time.
The resulting amount of output is much smaller, and often fits on one
screen, and also provides a much more readable diagnostics.
Differential Revision: https://reviews.llvm.org/D41378
llvm-svn: 322612
In the security package, we have a simple syntactic check that warns about
strcpy() being insecure, due to potential buffer overflows.
Suppress that check's warning in the trivial situation when the source is an
immediate null-terminated string literal and the target is an immediate
sufficiently large buffer.
Patch by András Leitereg!
Differential Revision: https://reviews.llvm.org/D41384
llvm-svn: 322410
Simple refactoring attempt: factor out some code, remove some
repetition, use auto where appropriate.
Differential Revision: https://reviews.llvm.org/D41751
llvm-svn: 322151
The current code used to not suppress the report, if the dereference was
performed in a macro, assuming it is that same macro.
However, the assumption might not be correct, and XNU has quite a bit of
code where dereference is actually performed in a different macro.
As the code uses macro name and not a unique identifier it might be fragile,
but in a worst-case scenario we would simply emit an extra diagnostic.
rdar://36160245
Differential Revision: https://reviews.llvm.org/D41749
llvm-svn: 322149
This addresses an issue introduced in r183451: since
`removePiecesWithInvalidLocations` is called *after* `adjustCallLocations`,
it is not necessary, and in fact harmful, to have this assertion in
adjustCallLocations.
Addresses rdar://36170689
Differential Revision: https://reviews.llvm.org/D41680
llvm-svn: 321682
This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms.
Fixes the -Wreorder issue and fixes the ast-dump-color.cpp test.
llvm-svn: 321310
Using ARC, strong, weak, and autoreleasing stack variables are implicitly
initialized with nil. This includes variable-length arrays of Objective-C object
pointers. However, in the analyzer we don't zero-initialize them. We used to,
but it accidentally regressed after r289618.
Under ARC, the array variable's initializer within DeclStmt is an
ImplicitValueInitExpr. Environment doesn't maintain any bindings for this
expression kind - instead it always knows that it's a known constant
(0 in our case), so it just returns the known value by calling
SValBuilder::makeZeroVal() (see EnvironmentManager::getSVal().
Commit r289618 had introduced reasonable behavior of SValBuilder::makeZeroVal()
for the arrays, which produces a zero-length compoundVal{}. When such value
is bound to arrays, in RegionStoreManager::bindArray() "remaining" items in the
array are default-initialized with zero, as in
RegionStoreManager::setImplicitDefaultValue(). The similar mechanism works when
an array is initialized by an initializer list that is too short, eg.
int a[3] = { 1, 2 };
would result in a[2] initialized with 0. However, in case of variable-length
arrays it didn't know if any more items need to be added,
because, well, the length is variable.
Add the default binding anyway, regardless of how many actually need
to be added. We don't really care how many, because the default binding covers
the whole array anyway.
Differential Revision: https://reviews.llvm.org/D41478
rdar://problem/35477763
llvm-svn: 321290
This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms.
llvm-svn: 321223
The bugreporter::trackNullOrUndefValue() mechanism contains a system of bug
reporter visitors that recursively call each other in order to track where a
null or undefined value came from, where each visitor represents a particular
tracking mechanism (track how the value was stored, track how the value was
returned from a function, track how the value was constrained to null, etc.).
Each visitor is only added once per value it needs to track. Almost. One
exception from this rule would be FindLastStoreBRVisitor that has two operation
modes: it contains a flag that indicates whether null stored values should be
suppressed. Two instances of FindLastStoreBRVisitor with different values of
this flag are considered to be different visitors, so they can be added twice
and produce the same diagnostic twice. This was indeed the case in the affected
test.
With the current logic of this whole machinery, such duplication seems
unavoidable. We should be able to safely add visitors with different flag
values without constructing duplicate diagnostic pieces. Hence the effort
in this commit to de-duplicate diagnostics regardless of what visitors
have produced them.
Differential Revision: https://reviews.llvm.org/D41258
llvm-svn: 321135
When trying to figure out where a null or undefined value came from,
parentheses and cast expressions are either completely irrelevant, or,
in the case of lvalue-to-rvale cast, straightforwardly lead us in the right
direction when we remove them.
There is a regression that causes a certain diagnostic to appear twice in the
path-notes.cpp test (changed to FIXME). It would be addressed in the next
commit.
Differential revision: https://reviews.llvm.org/D41254
llvm-svn: 321133
When reporting certain kinds of analyzer warnings, we use the
bugreporter::trackNullOrUndefValue mechanism, which is part of public checker
API, to understand where a zero, null-pointer, or garbage value came from,
which would highlight important events with respect to that value in the
diagnostic path notes, and help us suppress various false positives that result
from values appearing from particular sources.
Previously, we've lost track of the value when it was written into a memory
region that is not a plain variable. Now try to resume tracking in this
situation by finding where the last write to this region has occured.
Differential revision: https://reviews.llvm.org/D41253
llvm-svn: 321130
Since C++17, classes that have base classes can potentially be initialized as
aggregates. Trying to construct such objects through brace initialization was
causing the analyzer to crash when the base class has a non-trivial constructor,
while figuring target region for the base class constructor, because the parent
stack frame didn't contain the constructor of the subclass, because there is
no constructor for subclass, merely aggregate initialization.
This patch avoids the crash, but doesn't provide the actually correct region
for the constructor, which still remains to be fixed. Instead, construction
goes into a fake temporary region which would be immediately discarded. Similar
extremely conservative approach is used for other cases in which the logic for
finding the target region is not yet implemented, including aggregate
initialization with fields instead of base-regions (which is not C++17-specific
but also never worked, just didn't crash).
Differential revision: https://reviews.llvm.org/D40841
rdar://problem/35441058
llvm-svn: 321128
Adding the new enumerator forced a bunch more changes into this patch than I
would have liked. The -Wtautological-compare warning was extended to properly
check the new comparison operator, clang-format needed updating because it uses
precedence levels as weights for determining where to break lines (and several
operators increased their precedence levels with this change), thread-safety
analysis needed changes to build its own IL properly for the new operator.
All "real" semantic checking for this operator has been deferred to a future
patch. For now, we use the relational comparison rules and arbitrarily give
the builtin form of the operator a return type of 'void'.
llvm-svn: 320707
The new check introduced in r318705 is useful, but suffers from a particular
class of false positives, namely, it does not account for
dispatch_barrier_sync() API which allows one to ensure that the asyncronously
executed block that captures a pointer to a local variable does not actually
outlive that variable.
The new check is split into a separate checker, under the name of
alpha.core.StackAddressAsyncEscape, which is likely to get enabled by default
again once these positives are fixed. The rest of the StackAddressEscapeChecker
is still enabled by default.
Differential Revision: https://reviews.llvm.org/D41042
llvm-svn: 320455
This is a follow-up from r314910. When a checker developer attempts to
dereference a location in memory through ProgramState::getSVal(Loc) or
ProgramState::getSVal(const MemRegion *), without specifying the second
optional QualType parameter for the type of the value he tries to find at this
location, the type is auto-detected from location type. If the location
represents a value beyond a void pointer, we thought that auto-detecting the
type as 'char' is a good idea. However, in most practical cases, the correct
behavior would be to specify the type explicitly, as it is available from other
sources, and the few cases where we actually need to take a 'char' are
workarounds rather than an intended behavior. Therefore, try to fail with an
easy-to-understand assertion when asked to read from a void pointer location.
Differential Revision: https://reviews.llvm.org/D38801
llvm-svn: 320451
Array subscript is almost always an lvalue, except for a few cases where
it is not, such as a subscript into an Objective-C property, or a
return from the function.
This commit prevents crashing in such cases.
Fixes rdar://34829842
Differential Revision: https://reviews.llvm.org/D40584
llvm-svn: 319834
They are now printed as HeapSymRegion{$x} in order to discriminate between that
and regular SymRegion{$x}, which are two different regions, having different
parent reginos (memory spaces) - HeapSpaceRegion and UnknownSpaceRegion
respectively.
Differential Revision: https://reviews.llvm.org/D40793
llvm-svn: 319793
Two copies of getSymLERange in RangeConstraintManager are virtually
identical, which is clearly bad.
This patch uses lambdas to call one from another (assuming that we would
like to avoid getting ranges from the state when necessary).
Differential Revision: https://reviews.llvm.org/D39709
llvm-svn: 319697
RegionStore has special logic to evaluate captured constexpr variables.
However, if the constexpr initializer cannot be evaluated as an integer, the
value is treated as undefined. This leads to false positives when, for example,
a constexpr float is captured by a lambda.
To fix this, treat a constexpr capture that cannot be evaluated as unknown
rather than undefined.
rdar://problem/35784662
llvm-svn: 319638
In the original design of the analyzer, it was assumed that a BlockEntrance
doesn't create a new binding on the Store, but this assumption isn't true when
'widen-loops' is set to true. Fix this by finding an appropriate location
BlockEntrace program points.
Patch by Henry Wong!
Differential Revision: https://reviews.llvm.org/D37187
llvm-svn: 319333
We didn't support the following syntax:
(std::initializer_list<int>){12}
which suddenly produces CompoundLiteralExpr that contains
CXXStdInitializerListExpr.
Lift the assertion and instead pass the value through CompoundLiteralExpr
transparently, as it doesn't add much.
Differential Revision: https://reviews.llvm.org/D39803
llvm-svn: 319058
We were crashing whenever a C++ pointer-to-member was taken, that was pointing
to a member of an anonymous structure field within a class, eg.
struct A {
struct {
int x;
};
};
// ...
&A::x;
Differential Revision: https://reviews.llvm.org/D39800
llvm-svn: 319055
Teach the retain-count checker that CoreMedia reference types use
CoreFoundation-style reference counting. This enables the checker
to catch leaks and over releases of those types.
rdar://problem/33599757
llvm-svn: 318979
This diff extends StackAddrEscapeChecker
to catch stack addresses leaks via block captures
if the block is executed asynchronously or
returned from a function.
Differential revision: https://reviews.llvm.org/D39438
llvm-svn: 318705
The ObjCGenerics checker warns on a cast when there is no subtyping relationship
between the tracked type of the value and the destination type of the cast. It
does this even if the cast was explicitly written. This means the user can't
write an explicit cast to silence the diagnostic.
This commit treats explicit casts involving generic types as an indication from
the programmer that the Objective-C type system is not rich enough to express
the needed invariant. On explicit casts, the checker now removes any existing
information inferred about the type arguments. Further, it no longer assumes
the casted-to specialized type because the invariant the programmer specifies
in the cast may only hold at a particular program point and not later ones. This
prevents a suppressing cast from requiring a cascade of casts down the
line.
rdar://problem/33603303
Differential Revision: https://reviews.llvm.org/D39711
llvm-svn: 318054
This is the issue breaking the postgresql bot, purely by chance exposed
through taint checker, somehow appearing after
https://reviews.llvm.org/D38358 got committed.
The backstory is that the taint checker requests SVal for the value of
the pointer, and analyzer has a "fast path" in the getter to return a
constant when we know that the value is constant.
Unfortunately, the getter requires a cast to get signedness correctly,
and for the pointer `void *` the cast crashes.
This is more of a band-aid patch, as I am not sure what could be done
here "correctly", but it should be applied in any case to avoid the
crash.
Differential Revision: https://reviews.llvm.org/D39862
llvm-svn: 317839
Patches the solver to assume that bitwise OR of an unsigned value with a
constant always produces a value larger-or-equal than the constant, and
bitwise AND with a constant always produces a value less-or-equal than
the constant.
This patch is especially useful in the context of using bitwise
arithmetic for error code encoding: the analyzer would be able to state
that the error code produced using a bitwise OR is non-zero.
Differential Revision: https://reviews.llvm.org/D39707
llvm-svn: 317820
Do not crash when trying to compute x && y or x || y where x and y are
of a vector type.
For now we do not seem to properly model operations with vectors. In particular,
operations && and || on a pair of vectors are not short-circuit, unlike regular
logical operators, so even our CFG is incorrect.
Avoid the crash, add respective FIXME tests for later.
Differential Revision: https://reviews.llvm.org/D39682
rdar://problem/34317663
llvm-svn: 317700
Do not crash when trying to define and call a non-standard
strcpy(unsigned char *, unsigned char *) during analysis.
At the same time, do not try to actually evaluate the call.
Differential Revision: https://reviews.llvm.org/D39422
llvm-svn: 317565
The analyzer did not return an UndefVal in case a negative value was left
shifted. I also altered the UndefResultChecker to emit a clear warning in this
case.
Differential Revision: https://reviews.llvm.org/D39423
llvm-svn: 316924
Now when a template is instantiated more times and there is a bug found in the
instantiations the issue hash will be different for each instantiation even if
every other property of the bug (path, message, location) is the same.
This patch aims to resolve this issue. Note that explicit specializations still
generate different hashes but that is intended.
Differential Revision: https://reviews.llvm.org/D38728
llvm-svn: 316900
Extend ExprInspection checker to make it possible to dump the issue hash of
arbitrary expressions. This change makes it possible to make issue hash related
tests more concise and also makes debugging issue hash related problems easier.
Differential Revision: https://reviews.llvm.org/D38844
llvm-svn: 316899
Added new enum in order to differentiate the warning messages on "misusing" into
3 categories: function calls, moving an object, copying an object. (At the
moment the checker gives the same message in case of copying and moving.)
Additional test cases added as well.
Differential Revision: https://reviews.llvm.org/D38674
llvm-svn: 316852
An earlier solution from Artem r315301 solves the reset problem, however, the
reports should be handled the same way in case of method calls. We should not
just report the base class of the object where the method was defined but the
whole object.
Fixed false positive which came from not removing the subobjects in case of a
state-resetting function. (Just replaced the State->remove(...) call to
removeFromState(..) which was defined exactly for that purpose.)
Some minor typos fixed in this patch as well which did not worth a whole new
patch in my opinion, so included them here.
Differential Revision: https://reviews.llvm.org/D31538
llvm-svn: 316850
The loop unrolling feature aims to track the maximum possible steps a loop can
make. In order to implement this, it investigates the initial value of the
counter variable and the bound number. (It has to be known.)
These numbers are used as llvm::APInts, however, it was not checked if their
bitwidths are the same which lead to some crashes.
This revision solves this problem by extending the "shorter" one (to the length
of the "longer" one).
For the detailed bug report, see: https://bugs.llvm.org/show_bug.cgi?id=34943
Differential Revision: https://reviews.llvm.org/D38922
llvm-svn: 316830
In getLValueElement Base may represent the address of a label
(as in the newly-added test case), in this case it's not a loc::MemRegionVal
and Base.castAs<loc::MemRegionVal>() triggers an assert, this diff makes
getLValueElement return UnknownVal instead.
Differential revision: https://reviews.llvm.org/D39174
llvm-svn: 316399
In some cases the analyzer didn't expect an array-type variable to be
initialized with anything other than a string literal. The patch essentially
removes the assertion, and ensures relatively sane behavior.
There is a bigger problem with these initializers. Currently our memory model
(RegionStore) is being ordered to initialize the array with a region that
is assumed to be storing the initializer rvalue, and it guesses to copy
the contents of that region to the array variable. However, it would make
more sense for RegionStore to receive the correct initializer in the first
place. This problem isn't addressed with this patch.
rdar://problem/27248428
Differential Revision: https://reviews.llvm.org/D23963
llvm-svn: 315750
The checker used to crash when a mempcpy's length argument is symbolic. In this
case the cast from 'void *' to 'char *' failed because the respective
ElementRegion that represents cast is hard to add on top of the existing
ElementRegion that represents the offset to the last copied byte, while
preseving a sane memory region structure.
Additionally, a few test cases are added (to casts.c) which demonstrate problems
caused by existing sloppy work we do with multi-layer ElementRegions. If said
cast would be modeled properly in the future, these tests would need to be
taken into account.
Differential Revision: https://reviews.llvm.org/D38797
llvm-svn: 315742
It is not uncommon for the users to make their own wrappers around
CoreFoundation's CFRetain and CFRelease functions that are defensive
against null references. In such cases CFRetain is often incorrectly
marked as CF_RETURNS_RETAINED. Ignore said annotation and treat such
wrappers similarly to the regular CFRetain.
rdar://problem/31699502
Differential Revision: https://reviews.llvm.org/D38877
llvm-svn: 315736
If a method is resetting the state of an object that was moved from, it should
be safe to use this object again. However if the method was defined in a parent
class, but used in a child class, the reset didn't happen from the checker's
perspective.
Differential Revision: https://reviews.llvm.org/D31538
llvm-svn: 315301
This method injects additional information into program state dumps,
describing which objects have been moved from.
Differential Revision: https://reviews.llvm.org/D31541
llvm-svn: 315300
This method injects additional information into program state dumps,
describing states of mutexes tracked by the checker.
Differential Revision: https://reviews.llvm.org/D37805
llvm-svn: 315298
The analyzer now realizes that C++ std::initializer_list objects and
Objective-C boxed structure/array/dictionary expressions can potentially
maintain a reference to the objects that were put into them. This avoids
false memory leak posivites and a few other issues.
This is a conservative behavior; for now, we do not model what actually happens
to the objects after being passed into such initializer lists.
rdar://problem/32918288
Differential Revision: https://reviews.llvm.org/D35216
llvm-svn: 314975
In ProgramState::getSVal(Location, Type) API which dereferences a pointer value,
when the optional Type parameter is not supplied and the Location is not typed,
type should have been guessed on a best-effort basis by inspecting the Location
more deeply. However, this never worked; the auto-detected type was instead
a pointer type to the correct type.
Fixed the issue and added various test cases to demonstrate which parts of the
analyzer were affected (uninitialized pointer argument checker, C++ trivial copy
modeling, Google test API modeling checker).
Additionally, autodetected void types are automatically replaced with char,
in order to simplify checker APIs. Which means that if the location is a void
pointer, getSVal() would read the first byte through this pointer
and return its symbolic value.
Fixes pr34305.
Differential Revision: https://reviews.llvm.org/D38358
llvm-svn: 314910
Fixes the test failure: temporary is now bound to std::string, tests
fully pass on Linux.
This reverts commit b36ee0924038e1d95ea74230c62d46e05f80587e.
llvm-svn: 314859
Only assume that IOBSDNameMatching and friends increment a reference counter
if their return type is a CFMutableDictionaryRef.
Differential Revision: https://reviews.llvm.org/D38487
llvm-svn: 314820
This function can now track null pointer through simple pointer arithmetic,
such as '*&*(p + 2)' => 'p' and so on, displaying intermediate diagnostic pieces
for the user to understand where the null pointer is coming from.
Differential Revision: https://reviews.llvm.org/D37025
llvm-svn: 314290
This API is used by checkers (and other entities) in order to track where does
a value originate from, by jumping from an expression value of which is equal
to that value to the expression from which this value has "appeared". For
example, it may be an lvalue from which the rvalue was loaded, or a function
call from which the dereferenced pointer was returned.
The function now avoids incorrectly unwrapping implicit lvalue-to-rvalue casts,
which caused crashes and incorrect intermediate diagnostic pieces. It also no
longer relies on how the expression is written when guessing what it means.
Fixes pr34373 and pr34731.
rdar://problem/33594502
Differential Revision: https://reviews.llvm.org/D37023
llvm-svn: 314287
This patch fixes analyzer's crash on the newly added test case
(see also https://bugs.llvm.org/show_bug.cgi?id=34374).
Pointers subtraction appears to be modeled incorrectly
in the following example:
char* p;
auto n = p - reinterpret_cast<char*>((unsigned long)1);
In this case the analyzer (built without this patch)
tries to create a symbolic value for the difference
treating reinterpret_cast<char*>((unsigned long)1)
as an integer, that is not correct.
Differential revision: https://reviews.llvm.org/D38214
Test plan: make check-all
llvm-svn: 314141
The implementation is in AnalysisDeclContext.cpp and the class is called
AnalysisDeclContext.
Making those match up has numerous benefits, including:
- Easier jump from header to/from implementation.
- Easily identify filename from class.
Differential Revision: https://reviews.llvm.org/D37500
llvm-svn: 312671
Summary:
So far we used a value of 10 which was useful for testing but produces many false-positives in real programs. The usual suspicious clones we find seem to be at around a complexity value of 70 and for normal clone-reporting everything above 50 seems to be a valid normal clone for users, so let's just go with 50 for now and set this as the new default value.
This patch also explicitly sets the complexity value for the regression tests as they serve more of a regression testing/debugging purpose and shouldn't really be reported by default in real programs. I'll add more tests that reflect actual found bugs that then need to pass with the default setting in the future.
Reviewers: NoQ
Subscribers: cfe-commits, javed.absar, xazax.hun, v.g.vassilev
Differential Revision: https://reviews.llvm.org/D34178
llvm-svn: 312468
Summary:
This patch aims at optimizing the CloneChecker for larger programs. Before this
patch we took around 102 seconds to analyze sqlite3 with a complexity value of
50. After this patch we now take 2.1 seconds to analyze sqlite3.
The biggest performance optimization is that we now put the constraint for group
size before the constraint for the complexity. The group size constraint is much
faster in comparison to the complexity constraint as it only does a simple
integer comparison. The complexity constraint on the other hand actually
traverses each Stmt and even checks the macro stack, so it is obviously not able
to handle larger amounts of incoming clones. The new order filters out all the
single-clone groups that the type II constraint generates in a faster way before
passing the fewer remaining clones to the complexity constraint. This reduced
runtime by around 95%.
The other change is that we also delay the verification part of the type II
clones back in the chain of constraints. This required to split up the
constraint into two parts - a verification and a hash constraint (which is also
making it more similar to the original design of the clone detection algorithm).
The reasoning for this is the same as before: The verification constraint has to
traverse many statements and shouldn't be at the start of the constraint chain.
However, as the type II hashing has to be the first step in our algorithm, we
have no other choice but split this constrain into two different ones. Now our
group size and complexity constrains filter out a chunk of the clones before
they reach the slow verification step, which reduces the runtime by around 8%.
I also kept the full type II constraint around - that now just calls it's two
sub-constraints - in case someone doesn't care about the performance benefits
of doing this.
Reviewers: NoQ
Reviewed By: NoQ
Subscribers: klimek, v.g.vassilev, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D34182
llvm-svn: 312222
This diff fixes modeling of arithmetic
expressions where pointers are treated as integers
(i.e. via C-style / reinterpret casts).
For now we return UnknownVal unless the operation is a comparison.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D37120
llvm-svn: 311935
This way the unrolling can be restricted for loops which will take at most a
given number of steps. It is defined as 128 in this patch and it seems to have
a good number for that purpose.
Differential Revision: https://reviews.llvm.org/D37181
llvm-svn: 311883
Added check if the execution of the last step of the given unrolled loop has
generated more branches. If yes, than treat it as a normal (non-unrolled) loop
in the remaining part of the analysis.
Differential Revision: https://reviews.llvm.org/D36962
llvm-svn: 311881
1. The LoopUnrolling feature needs the LoopExit included in the CFG so added this
dependency via the config options
2. The LoopExit element can be encountered even if we haven't encountered the
block of the corresponding LoopStmt. So the asserts were not right.
3. If we are caching out the Node then we get a nullptr from generateNode which
case was not handled.
Differential Revision: https://reviews.llvm.org/D37103
llvm-svn: 311880
The LoopExit CFG information provides the opportunity to not mark the loops but
having a stack which tracks if a loop is unrolled or not. So in case of
simulating a loop we just add it and the information if it meets the
requirements to be unrolled to the top of the stack.
Differential Revision: https://reviews.llvm.org/D35684
llvm-svn: 311346
This patch adds handling of the LoopExit CFGElements to the StaticAnalyzer.
This is reached by introducing a new ProgramPoint.
Tests will be added in a following commit.
Differential Revision: https://reviews.llvm.org/D35670
llvm-svn: 311344
This patch introduces a new CFG element CFGLoopExit that indicate when a loop
ends. It does not deal with returnStmts yet (left it as a TODO).
It hidden behind a new analyzer-config flag called cfg-loopexit (false by
default).
Test cases added.
The main purpose of this patch right know is to make loop unrolling and loop
widening easier and more efficient. However, this information can be useful for
future improvements in the StaticAnalyzer core too.
Differential Revision: https://reviews.llvm.org/D35668
llvm-svn: 311235
Adding escape check for the counter variable of the loop.
It is achieved by jumping back on the ExplodedGraph to its declStmt.
Differential Revision: https://reviews.llvm.org/D35657
llvm-svn: 311234
This diff fixes analyzer's crash (triggered assert) on the newly added test case.
The assert being discussed is assert(!B.lookup(R, BindingKey::Direct))
in lib/StaticAnalyzer/Core/RegionStore.cpp, however the root cause is different.
For classes with empty bases the offsets might be tricky.
For example, let's assume we have
struct S: NonEmptyBase, EmptyBase {
...
};
In this case Clang applies empty base class optimization and
the offset of EmptyBase will be 0, it can be verified via
clang -cc1 -x c++ -v -fdump-record-layouts main.cpp -emit-llvm -o /dev/null.
When the analyzer tries to perform zero initialization of EmptyBase
it will hit the assert because that region
has already been "written" by the constructor of NonEmptyBase.
Test plan:
make check-all
Differential revision: https://reviews.llvm.org/D36851
llvm-svn: 311182
This commit adds the functionality of performing reference counting on the
callee side for Integer Set Library (ISL) to Clang Static Analyzer's
RetainCountChecker.
Reference counting on the callee side can be extensively used to perform
debugging within a function (For example: Finding leaks on error paths).
Patch by Malhar Thakkar!
Differential Revision: https://reviews.llvm.org/D36441
llvm-svn: 311063
This diff fixes a crash (triggered assert) on the newly added test case.
In the method Simplifier::VisitSymbolData we check the type of S and return
Loc/NonLoc accordingly.
Differential revision: https://reviews.llvm.org/D36564
llvm-svn: 310887
This change adds support for cross-file diagnostic paths in html output. If the
diagnostic path is not cross-file, there is no change in the output.
Patch by Vlad Tsyrklevich!
Differential Revision: https://reviews.llvm.org/D30406
llvm-svn: 309968
This feature allows the analyzer to consider loops to completely unroll.
New requirements/rules (for unrolling) can be added easily via ASTMatchers.
Right now it is hidden behind a flag, the aim is to find the correct heuristic
and create a solution which results higher coverage % and more precise
analysis, thus can be enabled by default.
Right now the blocks which belong to an unrolled loop are marked by the
LoopVisitor which adds them to the ProgramState.
Then whenever we encounter a CFGBlock in the processCFGBlockEntrance which is
marked then we skip its investigating. That means, it won't be considered to
be visited more than the maximal bound for visiting since it won't be checked.
llvm-svn: 309006
Add a 'Generalized' object kind to the retain-count checker and suitable
generic diagnostic text for retain-count diagnostics involving those objects.
For now the object kind is introduced in summaries by 'annotate' attributes.
Once we have more experience with these annotations we will propose explicit
attributes.
Patch by Malhar Thakkar!
Differential Revision: https://reviews.llvm.org/D35613
llvm-svn: 308990
Because since r308957 the suppress-on-sink feature contains its own
mini-analysis, it also needs to become aware that C++ unhandled exceptions
cause sinks. Unfortunately, for now we treat all exceptions as unhandled in
the analyzer, so suppress-on-sink needs to do the same.
rdar://problem/28157554
Differential Revision: https://reviews.llvm.org/D35674
llvm-svn: 308961
If a certain memory leak (or other similar bug) found by the analyzer is known
to be happening only before abnormal termination of the program ("sink", eg.
assertion failure in the code under analysis, or another bug that introduces
undefined behavior), such leak warning is discarded. However, if the analysis
has never reaches completion (due to complexity of the code), it may be
failing to notice the sink.
This commit further extends the partial solution introduced in r290341 to cover
cases when a complicated control flow occurs before encountering a no-return
statement (which anyway inevitably leads to such statement(s)) by traversing
the respective section of the CFG in a depth-first manner. A complete solution
still seems elusive.
rdar://problem/28157554
Differential Revision: https://reviews.llvm.org/D35673
llvm-svn: 308957
requirements/rules (for unrolling) can be added easily via ASTMatchers.
The current implementation is hidden behind a flag.
Right now the blocks which belong to an unrolled loop are marked by the
LoopVisitor which adds them to the ProgramState. Then whenever we encounter a
CFGBlock in the processCFGBlockEntrance which is marked then we skip its
investigating. That means, it won't be considered to be visited more than the
maximal bound for visiting since it won't be checked.
Differential Revision: https://reviews.llvm.org/D34260
llvm-svn: 308558
Add support to the retain-count checker for an annotation indicating that a
function's implementation should be trusted by the retain count checker.
Functions with these attributes will not be inlined and the arguments will
be treating as escaping.
Adding this annotation avoids spurious diagnostics when the implementation of
a reference counting operation is visible but the analyzer can't reason
precisely about the ref count.
Patch by Malhar Thakkar!
Differential Revision: https://reviews.llvm.org/D34937
llvm-svn: 308416
There was already a returns_localized_nsstring annotation to indicate
that the return value could be passed to UIKit methods that would
display them. However, those UIKit methods were hard-coded, and it was
not possible to indicate that other classes/methods in a code-base would
do the same.
The takes_localized_nsstring annotation can be put on function
parameters and selector parameters to indicate that those will also show
the string to the user.
Differential Revision: https://reviews.llvm.org/D35186
llvm-svn: 308012
Summary:
This mimics the implementation for the implicit destructors. The
generation of this scope leaving elements is hidden behind
a flag to the CFGBuilder, thus it should not affect existing code.
Currently, I'm missing a test (it's implicitly tested by the clang-tidy
lifetime checker that I'm proposing).
I though about a test using debug.DumpCFG, but then I would
have to add an option to StaticAnalyzer/Core/AnalyzerOptions
to enable the scope leaving CFGElement,
which would only be useful to that particular test.
Any other ideas how I could make a test for this feature?
Reviewers: krememek, jordan_rose
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15031
llvm-svn: 307759
This is a follow up for one of
the previous diffs https://reviews.llvm.org/D32328.
getTypeSize and with getIntWidth are not equivalent for bool
(see https://clang.llvm.org/doxygen/ASTContext_8cpp_source.html#l08444),
this causes a number of issues
(for instance, if APint X representing a bool is created
with the wrong bit width then X is not comparable against Min/Max
(because of the different bit width), that results in crashes
(triggered asserts) inside assume* methods),
for examples see the newly added test cases.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D35041
llvm-svn: 307604
This is a new checker package. It contains checkers that highlight
well-documented implementation-defined behavior. Such checkers are only useful
to developers that intend to write portable code. Code that is only compiled for
a single platform should be allowed to rely on this platform's specific
documented behavior.
rdar://problem/30545046
Differential Revision: https://reviews.llvm.org/D34102
llvm-svn: 306396
This makes the analyzer around 10% slower by default,
allowing it to find deeper bugs.
Default values for the following -analyzer-config change:
max-nodes: 150000 -> 225000;
max-inlinable-size: 50 -> 100.
rdar://problem/32539666
Differential Revision: https://reviews.llvm.org/D34277
llvm-svn: 305900
Add support for new methods that were added in macOS High Sierra & iOS 11
and require a localized string.
Patch by Kulpreet Chilana!
rdar://problem/32795210
Differential Revision: https://reviews.llvm.org/D34266
llvm-svn: 305896
Memory region allocated by alloca() carries no implicit type information.
Don't crash when resolving the init message for an Objective-C object
that is being constructed in such region.
rdar://problem/32517077
Differential Revision: https://reviews.llvm.org/D33828
llvm-svn: 305211
In plist output mode with alternate path diagnostics, when entering a function,
we draw an arrow from the caller to the beginning of the callee's declaration.
Upon exiting, however, we draw the arrow from the last statement in the
callee function. The former makes little sense when the declaration is
not a definition, i.e. has no body, which may happen in case the body
is coming from a body farm, eg. Objective-C autosynthesized property accessor.
Differential Revision: https://reviews.llvm.org/D33671
llvm-svn: 304713
Nullable-to-nonnull checks used to crash when the custom bug visitor was trying
to add its notes to autosynthesized accessors of Objective-C properties.
Now we avoid this, mostly automatically outside of checker control, by
moving the diagnostic to the parent stack frame where the accessor has been
called.
Differential revision: https://reviews.llvm.org/D32437
llvm-svn: 304710
This should fix the leaks found by asan buildbot in r304162.
Also don't store a reference to the factory with every map value,
which is the only difference between ImmutableMap and ImmutableMapRef.
llvm-svn: 304170
The analyzer's taint analysis can now reason about structures or arrays
originating from taint sources in which only certain sections are tainted.
In particular, it also benefits modeling functions like read(), which may
read tainted data into a section of a structure, but RegionStore is incapable of
expressing the fact that the rest of the structure remains intact, even if we
try to model read() directly.
Patch by Vlad Tsyrklevich!
Differential revision: https://reviews.llvm.org/D28445
llvm-svn: 304162
The new checker currently contains the very core infrastructure for tracking
the state of iterator-type objects in the analyzer: relating iterators to
their containers, tracking symbolic begin and end iterator values for
containers, and solving simple equality-type constraints over iterators.
A single specific check over this infrastructure is capable of finding usage of
out-of-range iterators in some simple cases.
Patch by Ádám Balogh!
Differential revision: https://reviews.llvm.org/D32592
llvm-svn: 304160
pthread_mutex_destroy() may fail, returning a non-zero error number, and
keeping the mutex untouched. The mutex can be used on the execution branch
that follows such failure, so the analyzer shouldn't warn on using
a mutex that was previously destroyed, when in fact the destroy call has failed.
Patch by Malhar Thakkar!
Differential revision: https://reviews.llvm.org/D32449
llvm-svn: 304159
Even though the shouldInlineCall function returns true, it can happen that the
function is not going to be inlined (as it can be seen at line 913 and below).
Moved the bumpNumTimesInlined(D) (the counter increaser) call to the inlineCall
function where it logically belongs.
Differential Revision: https://reviews.llvm.org/D32179
llvm-svn: 303158
Use variadic templates instead of relying on <cstdarg> + sentinel.
This enforces better type checking and makes code more readable.
Differential revision: https://reviews.llvm.org/D32550
llvm-svn: 302572
It was written as "Memory Error" in most places and as "Memory error" in a few
other places, however it is the latter that is more consistent with
other categories (such as "Logic error").
rdar://problem/31718115
Differential Revision: https://reviews.llvm.org/D32702
llvm-svn: 302016
Array-to-pointer cast now works correctly when the pointer to the array
is concrete, eg. null, which allows further symbolic calculations involving
such values.
Inlined defensive checks are now detected correctly when the resulting null
symbol is being array-subscripted before dereference.
Differential Revision: https://reviews.llvm.org/D32291
llvm-svn: 301251
Null dereferences are suppressed if the lvalue was constrained to 0 for the
first time inside a sub-function that was inlined during analysis, because
such constraint is a valid defensive check that does not, by itself,
indicate that null pointer case is anyhow special for the caller.
If further operations on the lvalue are performed, the symbolic lvalue is
collapsed to concrete null pointer, and we need to track where does the null
pointer come from.
Improve such tracking for lvalue operations involving operator &.
rdar://problem/27876009
Differential Revision: https://reviews.llvm.org/D31982
llvm-svn: 301224
This diff replaces getTypeSize(CondE->getType()))
with getIntWidth(CondE->getType())) in ExprEngine::processSwitch.
These calls are not equivalent for bool, see ASTContext.cpp
Add a test case.
Test plan:
make check-clang-analysis
make check-clang
Differential revision: https://reviews.llvm.org/D32328
llvm-svn: 300936
We now check the type of the super-region pointer for most SubRegion classes
in compile time; some checks are run-time though.
This is an API-breaking change (we now require explicit casts to specific region
sub-classes), but in practice very few checkers are affected.
Differential Revision: https://reviews.llvm.org/D26838
llvm-svn: 300189
Clean up vtable anchors (remove anchors for regions that have regular
out-of-line virtual methods, add anchors for regions that don't have those).
Fix private/public methods (all constructors should now be private for leaf
classes, protected for abstract classes).
No functional change intended, only extra sanity checks and cleanups.
Differential Revision: https://reviews.llvm.org/D26837
llvm-svn: 300187
SValBuilder tries to constant-fold symbols in the left-hand side of the symbolic
expression whenever it fails to evaluate the expression directly. However, it
only constant-folds them when they are atomic expressions, not when they are
complicated expressions themselves. This patch adds recursive constant-folding
to the left-hand side subexpression (there's a lack of symmetry because we're
trying to have symbols on the left and constants on the right). As an example,
we'd now be able to handle operations similar to "$x + 1 < $y", when $x is
constrained to a constant.
rdar://problem/31354676
Differential Revision: https://reviews.llvm.org/D31886
llvm-svn: 300178
This diff adds a defensive check in getExtraInvalidatedValues
for the case when there are no regions for the ivar associated with
a property. Corresponding test case added.
Test plan:
make check-clang
make check-clang-analysis
llvm-svn: 300114
Hopefully fix crashes by unshadowing the variable.
Original commit message:
A big part of the clone detection code is functionality for filtering clones and
clone groups based on different criteria. So far this filtering process was
hardcoded into the CloneDetector class, which made it hard to understand and,
ultimately, to extend.
This patch splits the CloneDetector's logic into a sequence of reusable
constraints that are used for filtering clone groups. These constraints
can be turned on and off and reodreder at will, and new constraints are easy
to implement if necessary.
Unit tests are added for the new constraint interface.
This is a refactoring patch - no functional change intended.
Patch by Raphael Isemann!
Differential Revision: https://reviews.llvm.org/D23418
llvm-svn: 299653
A big part of the clone detection code is functionality for filtering clones and
clone groups based on different criteria. So far this filtering process was
hardcoded into the CloneDetector class, which made it hard to understand and,
ultimately, to extend.
This patch splits the CloneDetector's logic into a sequence of reusable
constraints that are used for filtering clone groups. These constraints
can be turned on and off and reodreder at will, and new constraints are easy
to implement if necessary.
Unit tests are added for the new constraint interface.
This is a refactoring patch - no functional change intended.
Patch by Raphael Isemann!
Differential Revision: https://reviews.llvm.org/D23418
llvm-svn: 299544
Summary:
The alpha.core.Conversion was too strict about compound assignments and could warn even though there is no problem.
Differential Revision: https://reviews.llvm.org/D25596
llvm-svn: 299523
If the value is known, but we cannot increment it, conjure a symbol to
represent the result of the operation based on the operator expression,
not on the sub-expression.
In particular, no longer crash on comparing a result of a LocAsInteger increment
to a constant integer.
rdar://problem/31067356
Differential Revision: https://reviews.llvm.org/D31289
llvm-svn: 298927
Adjustments should be considered properly; we should copy the unadjusted object
over the whole temporary base region. If the unadjusted object is no longer
available in the Environment, invalidate the temporary base region, and then
copy the adjusted object into the adjusted sub-region of the temporary region.
This fixes a regression introduced by r288263, that caused various
false positives, due to copying only adjusted object into the adjusted region;
the rest of the base region therefore remained undefined.
Before r288263, the adjusted value was copied over the unadjusted region,
which is incorrect, but accidentally worked better due to how region store
disregards compound value bindings to non-base regions.
An additional test machinery is introduced to make sure that despite making
two binds, we only notify checkers once for both of them, without exposing
the partially copied objects.
This fix is a hack over a hack. The proper fix would be to model C++ temporaries
in the CFG, and after that dealing with adjustments would no longer be
necessary, and the values we need would no longer disappear from the
Environment.
rdar://problem/30658168
Differential Revision: https://reviews.llvm.org/D30534
llvm-svn: 298924
The checker currently warns on copying, moving, or calling methods on an object
that was recently std::move'd from. It understands a set of "state reset"
methods that bring a moved-from object back to a well-specified state.
Patch by Peter Szecsi!
Differential Revision: https://reviews.llvm.org/D24246
llvm-svn: 298698
It looks like on some host-triples the result of a valist related expr can be
a LazyCompoundVal. Handle that case in the check.
Patch by Abramo Bagnara!
llvm-svn: 297619
We have several reports of false positives coming from libc++. For example,
there are reports of false positives in std::regex, std::wcout, and also
a bunch of issues are reported in https://reviews.llvm.org/D30593. In many
cases, the analyzer trips over the complex libc++ code invariants. Let's turn
off the reports coming from these headers until we can re-evalate the support.
We can turn this back on once we individually suppress all known false
positives and perform deeper evaluation on large codebases that use libc++.
We'd also need to commit to doing these evaluations regularly as libc++
headers change.
Differential Revision: https://reviews.llvm.org/D30798
llvm-svn: 297429
Some of the magic functions take arguments of arbitrary type. However,
for semantic correctness, the compiler still requires a declaration
of these functions with the correct type. Since C does not have
argument-type-overloaded function, this made those functions hard to
use in C code. Improve this situation by allowing arbitrary suffixes
in the affected magic functions' names, thus allowing the user to
create different declarations for different types.
A patch by Keno Fischer!
Differential Revision: https://reviews.llvm.org/D30589
llvm-svn: 297325
Add a bug visitor to the taint checker to make it easy to distinguish where
the tainted value originated. This is especially useful when the original
taint source is obscured by complex data flow.
A patch by Vlad Tsyrklevich!
Differential Revision: https://reviews.llvm.org/D30289
llvm-svn: 297324
This patch makes the valist check more robust to the different AST variants on
different platforms and also fixes a FIXME.
Differential Revision: https://reviews.llvm.org/D30157
llvm-svn: 297153
Summary:
The changes contained in this patch are:
1. Defines a new AST node `CoawaitDependentExpr` for representing co_await expressions while the promise type is still dependent.
2. Correctly detect and transform the 'co_await' operand to `p.await_transform(<expr>)` when possible.
3. Change the initial/final suspend points to build during the initial parse, so they have the correct operator co_await lookup results.
4. Fix transformation of the CoroutineBodyStmt so that it doesn't re-build the final/initial suspends.
@rsmith: This change is a little big, but it's not trivial for me to split it up. Please let me know if you would prefer this submitted as multiple patches.
Reviewers: rsmith, GorNishanov
Reviewed By: rsmith
Subscribers: ABataev, rsmith, mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D26057
llvm-svn: 297093
* ExprEngine assumes that OpenMP statements should never appear in CFG.
However, current CFG doesn't know anything about OpenMP and passes
such statements as CFG nodes causing "UNREACHABLE executed!" crashes.
Since there is no OpenMP implementation in ExprEngine or CFG,
we stop the analysis on OpenMP statements to avoid crashes.
This fixes PR31835.
Differential Revision: https://reviews.llvm.org/D30565
llvm-svn: 296884
In the following code involving GNU statement-expression extension:
struct S {
~S();
};
void foo() {
const S &x = ({ return; S(); });
}
function 'foo()' returns before reference x is initialized. We shouldn't call
the destructor for the temporary object lifetime-extended by 'x' in this case,
because the object never gets constructed in the first place.
The real problem is probably in the CFG somewhere, so this is a quick-and-dirty
hotfix rather than the perfect solution.
A patch by Artem Dergachev!
rdar://problem/30759076
Differential Revision: https://reviews.llvm.org/D30499
llvm-svn: 296646
Fix a crash in the ObjCPropertyChecker when analyzing a 'copy' property of an
NSMutable* type in a protocol.
rdar://problem/30766684
Differential Revision: https://reviews.llvm.org/D30482
llvm-svn: 296562
Summary: SimpleConstraintManager is difficult to use, and makes assumptions about capabilities of the constraint manager. This patch refactors out those portions into a new RangedConstraintManager, and also fixes some issues with camel case, formatting, and confusing naming.
Reviewers: zaks.anna, dcoughlin
Subscribers: mgorny, xazax.hun, NoQ, rgov, cfe-commits
Differential Revision: https://reviews.llvm.org/D26061
llvm-svn: 296242
During the review of D29567 it turned out the caching in CallDescription is not implemented properly. In case an identifier does not exist in a translation unit, repeated identifier lookups will be done which might have bad impact on the performance. This patch guarantees that the lookup is only executed once. Moreover this patch fixes a corner case when the identifier of CallDescription does not exist in the translation unit and the called function does not have an identifier (e.g.: overloaded operator in C++).
Differential Revision: https://reviews.llvm.org/D29884
llvm-svn: 295186
Summary:
In VirtualCallChecker, handle indirect calls.
getDirectCallee() can be nullptr, and dyn_cast(nullptr) is UB
Reviewers: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D29303
llvm-svn: 293604
This is an attempt to avoid new false positives caused by the reverted r292800,
however the scope of the fix is significantly reduced - some variables are still
in incorrect memory spaces.
Relevant test cases added.
rdar://problem/30105546
rdar://problem/30156693
Differential revision: https://reviews.llvm.org/D28946
llvm-svn: 293043
This reverts commit r292800.
It is causing null pointer dereference false positives when a block that
captures a static local is evaluated at the top level.
llvm-svn: 292874
When a block within a function accesses a function's static local variable,
this local is captured by reference rather than copied to the heap.
Therefore this variable's memory space is known: StaticGlobalSpaceRegion.
Used to be UnknownSpaceRegion, same as for stack locals.
Fixes a false positive in MacOSXAPIChecker.
rdar://problem/30105546
Differential revision: https://reviews.llvm.org/D28946
llvm-svn: 292800
This patch adds LocationContext to checkRegionChanges and removes
wantsRegionChangeUpdate as it was unused.
A patch by Krzysztof Wiśniewski!
Differential Revision: https://reviews.llvm.org/D27090
llvm-svn: 291869
The checker has several false positives that this patch addresses:
- Do not check if the return status has been compared to error (or no error) at the time when leaks are reported since the status symbol might no longer be alive. Instead, pattern match on the assume and stop tracking allocated symbols on error paths.
- The checker used to report error when an unknown symbol was freed. This could lead to false positives, let's not repot those. This leads to loss of coverage in double frees.
- Do not enforce that we should only call free if we are sure that error was not returned and the pointer is not null. That warning is too noisy and we received several false positive reports about it. (I removed: "Only call free if a valid (non-NULL) buffer was returned")
- Use !isDead instead of isLive in leak reporting. Otherwise, we report leaks for objects we loose track of. This change triggered change #1.
This also adds checker specific dump to the state.
Differential Revision: https://reviews.llvm.org/D28330
llvm-svn: 291866
This replaces the hack in r291754, which was fixing pr31592, which was
caused by r291754, with a more appropriate solution.
rdar://problem/28832541
Differential revision: https://reviews.llvm.org/D28602
llvm-svn: 291781
A hotfix for pr31592 that fixes the crash but not the root cause of the problem.
We need to update the analyzer engine further to account for AST changes
introduced in r289618. At the moment we're erroneously performing a redundant
lvalue-to-rvalue cast in this scenario, and squashing the rvalue of the object
bound to the reference into the reference itself.
rdar://problem/28832541
llvm-svn: 291754
Sema treats pointers to static member functions as having function pointer
type, so treat treat them as function pointer values in the analyzer as well.
This prevents an assertion failure in SValBuilder::evalBinOp caused by code
that expects function pointers to be Locs (in contrast, PointerToMember values
are nonlocs).
Differential Revision: https://reviews.llvm.org/D28033
llvm-svn: 291581
This patch is to implement sema and parsing for 'target teams distribute simd’ pragma.
Differential Revision: https://reviews.llvm.org/D28252
llvm-svn: 291579
Aleksey Shlypanikov pointed out my mistake in migrating an explicit
unique_ptr to auto - I was expecting the function returned a unique_ptr,
but instead it returned a raw pointer - introducing a leak.
Thanks Aleksey!
This reapplies r291184, reverted in r291249.
llvm-svn: 291270
The one use of CheckerManager (AnalysisConsumer, calling
createCheckerManager) keeps a strong reference to the AnalysisOptions
anyway, so this ownership wasn't necessary.
(I'm not even sure AnalysisOptions needs ref counting at all - but
that's more involved)
llvm-svn: 291017
This patch is to implement sema and parsing for 'target teams distribute parallel for simd’ pragma.
Differential Revision: https://reviews.llvm.org/D28202
llvm-svn: 290862
This patch is to implement sema and parsing for 'target teams distribute parallel for’ pragma.
Differential Revision: https://reviews.llvm.org/D28160
llvm-svn: 290725
This patch is to implement sema and parsing for 'target teams distribute' pragma.
Differential Revision: https://reviews.llvm.org/D28015
llvm-svn: 290508
The patch also simplifies an assume of a constraint of the form: "(exp comparison_op expr) != 0" to true into an assume of "exp comparison_op expr" to true. (And similarly, an assume of the form "(exp comparison_op expr) == 0" to true as an assume of exp comparison_op expr to false.) which improves precision overall.
https://reviews.llvm.org/D22862
llvm-svn: 290505
The patch also simplifies an assume of a constraint of the form: "(exp comparison_op expr) != 0" to true into an assume of "exp comparison_op expr" to true. (And similarly, an assume of the form "(exp comparison_op expr) == 0" to true as an assume of exp comparison_op expr to false.) which improves precision overall.
https://reviews.llvm.org/D22862
llvm-svn: 290413
Update the GTestChecker to tighten up the API detection and make it
cleaner in response to post-commit feedback. Also add tests for when
temporary destructors are enabled to make sure we get the expected behavior
when inlining constructors for temporaries.
llvm-svn: 290352
Warnings with suppress-on-sink are discarded during FlushReports when
BugReporter notices that all paths in ExplodedGraph that pass through the
warning eventually run into a sink node.
However, suppress-on-sink fails to filter out false positives when the analysis
terminates too early - by running into analyzer limits, such as block count
limits or graph size limits - and the interruption hits the narrow window
between throwing the leak report and reaching the no-return function call. In
such case the report is there, however suppression-on-sink doesn't work, because
the sink node was never constructed in the incomplete ExplodedGraph.
This patch implements a very partial solution: also suppress reports thrown
against a statement-node that corresponds to a statement that belongs to a
no-return block of the CFG.
rdar://problem/28832541
Differential Revision: https://reviews.llvm.org/D28023
llvm-svn: 290341
gtest is a widely-used unit-testing API. It provides macros for unit test
assertions:
ASSERT_TRUE(p != nullptr);
that expand into an if statement that constructs an object representing
the result of the assertion and returns when the assertion is false:
if (AssertionResult gtest_ar_ = AssertionResult(p == nullptr))
;
else
return ...;
Unfortunately, the analyzer does not model the effect of the constructor
precisely because (1) the copy constructor implementation is missing from the
the header (so it can't be inlined) and (2) the boolean-argument constructor
is constructed into a temporary (so the analyzer decides not to inline it since
it doesn't reliably call temporary destructors right now).
This results in false positives because the analyzer does not realize that the
the assertion must hold along the non-return path.
This commit addresses the false positives by explicitly modeling the effects
of the two un-inlined constructors on the AssertionResult state.
I've added a new package, "apiModeling", for these kinds of checkers that
model APIs but don't emit any diagnostics. I envision all the checkers in
this package always being on by default.
This addresses the false positives reported in PR30936.
Differential Revision: https://reviews.llvm.org/D27773
rdar://problem/22705813
llvm-svn: 290143
The analyzer's CFG currently doesn't have nodes for calls to temporary
destructors. This causes the analyzer to explore infeasible paths in which
a no-return destructor would have stopped exploration and so results in false
positives when no-return destructors are used to implement assertions.
To mitigate these false positives, this patch stops generates a sink after
evaluating a constructor on a temporary object that has a no-return destructor.
This results in a loss of coverage because the time at which the destructor is
called may be after the time of construction (especially for lifetime-extended
temporaries).
This addresses PR15599.
rdar://problem/29131566
llvm-svn: 290140
Update the UnixAPIChecker to not diagnose for calls to functions that
are declared in C++ namespaces. This avoids false positives when a
namespaced function has the same name as a Unix API.
This address PR28331.
llvm-svn: 290023
This is a big deal for ObjC, where nullability annotations are extensively
used. I've also changed "Null" -> "null" and removed "is" as this is the
pattern that Sema is using.
Differential Revision: https://reviews.llvm.org/D27600
llvm-svn: 289885
When a macro expending to a literal is used in a comparison, use the macro name
in the diagnostic rather than the literal. This improves readability of path
notes.
Added tests for various macro literals that could occur. Only BOOl, Int, and
NULL tests have changed behavior with this patch.
Differential Revision: https://reviews.llvm.org/D27726
llvm-svn: 289884
The more detailed diagnostic will make identifying which object the
diagnostics refer to easier.
Differential Revision: https://reviews.llvm.org/D27740
llvm-svn: 289883
Add a new type of NonLoc SVal for C++ pointer-to-member operations. This SVal
supports both pointers to member functions and pointers to member data.
A patch by Kirill Romanenkov!
Differential Revision: https://reviews.llvm.org/D25475
llvm-svn: 289873
copy constructors of classes with array members, instead using
ArrayInitLoopExpr to represent the initialization loop.
This exposed a bug in the static analyzer where it was unable to differentiate
between zero-initialized and unknown array values, which has also been fixed
here.
llvm-svn: 289618
When an Objective-C property has a (copy) attribute, the default setter
for this property performs a -copy on the object assigned.
Calling -copy on a mutable NS object such as NSMutableString etc.
produces an immutable object, NSString in our example.
Hence the getter becomes type-incorrect.
rdar://problem/21022397
Differential Revision: https://reviews.llvm.org/D27535
llvm-svn: 289554
initialization of each array element:
* ArrayInitLoopExpr is a prvalue of array type with two subexpressions:
a common expression (an OpaqueValueExpr) that represents the up-front
computation of the source of the initialization, and a subexpression
representing a per-element initializer
* ArrayInitIndexExpr is a prvalue of type size_t representing the current
position in the loop
This will be used to replace the creation of explicit index variables in lambda
capture of arrays and copy/move construction of classes with array elements,
and also C++17 structured bindings of arrays by value (which inexplicably allow
copying an array by value, unlike all of C++'s other array declarations).
No uses of these nodes are introduced by this change, however.
llvm-svn: 289413
The VirtualCallChecker is in alpha because its interprocedural diagnostics
represent the call path textually in the diagnostic message rather than with a
path sensitive diagnostic.
This patch turns off the AST-based interprocedural analysis in the checker so
that no call path is needed and improves with diagnostic text. With these
changes, the checker is ready to be moved into the optin package.
Ultimately the right fix is to rewrite this checker to be path sensitive -- but
there is still value in enabling the checker for intraprocedural analysis only
The interprocedural mode can be re-enabled with an -analyzer-config flag.
Differential Revision: https://reviews.llvm.org/D26768
llvm-svn: 289309
This patch is to implement sema and parsing for 'teams distribute parallel for' pragma.
Differential Revision: https://reviews.llvm.org/D27345
llvm-svn: 289179
This function receives a callback block. The analyzer suspects that this block
may be used to take care of releasing the libdispatch object returned from
the function. In fact, it doesn't - it only releases the raw data buffer.
Inform the analyzer about that. Fixes the resulting false negatives.
rdar://problem/22280098
Differential Revision: https://reviews.llvm.org/D27409
llvm-svn: 289047
On a method call, the ObjCGenerics checker uses the type tracked by
DynamicTypePropagation for the receiver to to infer substituted parmeter types
for the called methods and warns when the argument type does not match the
parameter.
Unfortunately, using the tracked type can result in false positives when the
receiver has a non-invariant type parameter and has been intentionally upcast.
For example, becaue NSArray's type parameter is covaraint, the following code
is perfectly safe:
NSArray<NSString *> *allStrings = ...
NSDate *date = ...;
NSArray<NSObject *> *allObjects = allStrings;
NSArray<NSObject *> *moreObjects = [allObjects arrayByAddingObject:date];
but the checker currently warns that the date parameter is not an NSString *.
To avoid this kind of false positive, the checker will now only warn when
the class defining the called method has only invariant type parameters.
rdar://problem/28803951
llvm-svn: 288677
latter case, a temporary array object is materialized, and can be
lifetime-extended by binding a reference to the member access. Likewise, in an
array-to-pointer decay, an rvalue array is materialized before being converted
into a pointer.
This caused IR generation to stop treating file-scope array compound literals
as having static storage duration in some cases in C++; that has been rectified
by modeling such a compound literal as an lvalue. This also improves clang's
compatibility with GCC for those cases.
llvm-svn: 288654
This patch is to implement sema and parsing for 'teams distribute parallel for simd' pragma.
Differential Revision: https://reviews.llvm.org/D27084
llvm-svn: 288294
When constructing a temporary object region, which represents the result of
MaterializeTemporaryExpr, track down the sub-expression for which the temporary
is necessary with a trick similar to the approach used in CodeGen, namely
by using Expr::skipRValueSubobjectAdjustments().
Then, create the temporary object region with type of that sub-expression.
That type would propagate further in a path-sensitive manner.
During destruction of lifetime-extened temporaries, consult the type of
the temporary object region, rather than the type of the lifetime-extending
variable, in order to call the correct destructor (fixes pr17001) and,
at least, not to crash by trying to call a destructor of a plain type
(fixes pr19539).
rdar://problem/29131302
rdar://problem/29131576
Differential Revision: https://reviews.llvm.org/D26839
llvm-svn: 288263
- Fix the bug with transition handling in ExprInspectionChecker's
checkDeadSymbols implementation.
- Test this bug by adding a new function clang_analyzer_numTimesReached() to
catch number of passes through the code, which should be handy for testing
against unintended state splits.
- Add two more functions should help debugging issues quickly without running
the debugger or dumping exploded graphs - clang_analyzer_dump() which dump()s
an SVal argument to a warning message, and clang_analyzer_printState(), which
dump()s the current program state to stderr.
Differential Revision: https://reviews.llvm.org/D26835
llvm-svn: 288257
Because in case of unions we currently default-bind compound values in the
store, this quick fix avoids the crash for this case.
Patch by Ilya Palachev and independently by Alexander Shaposhnikov!
Differential Revision: https://reviews.llvm.org/D26442
llvm-svn: 287618
Remove the check::RegionChanges::wantsRegionChangeUpdate callback as it is no
longer used (since checkPointerEscape has been added).
A patch by Krzysztof Wiśniewski!
Differential Revision: https://reviews.llvm.org/D26759
llvm-svn: 287175
A combination of C++ modules, variadic functions with more than one argument,
and const globals in headers (all three being necessary) causes some releases
of clang to misplace the matcher objects, which causes the linker to fail.
No functional change - the extra allOf() matcher is no-op here.
llvm-svn: 287045
The CallAndMessageChecker has an existing check for when a function pointer
is called with too few arguments. Extend this logic to handle the block
case, as well. While we're at it, do a drive-by grammar correction
("less" --> "fewer") on the diagnostic text.
llvm-svn: 287001
Summary: The name is slightly confusing, since the constraint is not necessarily within the range unless `Assumption` is true. Split out renaming for ConstraintManager.h from D26061
Reviewers: zaks.anna, dcoughlin
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26644
llvm-svn: 286927
Fix a crash when checking parameter nullability on a block invocation
with fewer arguments than the block declaration requires.
rdar://problem/29237566
llvm-svn: 286901
Under automated reference counting the analyzer treats a methods -- even those
starting with 'copy' and friends -- as returning an unowned value. This is
because ownership of CoreFoundation objects must be transferred to ARC
with __bridge_transfer or CFBridgingRelease() before being returned as
ARC-managed bridged objects.
Unfortunately this could lead to a poor diagnostic inside copy methods under
ARC where the analyzer would complain about a leak of a returned CF value inside
a method "whose name does not start with 'copy'" -- even though the name did
start with 'copy'.
This commit improves the diagnostic under ARC to say inside a method "returned
from a method managed by Automated Reference Counting".
rdar://problem/28849667
llvm-svn: 286694
The context argument passed to VideoToolbox's
VTCompressionSessionEncodeFrame() function is ultimately passed to a callback
supplied when creating the compression session and so may be freed by that
callback. To suppress false positives in this case, teach the retain count
checker to stop tracking that argument.
This isn't suppressed by the usual callback context mechanism because the call
to VTCompressionSessionEncodeFrame() doesn't include the callback itself.
rdar://problem/27685213
llvm-svn: 286633
Summary:
This provides a better interface for clang-tidy and encapsulates the knowledge
about experimental checkers instead of leaving this to the clients.
Reviewers: zaks.anna
Subscribers: a.sidorin, NoQ, dcoughlin, cfe-commits
Differential Revision: https://reviews.llvm.org/D26310
llvm-svn: 286218
Because standard functions can be defined differently on different platforms,
this commit introduces a method for constructing summaries with multiple
variants, whichever matches better. It is also useful for supporting overloads.
Differential Revision: https://reviews.llvm.org/D25940
llvm-svn: 285852
Change "use of 'self'..." to "Use of 'self'...". The convention is to
start diagnostics with a capital letter.
rdar://problem/28322494
llvm-svn: 285759
Reading from a garbage pointer should be modeled as garbage,
and performTrivialCopy should be able to deal with any SVal input.
Patch by Ilya Palachev!
Differential Revision: https://reviews.llvm.org/D25727
llvm-svn: 285640
The checker already warns for __block-storage variables being used as a
dispatch_once() predicate, however it refers to them as local which is not quite
accurate, so we fix that.
Differential Revision: https://reviews.llvm.org/D26159
llvm-svn: 285637
Unlike global/static variables, calloc etc. functions that allocate ObjC
objects behave differently in terms of memory barriers, and hacks that make
dispatch_once as fast as it possibly could be start failing.
Differential Revision: https://reviews.llvm.org/D25909
llvm-svn: 285605
__builtin_alloca always uses __BIGGEST_ALIGNMENT__ for the alignment of
the allocation. __builtin_alloca_with_align allows the programmer to
specify the alignment of the allocation.
This fixes PR30658.
llvm-svn: 285544
Support CFNumberRef and OSNumber objects, which may also be accidentally
converted to plain integers or booleans.
Enable explicit boolean casts by default in non-pedantic mode.
Improve handling for warnings inside macros.
Improve error messages.
Differential Revision: https://reviews.llvm.org/D25731
llvm-svn: 285533
This patch contains 2 improvements to the CFNumber checker:
- Checking of CFNumberGetValue misuse.
- Treating all CFNumber API misuse errors as non-fatal. (Previously we treated errors that could cause uninitialized memory as syncs and the truncation errors as non-fatal.)
This implements a subset of functionality from https://reviews.llvm.org/D17954.
Differential Revision: https://reviews.llvm.org/D25876
llvm-svn: 285253
This checker does not emit reports, however it influences the analysis
by providing complete summaries for, or otherwise improving modeling of,
various standard library functions.
This should reduce the number of infeasible paths explored during analysis.
The custom function summary format used in this checker is superior to
body farms by causing less unnecessary state splits,
which would result in better analysis performance.
Differential Revision: https://reviews.llvm.org/D20811
llvm-svn: 284960
In macros, 'do {...} while (0)' is often used. Don't warn about the condition 0 when it is unreachable.
Differential Revision: https://reviews.llvm.org/D25606
llvm-svn: 284477
When dealing with objects that represent numbers, such as Objective-C NSNumber,
the language provides little protection from accidentally interpreting
the value of a pointer to such object as the value of the number represented
by the object. Results of such mis-interpretation may be unexpected.
The checker attempts to fill this gap in cases when the code is obviously
incorrect.
With "Pedantic" option enabled, this checker enforces a coding style to
completely prevent errors of this kind (off by default).
Differential Revision: https://reviews.llvm.org/D22968
llvm-svn: 284473
This reverts commit r284335.
It appears to be causing test-suite compile-time and execution-time
performance measurements to take longer than expected on several bots.
This is surprising, because r284335 is a static-analyzer-only change.
llvm-svn: 284340
Add additional checking to MallocChecker to avoid crashing when memory
routines have unexpected numbers of arguments. You wouldn't expect to see much
of this in normal code (-Wincompatible-library-redeclaration warns on this),
but, for example, CMake tests can generate these.
This is PR30616.
rdar://problem/28631974
llvm-svn: 284335
Revert:
r283662: [analyzer] Re-apply r283093 "Add extra notes to ObjCDeallocChecker"
r283660: [analyzer] Fix build error after r283660 - remove constexpr strings.
It was causing an internal build bot to fail. It looks like in some cases
adding an extra note can cause scan-build plist output to drop a diagnostic
altogether.
llvm-svn: 284317
AST matchers are useful for the analyzer's checkers.
More patches on particular checkers shall follow.
This is the first time clang binary gets linked to ASTMatchers.
The binary size increase for the clang executable would be
+0.5% in release mode, +2% in debug mode.
Differential Revision: https://reviews.llvm.org/D25429
llvm-svn: 284112
On macOS (but not iOS), if an ObjC property has no setter, the nib-loading code
for an IBOutlet is documented as directly setting the backing ivar without
retaining the value -- even if the property is 'retain'.
This resulted in false positives from the DeallocChecker for code that did not
release such ivars in -dealloc.
To avoid these false positives, treat IBOutlet ivars that back a property
without a setter as having an unknown release requirement in macOS.
rdar://problem/28507353
llvm-svn: 284084
The problem that caused the msvc crash has been indentified and fixed
in the previous commit. This patch contains the rest of r283092.
llvm-svn: 283584
Define PathDiagnosticNotePiece. The next commit would be able to address the
BugReport class code that is pointed to by the msvc crash message.
llvm-svn: 283566
Returns when calling an inline function should not be merged in the ExplodedGraph unless they are same.
Differential Revision: https://reviews.llvm.org/D25326
llvm-svn: 283554
Currently if the path diagnostic consumer (e.g HTMLDiagnostics and PlistDiagnostics) do not support cross file diagnostics then the path diagnostic report is silently omitted in the case of cross file diagnostics. The patch adds a little verbosity to Clang in this case.
The patch also adds help entry for the "--analyzer-output" driver option.
llvm-svn: 283499
Logical short-circuit operators now act like other branch conditions.
If the symbolic value of the left-hand side is not known to be true or false
(based on the previous execution path), the "Assuming" event piece is added
in order to explain that the analyzer is adding a new assumption.
Additionally, when the assumption is made against the right-hand side of
the logical operator (i.e. when the operator itself acts as a condition
in another CFG terminator), the "Assuming..." piece is written out for the
right-hand side of the operator rather than for the whole operator.
This allows expression-specific diagnostic message text to be constructed.
Differential Revision: https://reviews.llvm.org/D25092
llvm-svn: 283302
In the analyzer's path-sensitive reports, when a report goes through a branch
and the branch condition cannot be decided to be definitely true or false
(based on the previous execution path), an event piece is added that tells the
user that a new assumption is added upon the symbolic value of the branch
condition. For example, "Assuming 'a' is equal to 3".
The text of the assumption is hand-crafted in various manners depending on
the AST expression. If the AST expression is too complex and the text of
the assumption fails to be constructed, the event piece is omitted.
This causes loss of information and misunderstanding of the report.
Do not omit the event piece even if the expression is too complex;
add a piece with a generic text instead.
Differential Revision: https://reviews.llvm.org/D23300
llvm-svn: 283301
Highlight code clones referenced by the warning message with the help of
the extra notes feature recently introduced in r283092.
Change warning text to more clang-ish. Remove suggestions from the copy-paste
error checker diagnostics, because currently our suggestions are strictly 50%
wrong (we do not know which of the two code clones contains the error), and
for that reason we should not sound as if we're actually suggesting this.
Hopefully a better solution would bring them back.
Make sure the suspicious clone pair structure always mentions
the correct variable for the second clone.
Differential Revision: https://reviews.llvm.org/D24916
llvm-svn: 283094
The report is now highlighting instance variables and properties
referenced by the warning message with the help of the
extra notes feature recently introduced in r283092.
Differential Revision: https://reviews.llvm.org/D24915
llvm-svn: 283093
These diagnostics are separate from the path-sensitive engine's path notes,
and can be added manually on top of path-sensitive or path-insensitive reports.
The new note diagnostics would appear as note:-diagnostic on console and
as blue bubbles in scan-build. In plist files they currently do not appear,
because format needs to be discussed with plist file users.
The analyzer option "-analyzer-config notes-as-events=true" would convert
notes to normal path notes, and put them at the beginning of the path.
This is a temporary hack to show the new notes in plist files.
A few checkers would be updated in subsequent commits,
including tests for this new feature.
Differential Revision: https://reviews.llvm.org/D24278
llvm-svn: 283092
Example:
switch (x) {
int a; // <- This is unreachable but needed
case 1:
a = ...
Differential Revision: https://reviews.llvm.org/D24905
llvm-svn: 282574
This option behaves in a similar spirit as -save-temps and writes
internal llvm statistics in json format to a file.
Differential Revision: https://reviews.llvm.org/D24820
llvm-svn: 282426
The class BodyFarm creates bodies for
OSAtomicCompareAndSwap*, objc_atomicCompareAndSwap*, dispatch_sync*, dispatch_once*
and for them the flag isBodyAutosynthesized is set to true.
This diff
1. makes AnalysisConsumer::HandleCode skip the autosynthesized code
2. replaces assert(LCtx->getParent()) in RetainCountChecker::checkEndFunction
by assert(!LCtx->inTopFrame()) (minor cleanup)
Test plan: make -j8 check-clang-analysis
Differential revision: https://reviews.llvm.org/D24792
llvm-svn: 282293
This checker should find the calls to blocking functions (for example: sleep, getc, fgets,read,recv etc.) inside a critical section. When sleep(x) is called while a mutex is held, other threads cannot lock the same mutex. This might take some time, leading to bad performance or even deadlock.
Example:
mutex_t m;
void f() {
sleep(1000); // Error: sleep() while m is locked! [f() is called from foobar() while m is locked]
// do some work
}
void foobar() {
lock(m);
f();
unlock(m);
}
A patch by zdtorok (Zoltán Dániel Török)!
Differential Revision: https://reviews.llvm.org/D21506
llvm-svn: 282011
ArrayBoundChecker did not detect out of bounds memory access errors in case an
array was allocated by the new expression. This patch resolves this issue.
Patch by Daniel Krupp!
Differential Revision: https://reviews.llvm.org/D24307
llvm-svn: 281934
AST may contain intermediate ParenExpr nodes
between MemberExpr and ArrayToPointerDecay.
This diff adjusts the check in ExprEngine::VisitMemberExpr accordingly.
Test plan: make -j8 check-clang-analysis
Differential revision: https://reviews.llvm.org/D24484
llvm-svn: 281373
For ObjC type parameter, we used to have TypedefType that is canonicalized to
id or the bound type. We can't represent "T <protocol>" and thus will lose
the type information in the following example:
@interface MyMutableDictionary<KeyType, ObjectType> : NSObject
- (void)setObject:(ObjectType)obj forKeyedSubscript:(KeyType <NSCopying>)key;
@end
MyMutableDictionary<NSString *, NSString *> *stringsByString;
NSNumber *n1, *n2;
stringsByString[n1] = n2;
--> no warning on type mismatch of the key.
To fix the problem, we introduce a new type ObjCTypeParamType that supports
a list of protocol qualifiers.
We create ObjCTypeParamType for ObjCTypeParamDecl when we create
ObjCTypeParamDecl. We also substitute ObjCTypeParamType instead of TypedefType
on an ObjCTypeParamDecl.
rdar://24619481
rdar://25060179
Differential Revision: http://reviews.llvm.org/D23080
llvm-svn: 281358
This patch also introduces AnalysisOrderChecker which is intended for testing
of callback call correctness.
Differential Revision: https://reviews.llvm.org/D23804
llvm-svn: 280367
Some FileIDs that may be used by PlistDiagnostics were not added while building
a list of pieces. This caused assertion violation in GetFID() function.
This patch adds some missing FileIDs to avoid the assertion. It also contains
small refactoring of PlistDiagnostics::FlushDiagnosticsImpl().
Patch by Aleksei Sidorin, Ilya Palachev.
Differential Revision: https://reviews.llvm.org/D22090
llvm-svn: 280360
Fix a crash when relexing the underlying memory buffer to find incorrect
arguments to NSLocalizedString(). With precompiled headers, the raw
buffer may be NULL. Instead, use the source manager to get the buffer,
which will lazily create the buffer for precompiled headers.
rdar://problem/27429091
llvm-svn: 280174
This replaces the old approach of fingerprinting every AST node into a string,
which avoided collisions and was simple to implement, but turned out to be
extremely ineffective with respect to both performance and memory.
The collisions are now dealt with in a separate pass, which no longer causes
performance problems because collisions are rare.
Patch by Raphael Isemann!
Differential Revision: https://reviews.llvm.org/D22515
llvm-svn: 279378
We should ignore paren casts when making sure that the semantic expression
in a PseudoObjectExpr for an ObjC getter is a message send.
This has no other intended functionality change.
Adding a test for this exposed an interesting issue in another test case
that only manifests under ARC. trackNullOrUndefValue() is not properly
suppressing for nil values that are the result of nil propagation from a nil
receiver when the nil is returned from a function. I've added a FIXME for that
missing suppression.
rdar://problem/27290568
llvm-svn: 279181
The original clone checker tries to find copy-pasted code that is exactly
identical to the original code, up to minor details.
As an example, if the copy-pasted code has all references to variable 'a'
replaced with references to variable 'b', it is still considered to be
an exact clone.
The new check finds copy-pasted code in which exactly one variable seems
out of place compared to the original code, which likely indicates
a copy-paste error (a variable was forgotten to be renamed in one place).
Patch by Raphael Isemann!
Differential Revision: https://reviews.llvm.org/D23314
llvm-svn: 279056
This reverts commit r279003 as it breaks some of our buildbots (e.g.
clang-cmake-aarch64-quick, clang-x86_64-linux-selfhost-modules).
The error is in OpenMP/teams_distribute_simd_ast_print.cpp:
clang: /home/buildslave/buildslave/clang-cmake-aarch64-quick/llvm/include/llvm/ADT/DenseMap.h:527:
bool llvm::DenseMapBase<DerivedT, KeyT, ValueT, KeyInfoT, BucketT>::LookupBucketFor(const LookupKeyT&, const BucketT*&) const
[with LookupKeyT = clang::Stmt*; DerivedT = llvm::DenseMap<clang::Stmt*, long unsigned int>;
KeyT = clang::Stmt*; ValueT = long unsigned int;
KeyInfoT = llvm::DenseMapInfo<clang::Stmt*>;
BucketT = llvm::detail::DenseMapPair<clang::Stmt*, long unsigned int>]:
Assertion `!KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) &&
"Empty/Tombstone value shouldn't be inserted into map!"' failed.
llvm-svn: 279045
This patch is to implement sema and parsing for 'teams distribute simd’ pragma.
This patch is originated by Carlo Bertolli.
Differential Revision: https://reviews.llvm.org/D23528
llvm-svn: 279003
This new checker tries to find execution paths on which implicit integral casts
cause definite loss of information: a certainly-negative integer is converted
to an unsigned integer, or an integer is definitely truncated to fit into
a smaller type.
Being implicit, such casts are likely to produce unexpected results.
Patch by Daniel Marjamäki!
Differential Revision: https://reviews.llvm.org/D13126
llvm-svn: 278941
Like SymbolConjured, SymbolMetadata also needs to be uniquely
identified by the moment of its birth.
Such moments are coded by the (Statement, LocationContext, Block count) triples.
Each such triple represents the moment of analyzing a statement with a certain
call backtrace, with corresponding CFG block having been entered a given amount
of times during analysis of the current code body.
The LocationContext information was accidentally omitted for SymbolMetadata,
which leads to reincarnation of SymbolMetadata upon re-entering a code body
with a different backtrace; the new symbol is incorrectly unified with
the old symbol, which leads to unsound assumptions.
Patch by Alexey Sidorin!
Differential Revision: https://reviews.llvm.org/D21978
llvm-svn: 278937
Change the retain count checker to treat CoreFoundation-style "CV"-prefixed
reference types from CoreVideo similarly to CoreGraphics types. With this
change, we treat CVFooRetain() on a CVFooRef type as a retain. CVFooRelease()
APIs are annotated as consuming their parameter, so this change prevents false
positives about incorrect decrements of reference counts.
<rdar://problem/27116090>
llvm-svn: 278382
Both -analyze-function and -analyzer-display-progress now share the same
convention for naming functions, which allows discriminating between
methods with the same name in different classes, C++ overloads, and also
presents Objective-C instance and class methods in the convenient notation.
This also allows looking up the name for the particular function you're trying
to restrict analysis to in the -analyzer-display-progress output,
in case it was not instantly obvious.
Differential Revision: https://reviews.llvm.org/D22856
llvm-svn: 278018
This patch adds a command line option to list the checkers that were enabled
by analyzer-checker and not disabled by -analyzer-disable-checker.
It can be very useful to debug long command lines when it is not immediately
apparent which checkers are turned on and which checkers are turned off.
Differential Revision: https://reviews.llvm.org/D23060
llvm-svn: 278006
Dynamic casts are handled relatively well by the static analyzer.
BaseToDerived casts however are treated conservatively. This can cause some
false positives with the NewDeleteLeaks checker.
This patch alters the behavior of BaseToDerived casts. In case a dynamic cast
would succeed use the same semantics. Otherwise fall back to the conservative
approach.
Differential Revision: https://reviews.llvm.org/D23014
llvm-svn: 277989
Correct two comments that do not match the current behavior of the checker.
A patch by Alexander Droste!
Differential Revision: https://reviews.llvm.org/D22670
llvm-svn: 277547
Add new APIs that require localized strings and remove two APIs that were
incorrectly marked as requiring a user-facing string.
A patch by Kulpreet Chilana!
Differential Revision: https://reviews.llvm.org/D22926
llvm-svn: 277273
Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type.
This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer.
Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions.
This patch is partially based on Alexey Sotkin's work in Khronos Clang (3d4eec6162).
Differential Revision: https://reviews.llvm.org/D21567
llvm-svn: 277024
This patch adds the CloneDetector class which allows searching source code
for clones.
For every statement or group of statements within a compound statement,
CloneDetector computes a hash value, and finds clones by detecting
identical hash values.
This initial patch only provides a simple hashing mechanism
that hashes the kind of each sub-statement.
This patch also adds CloneChecker - a simple static analyzer checker
that uses CloneDetector to report copy-pasted code.
Patch by Raphael Isemann!
Differential Revision: https://reviews.llvm.org/D20795
llvm-svn: 276782
Summary:
This patch moves the MPIFunctionClassifier header to `clang/include/clang/StaticAnalyzer/Checkers`,
in order to make it accessible in other parts of the architecture.
Reviewers: dcoughlin, zaks.anna
Subscribers: alexfh, cfe-commits
Patch by Alexander Droste!
Differential Revision: https://reviews.llvm.org/D22671
llvm-svn: 276639
Remove some FIXMEs in the surrounding code,
which have been addressed long time ago
by introducing checker-specific tags.
Differential Revision: https://reviews.llvm.org/D22622
llvm-svn: 276557
This checker checks copy and move assignment operators whether they are
protected against self-assignment. Since C++ core guidelines discourages
explicit checking for `&rhs==this` in general we take a different approach: in
top-frame analysis we branch the exploded graph for two cases, where &rhs==this
and &rhs!=this and let existing checkers (e.g. unix.Malloc) do the rest of the
work. It is important that we check all copy and move assignment operator in top
frame even if we checked them already since self-assignments may happen
undetected even in the same translation unit (e.g. using random indices for an
array what may or may not be the same).
This reapplies r275820 after fixing a string-lifetime issue discovered by the
bots.
A patch by Ádám Balogh!
Differential Revision: https://reviews.llvm.org/D19311
llvm-svn: 276365
This checker checks copy and move assignment operators whether they are
protected against self-assignment. Since C++ core guidelines discourages
explicit checking for `&rhs==this` in general we take a different approach: in
top-frame analysis we branch the exploded graph for two cases, where &rhs==this
and &rhs!=this and let existing checkers (e.g. unix.Malloc) do the rest of the
work. It is important that we check all copy and move assignment operator in top
frame even if we checked them already since self-assignments may happen
undetected even in the same translation unit (e.g. using random indices for an
array what may or may not be the same).
A patch by Ádám Balogh!
Differential Revision: https://reviews.llvm.org/D19311
llvm-svn: 275820
This patch adds a new AST node: ObjCAvailabilityCheckExpr, and teaches the
Parser and Sema to generate it. This node represents an availability check of
the form:
@available(macos 10.10, *);
Which will eventually compile to a runtime check of the host's OS version. This
is the first patch of the feature I proposed here:
http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html
Differential Revision: https://reviews.llvm.org/D22171
llvm-svn: 275654
This patch is to implement sema and parsing for 'target parallel for simd' pragma.
Differential Revision: http://reviews.llvm.org/D22096
llvm-svn: 275365
This encourages checkers to make logical decisions depending on
value of which region was the symbol under consideration
introduced to denote.
A similar technique is already used in a couple of checkers;
they were modified to call the new method.
Differential Revision: http://reviews.llvm.org/D22242
llvm-svn: 275290
This proposed patch adds crude handling of atomics to the static analyzer.
Rather than ignore AtomicExprs, as we now do, this patch causes the analyzer
to escape the arguments. This is imprecise -- and we should model the
expressions fully in the future -- but it is less wrong than ignoring their
effects altogether.
This is rdar://problem/25353187
Differential Revision: http://reviews.llvm.org/D21667
llvm-svn: 274816
The analyzer does not model C++ temporary destructors completely and so
reports false alarms about leaks of memory allocated by the internals of
shared_ptr:
std::shared_ptr<int> p(new int(1));
p = nullptr; // 'Potential leak of memory pointed to by field __cntrl_'
This patch suppresses all diagnostics where the end of the path is inside
a method in std::shared_ptr.
It also reorganizes the tests for suppressions in the C++ standard library
to use a separate simulated header for library functions with bugs
that were deliberately inserted to test suppression. This will prevent
other tests from using these as models.
rdar://problem/23652766
llvm-svn: 274691
Summary: This patch is an implementation of sema and parsing for the OpenMP composite pragma 'distribute simd'.
Differential Revision: http://reviews.llvm.org/D22007
llvm-svn: 274604
Summary: This patch is an implementation of sema and parsing for the OpenMP composite pragma 'distribute parallel for simd'.
Differential Revision: http://reviews.llvm.org/D21977
llvm-svn: 274530
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
llvm-svn: 274049
[OpenMP] Initial implementation of parse and sema for composite pragma 'distribute parallel for'
This patch is an initial implementation for #distribute parallel for.
The main differences that affect other pragmas are:
The implementation of 'distribute parallel for' requires blocking of the associated loop, where blocks are "distributed" to different teams and iterations within each block are scheduled to parallel threads within each team. To implement blocking, sema creates two additional worksharing directive fields that are used to pass the team assigned block lower and upper bounds through the outlined function resulting from 'parallel'. In this way, scheduling for 'for' to threads can use those bounds.
As a consequence of blocking, the stride of 'distribute' is not 1 but it is equal to the blocking size. This is returned by the runtime and sema prepares a DistIncrExpr variable to hold that value.
As a consequence of blocking, the global upper bound (EnsureUpperBound) expression of the 'for' is not the original loop upper bound (e.g. in for(i = 0 ; i < N; i++) this is 'N') but it is the team-assigned block upper bound. Sema creates a new expression holding the calculation of the actual upper bound for 'for' as UB = min(UB, PrevUB), where UB is the loop upper bound, and PrevUB is the team-assigned block upper bound.
llvm-svn: 273884
http://reviews.llvm.org/D21564
This patch is an initial implementation for #distribute parallel for.
The main differences that affect other pragmas are:
The implementation of 'distribute parallel for' requires blocking of the associated loop, where blocks are "distributed" to different teams and iterations within each block are scheduled to parallel threads within each team. To implement blocking, sema creates two additional worksharing directive fields that are used to pass the team assigned block lower and upper bounds through the outlined function resulting from 'parallel'. In this way, scheduling for 'for' to threads can use those bounds.
As a consequence of blocking, the stride of 'distribute' is not 1 but it is equal to the blocking size. This is returned by the runtime and sema prepares a DistIncrExpr variable to hold that value.
As a consequence of blocking, the global upper bound (EnsureUpperBound) expression of the 'for' is not the original loop upper bound (e.g. in for(i = 0 ; i < N; i++) this is 'N') but it is the team-assigned block upper bound. Sema creates a new expression holding the calculation of the actual upper bound for 'for' as UB = min(UB, PrevUB), where UB is the loop upper bound, and PrevUB is the team-assigned block upper bound.
llvm-svn: 273705
During the core analysis, ExplodedNodes are added to the
ExplodedGraph, and those nodes are cached for deduplication purposes.
After core analysis, reports are generated. Here, trimmed copies of
the ExplodedGraph are made. Since the ExplodedGraph has already been
deduplicated, there is no need to deduplicate again.
This change makes it possible to add ExplodedNodes to an
ExplodedGraph without the overhead of deduplication. "Uncached" nodes
also cannot be iterated over, but none of the report generation code
attempts to iterate over all nodes. This change reduces the analysis
time of a large .C file from 3m43.941s to 3m40.256s (~1.6% speedup).
It should slightly reduce memory consumption. Gains should be roughly
proportional to the number (and path length) of static analysis
warnings.
This patch enables future work that should remove the need for an
InterExplodedGraphMap inverse map. I plan on using the (now unused)
ExplodedNode link to connect new nodes to the original nodes.
http://reviews.llvm.org/D21229
llvm-svn: 273572
Like with SenTestCase, subclasses of XCTestCase follow a "tear down" idiom to
release instance variables and so typically do not release ivars in -dealloc.
This commit applies the existing special casing for SenTestCase to XCTestCase
as well.
rdar://problem/25884696
llvm-svn: 273441
Teach trackNullOrUndefValue() how to properly look through PseudoObjectExprs
to find the underlying semantic method call for property getters. This fixes a
crash when looking through class property getters that I introduced in r265839.
rdar://problem/26796666
llvm-svn: 273340
classes.
MSVC actively uses unqualified lookup in dependent bases, lookup at the
instantiation point (non-dependent names may be resolved on things
declared later) etc. and all this stuff is the main cause of
incompatibility between clang and MSVC.
Clang tries to emulate MSVC behavior but it may fail in many cases.
clang could store lexed tokens for member functions definitions within
ClassTemplateDecl for later parsing during template instantiation.
It will allow resolving many possible issues with lookup in dependent
base classes and removing many already existing MSVC-specific
hacks/workarounds from the clang code.
llvm-svn: 272774
This is a speculative attempt to fix the compiler error: "list initialization inside
member initializer list or non-static data member initializer is not implemented" with
r272529.
llvm-svn: 272530
This commit adds a static analysis checker to verify the correct usage of the MPI API in C
and C++. This version updates the reverted r271981 to fix a memory corruption found by the
ASan bots.
Three path-sensitive checks are included:
- Double nonblocking: Double request usage by nonblocking calls without intermediate wait
- Missing wait: Nonblocking call without matching wait.
- Unmatched wait: Waiting for a request that was never used by a nonblocking call
Examples of how to use the checker can be found at https://github.com/0ax1/MPI-Checker
A patch by Alexander Droste!
Reviewers: zaks.anna, dcoughlin
Differential Revision: http://reviews.llvm.org/D21081
llvm-svn: 272529
Rehashing the ExplodedNode table is very expensive. The hashing
itself is expensive, and the general activity of iterating over the
hash table is highly cache unfriendly. Instead, we guess at the
eventual size by using the maximum number of steps allowed. This
generally avoids a rehash. It is possible that we still need to
rehash if the backlog of work that is added to the worklist
significantly exceeds the number of work items that we process. Even
if we do need to rehash in that scenario, this change is still a
win, as we still have fewer rehashes that we would have prior to
this change.
For small work loads, this will increase the memory used. For large
work loads, it will somewhat reduce the memory used. Speed is
significantly increased. A large .C file took 3m53.812s to analyze
prior to this change. Now it takes 3m38.976s, for a ~6% improvement.
http://reviews.llvm.org/D20933
llvm-svn: 272394
Second try at reapplying
"[analyzer] Add checker for correct usage of MPI API in C and C++."
Special thanks to Dan Liew for helping test the fix for the template
specialization compiler error with gcc.
The original patch is by Alexander Droste!
Differential Revision: http://reviews.llvm.org/D12761
llvm-svn: 271977
Reapply r271907 with a fix for the compiler error with gcc about specializing
clang::ento::ProgramStateTrait in a different namespace.
Differential Revision: http://reviews.llvm.org/D12761
llvm-svn: 271914
This commit adds a static analysis checker to check for the correct usage of the
MPI API in C and C++.
3 path-sensitive checks are included:
- Double nonblocking: Double request usage by nonblocking calls
without intermediate wait.
- Missing wait: Nonblocking call without matching wait.
- Unmatched wait: Waiting for a request that was never used by a
nonblocking call.
Examples of how to use the checker can be found
at https://github.com/0ax1/MPI-Checker
Reviewers: zaks.anna
A patch by Alexander Droste!
Differential Revision: http://reviews.llvm.org/D12761
llvm-svn: 271907
Summary:
This patch is to add parsing and sema support for `target update` directive. Support for the `to` and `from` clauses will be added by a different patch. This patch also adds support for other clauses that are already implemented upstream and apply to `target update`, e.g. `device` and `if`.
This patch is based on the original post by Kelvin Li.
Reviewers: hfinkel, carlo.bertolli, kkwli0, arpith-jacob, ABataev
Subscribers: caomhin, cfe-commits
Differential Revision: http://reviews.llvm.org/D15944
llvm-svn: 270878
Summary:
Leaking a stack address via a static variable refers to it in the diagnostic as a 'global'. This patch corrects the diagnostic for static variables.
Patch by Phil Camp, SN Systems
Reviewers: dcoughlin, zaks.anna
Subscribers: xazax.hun, cfe-commits
Differential Revision: http://reviews.llvm.org/D19866
Patch by Phil Camp
llvm-svn: 270849
The function strcmp() can return any value, not just {-1,0,1} : "The strcmp(const char *s1, const char *s2) function returns an integer greater than, equal to, or less than zero, accordingly as the string pointed to by s1 is greater than, equal to, or less than the string pointed to by s2." [C11 7.24.4.2p3]
https://llvm.org/bugs/show_bug.cgi?id=23790http://reviews.llvm.org/D16317
llvm-svn: 270154
Fix a crash in the generics checker where DynamicTypePropagation tries
to get the superclass of a root class.
This is a spot-fix for a deeper issue where the checker makes assumptions
that may not hold about subtyping between the symbolically-tracked type of
a value and the compile-time types of a cast on that value.
I've added a TODO to address the underlying issue.
rdar://problem/26086914
llvm-svn: 269227
If an address of a field is passed through a const pointer,
the whole structure's base region should receive the
TK_PreserveContents trait and avoid invalidation.
Additionally, include a few FIXME tests shown up during testing.
Differential Revision: http://reviews.llvm.org/D19057
llvm-svn: 267413
Update the nullability checker to allow an explicit cast to nonnull to
suppress a warning on an assignment of nil to a nonnull:
id _Nonnull x = (id _Nonnull)nil; // no-warning
This suppression as already possible for diagnostics on returns and
function/method arguments.
rdar://problem/25381178
llvm-svn: 266219
Treat a _Nonnull ivar that is nil as an invariant violation in a similar
fashion to how a nil _Nonnull parameter is treated as a precondition violation.
This avoids warning on defensive returns of nil on defensive internal
checks, such as the following common idiom:
@class InternalImplementation
@interface PublicClass {
InternalImplementation * _Nonnull _internal;
}
-(id _Nonnull)foo;
@end
@implementation PublicClass
-(id _Nonnull)foo {
if (!_internal)
return nil; // no-warning
return [_internal foo];
}
@end
rdar://problem/24485171
llvm-svn: 266157
The nullability checker can sometimes miss detecting nullability precondition
violations in inlined functions because the binding for the parameter
that violated the precondition becomes dead before the return:
int * _Nonnull callee(int * _Nonnull p2) {
if (!p2)
// p2 becomes dead here, so binding removed.
return 0; // warning here because value stored in p2 is symbolic.
else
return p2;
}
int *caller(int * _Nonnull p1) {
return callee(p1);
}
The fix, which is quite blunt, is to not warn about null returns in inlined
methods/functions. This won’t lose much coverage for ObjC because the analyzer
always analyzes each ObjC method at the top level in addition to inlined. It
*will* lose coverage for C — but there aren’t that many codebases with C
nullability annotations.
rdar://problem/25615050
llvm-svn: 266109
Don't emit a path note marking the return site if the return statement does not
have a valid location. This fixes an assertion failure I introduced in r265839.
llvm-svn: 266031
Teach trackNullOrUndefValue() how to look through PseudoObjectExprs to find
the underlying method call for property getters. This makes over-suppression
of 'return nil' in getters consistent with the similar over-suppression for
method and function calls.
rdar://problem/24437252
llvm-svn: 265839
In ObjCMethodCall:getRuntimeDefinition(), if the method is an accessor in a
category, and it doesn't have a self declaration, first try to find the method
in a class extension. This works around a bug in Sema where multiple accessors
are synthesized for properties in class extensions that are redeclared in a
category. The implicit parameters are not filled in for the method on the
category, which causes a crash when trying to synthesize a getter for the
property in BodyFarm. The Sema bug is tracked as rdar://problem/25481164.
rdar://problem/25056531
llvm-svn: 265103
In case the (uniqueing) location of the diagnostic is in a line that only
contains whitespaces there was an assertion fail during issue hash generation.
Unfortunately I am unable to reproduce this error with the built in checkers,
so no there is no failing test case with this patch. It would be possible to
write a debug checker for that purpuse but it does not worth the effort.
Differential Revision: http://reviews.llvm.org/D18210
llvm-svn: 264851
Change the nullability checker to not warn along paths where null is returned from
a method with a non-null return type, even when the diagnostic for this return
has been suppressed. This prevents warning from methods with non-null return types
that inline methods that themselves return nil but that suppressed the diagnostic.
Also change the PreconditionViolated state component to be called "InvariantViolated"
because it is set when a post-condition is violated, as well.
rdar://problem/25393539
llvm-svn: 264647
The -dealloc method in CIFilter is highly unusual in that it will release
instance variables belonging to its *subclasses* if the variable name
starts with "input" or backs a property whose name starts with "input".
Subclasses should not release these ivars in their own -dealloc method --
doing so could result in an over release.
Before this commit, the DeallocChecker would warn about missing releases for
such "input" properties -- which could cause users of the analyzer to add
over releases to silence the warning.
To avoid this, DeallocChecker now treats CIFilter "input-prefixed" ivars
as MustNotReleaseDirectly and so will not require a release. Further, it
will now warn when such an ivar is directly released in -dealloc.
rdar://problem/25364901
llvm-svn: 264463
The range here isn't over references, so using `auto &` here incites a
copy. Switching to `auto *` would do, but we might as well list an
explicit type for clarity.
Found by -Wrange-loop-analysis.
llvm-svn: 264071
Add the wide character strdup variants (wcsdup, _wcsdup) and the MSVC
version of alloca (_alloca) and other differently named function used
by the Malloc checker.
A patch by Alexander Riccio!
Differential Revision: http://reviews.llvm.org/D17688
llvm-svn: 262894
Add an -analyzer-config 'nullability:NoDiagnoseCallsToSystemHeaders' option to
the nullability checker. When enabled, this option causes the analyzer to not
report about passing null/nullable values to functions and methods declared
in system headers.
This option is motivated by the observation that large projects may have many
nullability warnings. These projects may find warnings about nullability
annotations that they have explicitly added themselves higher priority to fix
than warnings on calls to system libraries.
llvm-svn: 262763
In dealloc methods, the analyzer now warns when -dealloc is called directly on
a synthesized retain/copy ivar instead of -release. This is intended to find mistakes of
the form:
- (void)dealloc {
[_ivar dealloc]; // Mistaken call to -dealloc instead of -release
[super dealloc];
}
rdar://problem/16227989
llvm-svn: 262729
This prevents false negatives when a -dealloc method, for example, removes itself as
as an observer with [[NSNotificationCenter defaultCenter] removeObserver:self]. It is
unlikely that passing 'self' to a system header method will release 'self''s instance
variables, so this is unlikely to produce false positives.
A challenge here is that while CheckObjCDealloc no longer treats these calls as
escaping, the rest of the analyzer still does. In particular, this means that loads
from the same instance variable before and after a call to a system header will
result in different symbols being loaded by the region store. To account for this,
the checker now treats different ivar symbols with the same instance and ivar decl as
the same for the purpose of release checking and more eagerly removes a release
requirement when an instance variable is assumed to be nil. This was not needed before
because when an ivar escaped its release requirement was always removed -- now the
requirement is not removed for calls to system headers.
llvm-svn: 262261
Change "use of 'self' after it has been freed with call to [super dealloc]" to
"use of 'self' after it has been deallocated" and "use of instance variable
'_ivar' after the instance has been freed with call to [super dealloc]" to
"use of instance variable '_ivar' after 'self' has been deallocated".
llvm-svn: 261945
Referring to 'self' after a call to [super dealloc] is a use-after-free in
Objective-C because NSObject's -dealloc frees the memory pointed to by self.
This patch extends the ObjCSuperDeallocChecker to catch this error.
rdar://problem/6953275
Differential Revision: http://reviews.llvm.org/D17528
llvm-svn: 261935
This reapplies "[analyzer] Make ObjCDeallocChecker path sensitive." (r261917)
with a fix for an error on some bots about specializing a template
from another namespace.
llvm-svn: 261929
Convert the ObjCDeallocChecker to be path sensitive. The primary
motivation for this change is to prevent false positives when -dealloc calls
helper invalidation methods to release instance variables, but it additionally
improves precision when -dealloc contains control flow. It also reduces the need
for pattern matching. The check for missing -dealloc methods remains AST-based.
Part of rdar://problem/6927496
Differential Revision: http://reviews.llvm.org/D17511
llvm-svn: 261917
This patch is intended to improve pointer arithmetic checker.
From now on it only warns when the pointer arithmetic is likely to cause an
error. For example when the pointer points to a single object, or an array of
derived types.
Differential Revision: http://reviews.llvm.org/D14203
llvm-svn: 261632
Add an alpha path checker that warns about duplicate calls to [super dealloc].
This will form the foundation of a checker that will detect uses of
'self' after calling [super dealloc].
Part of rdar://problem/6953275.
Based on a patch by David Kilzer!
Differential Revision: http://reviews.llvm.org/D5238
llvm-svn: 261545
Add a checker callback that is called when the analyzer starts analyzing a
function either at the top level or when inlined. This will be used by a
follow-on patch making the DeallocChecker path sensitive.
Differential Revision: http://reviews.llvm.org/D17418
llvm-svn: 261293
When modeling a call to a setter for a property that is synthesized to be
backed by an instance variable, don't invalidate the entire instance
but rather only the storage for the updated instance variable itself.
This still doesn't model the effect of the setter completely. It doesn't
bind the set value to the ivar storage location because doing so would cause
the set value to escape, removing valuable diagnostics about potential
leaks of the value from the retain count checker.
llvm-svn: 261243
r260925 introduced a version of the *trim methods which is preferable
when trimming a single kind of character. Update all users in clang.
llvm-svn: 260927
Look through PseudoObjectExpr and OpaqueValueExprs when scanning for
release-like operations. This commit also adds additional tests in anticipation
of re-writing this as a path-sensitive checker.
llvm-svn: 260608
Now that the libcpp implementations of these methods has a branch that doesn't call
memmove(), the analyzer needs to invalidate the destination for these methods explicitly.
rdar://problem/23575656
llvm-svn: 260043
It is common for the ivars for read-only assign properties to always be stored retained,
so don't warn for a release in dealloc for the ivar backing these properties.
llvm-svn: 259998
If the class or method name case-insensitively contains the term "debug",
suppress warnings about string constants flowing to user-facing UI APIs.
llvm-svn: 259875
Summary:
This patch adds parsing + sema for the target parallel for directive along with testcases.
Reviewers: ABataev
Differential Revision: http://reviews.llvm.org/D16759
llvm-svn: 259654
-analyzer-display progress option prints only function names which may be ambiguous. This patch forces AnalysisConsumer to print fully-qualified function names.
Patch by Alex Sidorin!
Differential Revision: http://reviews.llvm.org/D16804
llvm-svn: 259646
These sets perform linear searching in small mode so it is never a good
idea to use SmallSize/N bigger than 32.
Differential Revision: http://reviews.llvm.org/D16705
llvm-svn: 259284
We already do this for case splits introduced as a result of defensive null
checks in functions and methods, so do the same for function-like macros.
rdar://problem/19640441
llvm-svn: 259222
- Include the position of the argument on which the nullability is violated
- Differentiate between a 'method' and a 'function' in the message wording
- Test for the error message text in the tests
- Fix a bug with setting 'IsDirectDereference' which resulted in regular dereferences assumed to have call context.
llvm-svn: 259221
PropertyMap used to map IdentifierInfo (name of the property) to
ObjcPropertyDecl *. Now that a class property can have the same name as
an instance property, we change PropertyMap to map a pair <IdentifierInfo *,
unsigned> to ObjcPropertyDecl *.
Also update a few places from iterating over instance_properties to
iterating over all properties.
rdar://23891898
llvm-svn: 259119
There are multiple, common idioms of defensive nil-checks in copy,
mutableCopy, and init methods in ObjC. The analyzer doesn't currently have the
capability to distinguish these idioms from true positives, so suppress all
warnings about returns in those families. This is a pretty blunt suppression
that we should improve later.
rdar://problem/24395811
llvm-svn: 259099
Previously the ObjC Dealloc Checker only checked classes with ivars, not
retained properties, which caused three bugs:
- False positive warnings about a missing -dealloc method in classes with only
ivars.
- Missing warnings about a missing -dealloc method on classes with only
properties.
- Missing warnings about an over-released or under-released ivar associated with
a retained property in classes with only properties.
The fix is to check only classes with at least one retained synthesized
property.
This also exposed a bug when reporting an over-released or under-released
property that did not contain a synthesize statement. The checker tried to
associate the warning with an @synthesize statement that did not exist, which
caused an assertion failure in debug builds. The fix is to fall back to the
@property statement in this case.
A patch by David Kilzer!
Part of rdar://problem/6927496
Differential Revision: http://reviews.llvm.org/D5023
llvm-svn: 258896
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"This is the way [autoconf] ends
Not with a bang but a whimper."
-T.S. Eliot
Reviewers: chandlerc, grosbach, bob.wilson, echristo
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D16472
llvm-svn: 258862
Summary:
This patch adds parsing + sema for the target parallel directive and its clauses along with testcases.
Reviewers: ABataev
Differential Revision: http://reviews.llvm.org/D16553
Rebased to current trunk and updated test cases.
llvm-svn: 258832
All current properties are instance properties.
This is the second patch in a series of patches to support class properties
in addition to instance properties in objective-c.
rdar://23891898
llvm-svn: 258824
This patch adds a small utility to match function calls. This utility abstracts away the mutable keywords and the lazy initialization and caching logic of identifiers from the checkers. The SimpleStreamChecker is ported over this utility within this patch to show the reduction of code and to test this change.
Differential Revision: http://reviews.llvm.org/D15921
llvm-svn: 258572
A common idiom in Objective-C initializers is for a defensive nil-check on the
result of a call to a super initializer:
if (self = [super init]) {
...
}
return self;
To avoid warning on this idiom, the nullability checker now suppress diagnostics
for returns of nil on syntactic 'return self' even in initializers with non-null
return types.
llvm-svn: 258461
In r256567 I changed the nullability checker to suppress warnings about returning a null
value from a function/method with a non-null return type when the type of the returned
expression is itself nonnull. This enables the programmer to silence nullability warnings
by casting to _Nonnull:
return (SomeObject * _Nonnull)nil;
Unfortunately, under ObjC automated reference counting, Sema adds implicit casts to
_Nonnull to return expressions of nullable or unspecified types in functions with
non-null function/method return types. With r256567, these casts cause all nullability
warnings for returns of reference-counted types to be suppressed under ARC, leading to
false negatives.
This commit updates the nullability checker to look through implicit casts before
determining the type of the returned expression. It also updates the tests to turn on
ARC for the nullability_nullonly.mm testfile and adds a new testfile to test when ARC
is turned off.
rdar://problem/24200117
llvm-svn: 258061
Make sure that we do not add SymbolCast at the very boundary of
the range in which the cast would not certainly happen.
Differential Revision: http://reviews.llvm.org/D16178
llvm-svn: 258039
Update NullabilityChecker so that it checks return statements in ObjC methods.
Previously it was returning early because methods do not have a function type.
Also update detection of violated parameter _Nonnull preconditions to handle
ObjC methods.
rdar://problem/24200560
llvm-svn: 257938
Provide separate visitor templates for the three hierarchies, and also
the `FullSValVisitor' class, which is a union of all three visitors.
Additionally, add a particular example visitor, `SValExplainer', in order to
test the visitor templates. This visitor is capable of explaining the SVal,
SymExpr, or MemRegion in a natural language.
Compared to the reverted r257605, this fixes the test that used to fail
on some triples, and fixes build failure under -fmodules.
Differential Revision: http://reviews.llvm.org/D15448
llvm-svn: 257893
This reverts commit r257605.
The test fails on architectures that use unsigned int as size_t.
SymbolManager.h fails with compile errors on some platforms.
llvm-svn: 257608
Provide separate visitor templates for the three hierarchies, and also
the `FullSValVisitor' class, which is a union of all three visitors.
Additionally, add a particular example visitor, `SValExplainer', in order to
test the visitor templates. This visitor is capable of explaining the SVal,
SymExpr, or MemRegion in a natural language.
Differential Revision: http://reviews.llvm.org/D15448
llvm-svn: 257605
The purpose of these changes is to simplify introduction of definition files
for the three hierarchies.
1. For every sub-class C of these classes, its kind in the relevant enumeration
is changed to "CKind" (or C##Kind in preprocessor-ish terms), eg:
MemRegionKind -> MemRegionValKind
RegionValueKind -> SymbolRegionValueKind
CastSymbolKind -> SymbolCastKind
SymIntKind -> SymIntExprKind
2. MemSpaceRegion used to be inconsistently used as both an abstract base and
a particular region. This region class is now an abstract base and no longer
occupies GenericMemSpaceRegionKind. Instead, a new class, CodeSpaceRegion,
is introduced for handling the unique use case for MemSpaceRegion as
"the generic memory space" (when it represents a memory space that holds all
executable code).
3. BEG_ prefixes in memory region kind ranges are renamed to BEGIN_ for
consisitency with symbol kind ranges.
4. FunctionTextRegion and BlockTextRegion are renamed to FunctionCodeRegion and
BlockCodeRegion, respectively. The term 'code' is less jargony than 'text' and
we already refer to BlockTextRegion as a 'code region' in BlockDataRegion.
Differential Revision: http://reviews.llvm.org/D16062
llvm-svn: 257598
Dominic Chen