[analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runt

[analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.

Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin

Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits

Differential Revision: https://reviews.llvm.org/D30373

llvm-svn: 296312

show more ...

[analyzer] Bug identification

This patch adds hashes to the plist and html output to be able to identfy bugs
for suppressing false positives or diff results against a baseline. This hash
aims to be

[analyzer] Bug identification

This patch adds hashes to the plist and html output to be able to identfy bugs
for suppressing false positives or diff results against a baseline. This hash
aims to be resilient for code evolution and is usable to identify bugs in two
different snapshots of the same software. One missing piece however is a
permanent unique identifier of the checker that produces the warning. Once that
issue is resolved, the hashes generated are going to change. Until that point
this feature is marked experimental, but it is suitable for early adoption.

Differential Revision: http://reviews.llvm.org/D10305

Original patch by: Bence Babati!

llvm-svn: 251011

show more ...

Record correct source range for defaulted/deleted members.

Fixes https://llvm.org/bugs/show_bug.cgi?id=20744

struct A {

A() = default;
};

Previously the source range of the declaration of A ended

Record correct source range for defaulted/deleted members.

Fixes https://llvm.org/bugs/show_bug.cgi?id=20744

struct A {

A() = default;
};

Previously the source range of the declaration of A ended at the ')'. It should
include the '= default' part as well. The same for '= delete'.

Note: this will break one of the clang-tidy fixers, which is going to be
addessed in a follow-up patch.

Differential Revision: http://reviews.llvm.org/D8465

llvm-svn: 233028

show more ...

[Static Analyzer] The name of the checker that reports a bug is added
to the plist output. This check_name field does not guaranteed to be the
same as the name of the checker in the future.

Reviewer

[Static Analyzer] The name of the checker that reports a bug is added
to the plist output. This check_name field does not guaranteed to be the
same as the name of the checker in the future.

Reviewer: Anna Zaks

Differential Revision: http://reviews.llvm.org/D6841

llvm-svn: 228624

show more ...

Fix/Improve SourceRange of explicitly defaulted members

When adding the implicit compound statement (required for Codegen?), the
end location was previously overridden by the start location, probabl

Fix/Improve SourceRange of explicitly defaulted members

When adding the implicit compound statement (required for Codegen?), the
end location was previously overridden by the start location, probably
based on the assumptions:

* The location of the compound statement should be the member's location
* The compound statement if present is the last element of a FunctionDecl

This patch changes the location of the compound statement to the
member's end location.

Code review: http://reviews.llvm.org/D4175

llvm-svn: 211344

show more ...

Add -Wtautological-undefined-compare and -Wundefined-bool-conversion warnings
to detect underfined behavior involving pointers.

llvm-svn: 210372

Correctly set brace range for CXXConstructExprs formed by list initialization.

Differential Revision: http://llvm-reviews.chandlerc.com/D2711

llvm-svn: 201926

[analyzer] Don't crash when a path goes through a 'delete' destructor call.

This was just left unimplemnted from r191381; the fix is to report this call
location as the location of the 'delete' expr

[analyzer] Don't crash when a path goes through a 'delete' destructor call.

This was just left unimplemnted from r191381; the fix is to report this call
location as the location of the 'delete' expr.

PR17746

llvm-svn: 193783

show more ...

Revert "[analyzer] Handle zeroing CXXConstructExprs."

Per review from Anna, this really should have been two commits, and besides
it's causing problems on our internal buildbot. Reverting until thes

Revert "[analyzer] Handle zeroing CXXConstructExprs."

Per review from Anna, this really should have been two commits, and besides
it's causing problems on our internal buildbot. Reverting until these have
been worked out.

This reverts r184511 / 98123284826bb4ce422775563ff1a01580ec5766.

llvm-svn: 184561

show more ...

[analyzer] Handle zeroing CXXConstructExprs.

Certain expressions can cause a constructor invocation to zero-initialize
its object even if the constructor itself does no initialization. The
analyzer

[analyzer] Handle zeroing CXXConstructExprs.

Certain expressions can cause a constructor invocation to zero-initialize
its object even if the constructor itself does no initialization. The
analyzer now handles that before evaluating the call to the constructor,
using the same "default binding" mechanism that calloc() uses, rather
than simply ignoring the zero-initialization flag.

As a bonus, trivial default constructors are now no longer inlined; they
are instead processed explicitly by ExprEngine. This has a (positive)
effect on the generated path edges: they no longer stop at a default
constructor call unless there's a user-provided implementation.

<rdar://problem/14212563>

llvm-svn: 184511

show more ...

[analyzer] Enable the new edge algorithm by default.

...but don't yet migrate over the existing plist tests. Some of these
would be trivial to migrate; others could use a bit of inspection first.
In

[analyzer] Enable the new edge algorithm by default.

...but don't yet migrate over the existing plist tests. Some of these
would be trivial to migrate; others could use a bit of inspection first.
In any case, though, the new edge algorithm seems to have proven itself,
and we'd like more coverage (and more usage) of it going forwards.

llvm-svn: 183165

show more ...

[analyzer] Fix a crash triggered by printing a note on a default argument

Instead, use the location of the call to print the note.

llvm-svn: 181337

[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse

The 2 functions were computing the same location using different logic (each one had edg

[analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse

The 2 functions were computing the same location using different logic (each one had edge case bugs that the other
one did not). Refactor them to rely on the same logic.

The location of the warning reported in text/command line output format will now match that of the plist file.

There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the
operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and
looks better in most cases.

llvm-svn: 180165

show more ...

[analyzer] Correct the comment

llvm-svn: 179914

[analyzer] Tweak getDerefExpr more to track DeclRefExprs to references.

In the committed example, we now see a note that tells us when the pointer
was assumed to be null.

This is the only case in w

[analyzer] Tweak getDerefExpr more to track DeclRefExprs to references.

In the committed example, we now see a note that tells us when the pointer
was assumed to be null.

This is the only case in which getDerefExpr returned null (failed to get
the dereferenced expr) throughout our regression tests. (There were multiple
occurrences of this one.)

llvm-svn: 179736

show more ...

[analyzer] Improve dereferenced expression tracking for MemberExpr with a dot and non-reference base

llvm-svn: 179734

[analyzer] Add pretty printing to CXXBaseObjectRegion.

llvm-svn: 179573

[analyzer] Add more specialized error messages for corner cases as per Jordan's code review for r179396

llvm-svn: 179571

[analyzer] Print a diagnostic note even if the region cannot be printed.

There are few cases where we can track the region, but cannot print the note,
which makes the testing limited. (Though, I’ve

[analyzer] Print a diagnostic note even if the region cannot be printed.

There are few cases where we can track the region, but cannot print the note,
which makes the testing limited. (Though, I’ve tested this manually by making
all regions non-printable.) Even though the applicability is limited now, the enhancement
will be more relevant as we start tracking more regions.

llvm-svn: 179396

show more ...

[analyzer] Show "Returning from ..." note at caller's depth, not callee's.

Before:
1. Calling 'foo'
2. Doing something interesting
3. Returning from 'foo'
4. Some kind of error here

Aft

[analyzer] Show "Returning from ..." note at caller's depth, not callee's.

Before:
1. Calling 'foo'
2. Doing something interesting
3. Returning from 'foo'
4. Some kind of error here

After:
1. Calling 'foo'
2. Doing something interesting
3. Returning from 'foo'
4. Some kind of error here

The location of the note is already in the caller, not the callee, so this
just brings the "depth" attribute in line with that.

This only affects plist diagnostic consumers (i.e. Xcode). It's necessary
for Xcode to associate the control flow arrows with the right stack frame.

<rdar://problem/13634363>

llvm-svn: 179351

show more ...

[analyzer] Don't emit extra context arrow after returning from an inlined call.

In this code

int getZero() {
return 0;
}

void test() {
int problem = 1 / getZero(); // expected-warnin

[analyzer] Don't emit extra context arrow after returning from an inlined call.

In this code

int getZero() {
return 0;
}

void test() {
int problem = 1 / getZero(); // expected-warning {{Division by zero}}
}

we generate these arrows:

+-----------------+
| v
int problem = 1 / getZero();
^ |
+---+

where the top one represents the control flow up to the first call, and the
bottom one represents the flow to the division.* It turns out, however, that
we were generating the top arrow twice, as if attempting to "set up context"
after we had already returned from the call. This resulted in poor
highlighting in Xcode.

* Arguably the best location for the division is the '/', but that's a
different problem.

<rdar://problem/13326040>

llvm-svn: 179350

show more ...

[analyzer] Show path diagnostic for C++ initializers

Also had to modify the PostInitializer ProgramLocation to contain the field region.

llvm-svn: 178826

[analyzer] Check for returning null references in ReturnUndefChecker.

Officially in the C++ standard, a null reference cannot exist. However,
it's still very easy to create one:

int &getNullRef() {

[analyzer] Check for returning null references in ReturnUndefChecker.

Officially in the C++ standard, a null reference cannot exist. However,
it's still very easy to create one:

int &getNullRef() {
int *p = 0;
return *p;
}

We already check that binds to reference regions don't create null references.
This patch checks that we don't create null references by returning, either.

<rdar://problem/13364378>

llvm-svn: 176601

show more ...

[analyzer] Suppress paths involving a reference whose rvalue is null.

Most map types have an operator[] that inserts a new element if the key
isn't found, then returns a reference to the value slot

[analyzer] Suppress paths involving a reference whose rvalue is null.

Most map types have an operator[] that inserts a new element if the key
isn't found, then returns a reference to the value slot so that you can
assign into it. However, if the value type is a pointer, it will be
initialized to null. This is usually no problem.

However, if the user /knows/ the map contains a value for a particular key,
they may just use it immediately:

// From ClangSACheckersEmitter.cpp
recordGroupMap[group]->Checkers

In this case the analyzer reports a null dereference on the path where the
key is not in the map, even though the user knows that path is impossible
here. They could silence the warning by adding an assertion, but that means
splitting up the expression and introducing a local variable. (Note that
the analyzer has no way of knowing that recordGroupMap[group] will return
the same reference if called twice in a row!)

We already have logic that says a null dereference has a high chance of
being a false positive if the null came from an inlined function. This
patch simply extends that to references whose rvalues are null as well,
silencing several false positives in LLVM.

<rdar://problem/13239854>

llvm-svn: 176371

show more ...

[analyzer] Fix test for r173067.

Note to self: don't remove comments /after/ updating the line-sensitive
part of a test.

llvm-svn: 173070