| Age | Commit message (Collapse) | Author |
|---|
|
were not emitted.
Fixes <rdar://problem/12280665>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163683 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
'Inputs' subdirectory.
The general desire has been to have essentially all of the non-test
input files live in such directories, with some exceptions for obvious
and common patterns like 'foo.c' using 'foo.h'.
This came up because our distributed test runner couldn't find some of
the headers, for example with stl.cpp.
No functionality changed, just shuffling around here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163674 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163673 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
reinterpret_cast does not provide any of the usual type information that
static_cast or dynamic_cast provide -- only the new type. This can get us
in a situation where the dynamic type info for an object is actually a
superclass of the static type, which does not match what CodeGen does at all.
In these cases, just fall back to the static type as the best possible type
for devirtualization.
Should fix the crashes on our internal buildbot.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163644 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
C++11 [expr.call]p1: ...If the selected function is non-virtual, or if the
id-expression in the class member access expression is a qualified-id,
that function is called. Otherwise, its final overrider in the dynamic type
of the object expression is called.
<rdar://problem/12255556>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163577 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The one reported bug, which was exposed by stl inlining, is addressed in
r163558.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163574 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
depth.
We only want to count how many substantial functions we inlined. This
is an improvement to r163558.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163571 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163562 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The option allows to always inline very small functions, whose size (in
number of basic blocks) is set using -analyzer-config
ipa-always-inline-size option.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163558 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a (heavy-handed) solution to PR13724 -- until we know we can do
a good job inlining the STL, it's best to be consistent and not generate
more false positives than we did before. We can selectively whitelist
certain parts of the 'std' namespace that are known to be safe.
This is controlled by analyzer config option 'c++-stdlib-inlining', which
can be set to "true" or "false".
This commit also adds control for whether or not to inline any templated
functions (member or non-member), under the config option
'c++-template-inlining'. This option is currently on by default.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163548 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
test.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163536 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163534 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
view them on different builders.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163529 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a C++ dialect. Let's see if this is the portability issue with this test.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163524 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163515 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I need to see how this breaks on other platforms when I fix the issue
that Benjamin Kramer pointed out.
This includes r163489 and r163490, plus a two line change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163512 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
r163489, "Take another crack at stabilizing the emission order of analyzer"
r163490, "Use isBeforeInTranslationUnitThan() instead of operator<."
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163497 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
diagnostics without using FoldingSetNodeIDs. This is done
by doing a complete recursive comparison of the PathDiagnostics.
Note that the previous method of comparing FoldingSetNodeIDs did
not end up relying on unstable things such as pointer addresses, so
I suspect this may still have some issues on various buildbots because
I'm not sure if the true source of non-determinism has been eliminated.
The tests pass for me, so the only way to know is to commit this change
and see what happens.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163489 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
fixes the buildbots.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163462 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
PathDiagnosticEventPieces were *always* pruned. Instead, they
are suppose to only be pruned if the entire call gets pruned.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163460 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163456 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of the analyzer by using the FullProfile() of a PathDiagnostic
for ordering them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163455 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ObjCSelfInitChecker stashes information in the GDM to persist it across
function calls; it is stored in pre-call checks and retrieved post-call.
The post-call check is supposed to clear out the stored state, but was
failing to do so in cases where the call did not have a symbolic return
value.
This was actually causing the inappropriate cache-out from r163361.
Per discussion with Anna, we should never actually cache out when
assuming the receiver of an Objective-C message is non-nil, because
we guarded that node generation by checking that the state has changed.
Therefore, the only states that could reach this exact ExplodedNode are
ones that should have merged /before/ making this assumption.
r163361 has been reverted and the test case removed, since it won't
actually test anything interesting now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163449 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163447 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163446 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Previously, we'd just keep constraints around forever, which means we'd
never be able to merge paths that differed only in constraints on dead
symbols.
Because we now allow constraints on symbolic expressions, not just single
symbols, this requires changing SymExpr::symbol_iterator to include
intermediate symbol nodes in its traversal, not just the SymbolData leaf
nodes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163444 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is necessary because further analysis will assume that the SVal's
type matches the AST type. This caused a crash when trying to perform
a derived-to-base cast on a C++ object that had been new'd to be another
object type.
Yet another crash in PR13763.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163442 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Teach malloc sizeof checker to find type inconsistencies in multi-
dimensional arrays.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163438 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
looking at PathPieces.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163427 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163418 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Don't warn when the sizeof argument is an array with the same element
type as the pointee of the return type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163407 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
changes to RegionStore.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163406 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Apparently the output of this test is not deterministic. Needs investigation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163377 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
While the check itself should count 0-based for the parameter index,
the diagnostic should be 1-based (first, second, third, not start at 0).
Fixes <rdar://problem/12249569>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163375 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of the analyzer, as the RetainReleaseChecker has many fine-grain
path diagnostic events that were not being checked. This uncovered
an inconsistency between the path diagnostics between Objective-C
and Objective-C++ code in ConditionBRVisitor that was fixed in a recent
patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163373 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
implicit pointer-to-boolean conversions in condition expressions. This would
result in inconsistent diagnostic emission between C and C++.
A consequence of this is now ConditionBRVisitor and TrackConstraintBRVisitor may
emit redundant diagnostics, for example:
"Assuming pointer value is null" (TrackConstraintBRVisitor)
"Assuming 'p' is null" (ConditionBRVisitor)
We need to reconcile the two, and perhaps prefer one over the other in some
cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163372 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
With some particularly evil casts, we can get an object whose dynamic type
is not actually a subclass of its static type. In this case, we won't even
find the statically-resolved method as a devirtualization candidate.
Rather than assert that this situation cannot occur, we now simply check
that the dynamic type is not an ancestor or descendent of the static type,
and leave it at that.
This error actually occurred analyzing LLVM: CallEventManager uses a
BumpPtrAllocator to allocate a concrete subclass of CallEvent
(FunctionCall), but then casts it to the actual subclass requested
(such as ObjCMethodCall) to perform the constructor.
Yet another crash in PR13763.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163367 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
return a CF object at all.
Fixes <rdar://problem/9566345>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163362 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
A bizarre series of coincidences led us to generate a previously-seen
node in the middle of processing an Objective-C message, where we assume
the receiver is non-nil. We were assuming that such an assumption would
never "cache out" like this, and blithely went on using a null ExplodedNode
as the predecessor for the next step in evaluation.
Although the test case committed here is complicated, this could in theory
happen in other ways as well, so the correct fix is just to test if the
non-nil assumption results in an ExplodedNode we've seen before.
<rdar://problem/12243648>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163361 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
via function/method with [CF,NS]_RETURNS_NOT_RETAINED.
Fixes <rdar://problem/11379000>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163355 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
are used in EH code. Right now the CFG doesn't support exceptions well,
so we need this hack to avoid bogus dead store warnings.
Fixes <rdar://problem/12147586>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163353 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
CXXDestructorCall now has a flag for when it is a base destructor call.
Other kinds of destructor calls (locals, fields, temporaries, and 'delete')
all behave as "whole-object" destructors and do not behave differently
from one another (specifically, in these cases we /should/ try to
devirtualize a call to a virtual destructor).
This was causing crashes in both our internal buildbot, the crash still
being tracked in PR13765, and some of the crashes being tracked in PR13763,
due to a assertion failure. (The behavior under -Asserts happened to be
correct anyway.)
Adding this knowledge also allows our DynamicTypePropagation checker to do
a bit less work; the special rules about virtual method calls during a
destructor only require extra handling during base destructors.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163348 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
As per Jordan's suggestion. (Came out of code review for r163261.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163269 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
While destructors will continue to not be inlined (unless the analyzer
config option 'c++-inlining' is set to 'destructors'), leaving them out
of the CFG is an incomplete model of the behavior of an object, and
can cause false positive warnings (like PR13751, now working).
Destructors for temporaries are still not on by default, since
(a) we haven't actually checked this code to be sure it's fully correct
(in particular, we probably need to be very careful with regard to
lifetime-extension when a temporary is bound to a reference,
C++11 [class.temporary]p5), and
(b) ExprEngine doesn't actually do anything when it sees a temporary
destructor in the CFG -- not even invalidate the object region.
To enable temporary destructors, set the 'cfg-temporary-dtors' analyzer
config option to '1'. The old -cfg-add-implicit-dtors cc1 option, which
controlled all implicit destructors, has been removed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163264 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163262 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
If a region is binded to a symbolic value, we should track the symbol.
(The code I changed was not previously exercised by the regression
tests.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163261 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Add a FIXME to the test while I track down the real problem.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163222 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The problem is that the value of 'this' in a C++ member function call
should always be a region (or NULL). However, if the object is an rvalue,
it has no associated region (only a conjured symbol or LazyCompoundVal).
For now, we handle this in two ways:
1) Actually respect MaterializeTemporaryExpr. Before, it was relying on
CXXConstructExpr to create temporary regions for all struct values.
Now it just does the right thing: if the value is not in a temporary
region, create one.
2) Have CallEvent recognize the case where its 'this' pointer is a
non-region, and just return UnknownVal to keep from confusing clients.
The long-term problem is being tracked internally in <rdar://problem/12137950>,
but this makes many test cases pass.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163220 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This turned out to have many implications, but what eventually seemed to
make it unworkable was the fact that we can get struct values (as
LazyCompoundVals) from other places besides return-by-value function calls;
that is, we weren't actually able to "treat all struct values as regions"
consistently across the entire analyzer core.
Hopefully we'll be able to come up with an alternate solution soon.
This reverts r163066 / 02df4f0aef142f00d4637cd851e54da2a123ca8e.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163218 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
SimpleSValBuilder processes a couple trivial identities, including 'x - x'
and 'x ^ x' (both 0). However, the former could appear with arguments of
floating-point type, and we weren't checking for that. This started
triggering an assert with r163069, which checks that a constant value is
actually going to be used as an integer or pointer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163159 91177308-0d34-0410-b5e6-96231b3b80d8
|
