History log of /external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
ef8225444452a1486bd721f3285301fe84643b00 21-Jul-2014 Stephen Hines <srhines@google.com> Update Clang for rebase to r212749.

This also fixes a small issue with arm_neon.h not being generated always.

Includes a cherry-pick of:
r213450 - fixes mac-specific header issue
r213126 - removes a default -Bsymbolic on Android

Change-Id: I2a790a0f5d3b2aab11de596fc3a74e7cbc99081d
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
6bcf27bb9a4b5c3f79cb44c0e4654a6d7619ad89 29-May-2014 Stephen Hines <srhines@google.com> Update Clang for 3.5 rebase (r209713).

Change-Id: I8c9133b0f8f776dc915f270b60f94962e771bc83
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
651f13cea278ec967336033dd032faef0e9fc2ec 24-Apr-2014 Stephen Hines <srhines@google.com> Updated to Clang 3.5a.

Change-Id: I8127eb568f674c2e72635b639a3295381fe8af82
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
2a648169f9ad854536814515cba1780fd02586d2 31-Oct-2013 Jordan Rose <jordan_rose@apple.com> [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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193783 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
36d558d85653315edb389677e995ec9ccdbfbf3d 03-Sep-2013 Jordan Rose <jordan_rose@apple.com> Add an implicit dtor CFG node just before C++ 'delete' expressions.

This paves the way for adding support for modeling the destructor of a
region before it is deleted. The statement "delete <expr>" now generates
this series of CFG elements:

1. <expr>
2. [B1.1]->~Foo() (Implicit destructor)
3. delete [B1.1]

Patch by Karthik Bhat!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189828 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
344472ebeded2fca2ed5013b9e87f81d09bfa908 23-Aug-2013 Robert Wilhelm <robert.wilhelm@gmx.net> Use pop_back_val() instead of both back() and pop_back().
No functionality change intended.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189112 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
24146975f1af8c1b4b14e8545f218129d0e7dfeb 22-Aug-2013 Eli Friedman <eli.friedman@gmail.com> Split isFromMainFile into two functions.

Basically, isInMainFile considers line markers, and isWrittenInMainFile
doesn't. Distinguishing between the two is useful when dealing with
files which are preprocessed files or rewritten with -frewrite-includes
(so we don't, for example, print useless warnings).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188968 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
d474da062565596015558856333423199aed5eb1 24-May-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Treat analyzer-synthesized function bodies like implicit bodies.

When generating path notes, implicit function bodies are shown at the call
site, so that, say, copying a POD type in C++ doesn't jump you to a header
file. This is especially important when the synthesized function itself
calls another function (or block), in which case we should try to jump the
user around as little as possible.

By checking whether a called function has a body in the AST, we can tell
if the analyzer synthesized the body, and if we should therefore collapse
the call down to the call site like a true implicitly-defined function.

<rdar://problem/13978414>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182677 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
61dfd6f160f7501e140704990db9c449d29f8649 22-May-2013 Anna Zaks <ganna@apple.com> [analyzer] Do not assert on reports ending in calls within macros.

The crash is triggered by the newly added option (-analyzer-config report-in-main-source-file=true) introduced in r182058.

Note, ideally, we’d like to report the issue within the main source file here as well.
For now, just do not crash.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182445 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
5a8e1ad062420ef74707bf093889403d07664b17 17-May-2013 Anna Zaks <ganna@apple.com> [analyzer] Address Jordan's review comments for r182058

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182156 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
d95b70175646829c26344d5f0bda1ec3009f2a5b 17-May-2013 Anna Zaks <ganna@apple.com> [analyzer] Add an option to use the last location in the main source file as the report location.

Previously, we’ve used the last location of the analyzer issue path as the location of the
report. This might not provide the best user experience, when one analyzer a source
file and the issue appears in the header. Introduce an option to use the last location
of the path that is in the main source file as the report location.

New option can be enabled with -analyzer-config report-in-main-source-file=true.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182058 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
ed866e73bab7733f5226f84c52edefe23d694b2f 30-Apr-2013 Ted Kremenek <kremenek@apple.com> Revert "[analyzer] Change PathPieces to be a wrapper around an ilist of (through indirection) PathDiagnosticPieces."

Jordan rightly pointed out that we can do the same with std::list.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180746 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
7651e53997e20f1e627ffce25ce613f79c48e3e3 30-Apr-2013 Ted Kremenek <kremenek@apple.com> [analyzer] Change PathPieces to be a wrapper around an ilist of (through indirection) PathDiagnosticPieces.

Much of this patch outside of PathDiagnostics.h are just minor
syntactic changes due to the return type for operator* and the like
changing for the iterator, so the real focus should be on
PathPieces itself.

This change is motivated so that we can do efficient insertion
and removal of individual pieces from within a PathPiece, just like
this was a kind of "IR" for static analyzer diagnostics. We
currently implement path transformations by iterating over an
entire PathPiece and making a copy. This isn't very natural for
some algorithms.

We use an ilist here instead of std::list because we want operations
to rip out/insert nodes in place, just like IR manipulation. This
isn't being used yet, but opens the door for more powerful
transformation algorithms on diagnostic paths.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180741 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
b5142359abc50e151c18bde88fbabec98b65077c 30-Apr-2013 Ted Kremenek <kremenek@apple.com> [analyzer] Remove comparePath's dependency on subscript operator.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180740 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
0f8579274a010f360a371b53101859d9d6052314 24-Apr-2013 Anna Zaks <ganna@apple.com> [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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180165 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
610f79cbab4d752349b5c81a94682a6a82b102e7 05-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Show path diagnostic for C++ initializers

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178826 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
b07805485c603be3d8011f72611465324c9e664b 23-Feb-2013 David Blaikie <dblaikie@gmail.com> Remove the CFGElement "Invalid" state.

Use Optional<CFG*> where invalid states were needed previously. In the one case
where that's not possible (beginAutomaticObjDtorsInsert) just use a dummy
CFGAutomaticObjDtor.

Thanks for the help from Jordan Rose & discussion/feedback from Ted Kremenek
and Doug Gregor.

Post commit code review feedback on r175796 by Ted Kremenek.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175938 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
df1f94ebfac4578e27ad008522c7b333e977e51b 22-Feb-2013 David Blaikie <dblaikie@gmail.com> Simplify code to use castAs rather than getAs + assert.

Post commit review feedback on r175812 from Jordan Rose.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175826 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
7a95de68c093991047ed8d339479ccad51b88663 21-Feb-2013 David Blaikie <dblaikie@gmail.com> Replace ProgramPoint llvm::cast support to be well-defined.

See r175462 for another example/more details.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175812 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
fdf6a279c9a75c778eba382d9a156697092982a1 21-Feb-2013 David Blaikie <dblaikie@gmail.com> Replace CFGElement llvm::cast support to be well-defined.

See r175462 for another example/more details.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175796 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
66874fb18afbffb8b2ca05576851a64534be3352 21-Feb-2013 David Blaikie <dblaikie@gmail.com> Use None rather than Optional<T>() where possible.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175705 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
dc84cd5efdd3430efb22546b4ac656aa0540b210 20-Feb-2013 David Blaikie <dblaikie@gmail.com> Include llvm::Optional in clang/Basic/LLVM.h

Post-commit CR feedback from Jordan Rose regarding r175594.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175679 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
5251abea41b446c26e3239c8dd6c7edea6fc335d 20-Feb-2013 David Blaikie <dblaikie@gmail.com> Replace SVal llvm::cast support to be well-defined.

See r175462 for another example/more details.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175594 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
2b9de0bc05e3e1092a9d1880e62aeaa54dc343e3 19-Jan-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Don't show "Entered 'foo'" if 'foo' is implicit.

Before:
Calling implicit default constructor for 'Foo' (where Foo is constructed)
Entered call from 'test' (at "=default" or 'Foo' declaration)
Calling default constructor for 'Bar' (at "=default" or 'Foo' declaration)

After:
Calling implicit default constructor for 'Foo' (where Foo is constructed)
Calling default constructor for 'Bar' (at "=default" or 'Foo' declaration)

This only affects the plist diagnostics; this note is never shown in the
other diagnostics.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172915 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
e02be97811c785f91ac43a0feed2db862de1867f 18-Jan-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Special path notes for C++ special member functions.

Examples:
Calling implicit default constructor for Foo
Calling defaulted move constructor for Foo
Calling copy constructor for Foo
Calling implicit destructor for Foo
Calling defaulted move assignment operator for Foo
Calling copy assignment operator for Foo

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172833 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
dc47c9a71c99ce2e5b9d84f1cd3487b6852b3543 18-Jan-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Do a better job describing C++ member functions in the call stack.

Examples:
Calling constructor for 'Foo'
Entered call from 'Foo::create'

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172832 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
cfa88f893915ceb8ae4ce2f17c46c24a4d67502f 12-Jan-2013 Dmitri Gribenko <gribozavr@gmail.com> Remove useless 'llvm::' qualifier from names like StringRef and others that are
brought into 'clang' namespace by clang/Basic/LLVM.h


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172323 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
97bfb558f69c09b01a5c1510f08dc91eb62329a7 08-Jan-2013 Anna Zaks <ganna@apple.com> [analyzer] Include the bug uniqueing location in the issue_hash.

The issue here is that if we have 2 leaks reported at the same line for
which we cannot print the corresponding region info, they will get
treated as the same by issue_hash+description. We need to AUGMENT the
issue_hash with the allocation info to differentiate the two issues.

Add the "hash" (offset from the beginning of a function) representing
allocation site to solve the issue.

We might want to generalize solution in the future when we decide to
track more than just the 2 locations from the diagnostics.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171825 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
55fc873017f10f6f566b182b70f6fc22aefa3464 04-Dec-2012 Chandler Carruth <chandlerc@gmail.com> Sort all of Clang's files under 'lib', and fix up the broken headers
uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.

I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
a93d0f280693b8418bc88cf7a8c93325f7fcf4c6 01-Dec-2012 Benjamin Kramer <benny.kra@googlemail.com> Include pruning and general cleanup.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169095 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
63bc186d6ac0b44ba4ec6fccb5f471b05c79b666 15-Nov-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Report leaks at the closing brace of a function body.

This fixes a few cases where we'd emit path notes like this:

+---+
1| v
p = malloc(len);
^ |2
+---+

In general this should make path notes more consistent and more correct,
especially in cases where the leak happens on the false branch of an if
that jumps directly to the end of the function. There are a couple places
where the leak is reported farther away from the cause; these are usually
cases where there are several levels of nested braces before the end of
the function. This still matches our current behavior for when there /is/
a statement after all the braces, though.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168070 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
368f3b070e8cb657a65bfa443d60256676d269e7 15-Nov-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Make sure calls in synthesized functions have valid path locations.

We do this by using the "most recent" good location: if a synthesized
function 'A' calls another function 'B', the path notes for the call to 'B'
will be placed at the same location as the path note for calling 'A'.

Similarly, the call to 'A' will have a note saying "Entered call from...",
and now we just don't emit that (since the user doesn't have a body to look
at anyway).

Previously, we were doing this for the "Calling..." notes, but not for the
"Entered call from..." or "Returning to caller". This caused a crash when
the path entered and then exiting a call within a synthesized body.

<rdar://problem/12657843>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168019 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
6a329ee7567cf3267ffab2bc755ea8c773d967e7 29-Oct-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] New option to not suppress null return paths if an argument is null.

Our one basic suppression heuristic is to assume that functions do not
usually return NULL. However, when one of the arguments is NULL it is
suddenly much more likely that NULL is a valid return value. In this case,
we don't suppress the report here, but we do attach /another/ visitor to
go find out if this NULL argument also comes from an inlined function's
error path.

This new behavior, controlled by the 'avoid-suppressing-null-argument-paths'
analyzer-config option, is turned off by default. Turning it on produced
two false positives and no new true positives when running over LLVM/Clang.

This is one of the possible refinements to our suppression heuristics.
<rdar://problem/12350829>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166941 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
cf4ce93caedca1d91ec5824981f9e45eda20b261 06-Oct-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Handle implicit statements used for end-of-path nodes' source locs.

Some implicit statements, such as the implicit 'self' inserted for "free"
Objective-C ivar access, have invalid source locations. If one of these
statements is the location where an issue is reported, we'll now look at
the enclosing statements for a valid source location.

<rdar://problem/12446776>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165354 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
615a092a511cd2dfe1a5364ebf5f80e55e33034d 22-Sep-2012 Jordan Rose <jordan_rose@apple.com> Use llvm::getOrdinalSuffix to print ordinal numbers in diagnostics.

Just a refactoring of common infrastructure. No intended functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164443 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
15f9f74f0cc7c2923b1977c6d33059251e6df204 10-Sep-2012 Ted Kremenek <kremenek@apple.com> Fix another case where we should be using isBeforeInTranslationUnit().

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163533 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
d727d39ca779920898d77f5dcbbb3980175594ef 10-Sep-2012 Ted Kremenek <kremenek@apple.com> Add a few more cases where we should be using isBeforeInTranslationUnit().

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163531 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
acc714ba6c448e6dc278acf9b6eafee44d7f48a7 10-Sep-2012 Ted Kremenek <kremenek@apple.com> Revert "Revert Ted's r163489 and r163490, due to breakage."

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
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
2343b3d0c29356583a013d900f2817083ac2d4a0 10-Sep-2012 NAKAMURA Takumi <geek4civic@gmail.com> Revert Ted's r163489 and r163490, due to breakage.

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
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
c265cddad7f9ca9eda1e7d08c2595ec73acec724 10-Sep-2012 Ted Kremenek <kremenek@apple.com> Use isBeforeInTranslationUnitThan() instead of operator<.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163490 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
4dfd141350009c742f4949a753ffe4a1524a2792 10-Sep-2012 Ted Kremenek <kremenek@apple.com> Take another crack at stabilizing the emission order of analyzer
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
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
0187a1b8b9b2b7657de0ba8b0d4f67d30bec83e8 08-Sep-2012 Ted Kremenek <kremenek@apple.com> Attempt (again) to stabilize the order of the emission of diagnostics
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
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
e157ae53772e90a3ee3cba3eaa7da3300eb249eb 08-Sep-2012 Ted Kremenek <kremenek@apple.com> Revert "Attempt to make the PathDiagnostic emission order more deterministic by"

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163446 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
62a456312ad633169528d5fc85063704dc8f5d0f 08-Sep-2012 Ted Kremenek <kremenek@apple.com> Revert "Further tweaks to hopefully make the PathDiagnostic emission more deterministic."

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163445 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
ec5fda4dedbc249b61be032f710e8c9d6396fee8 08-Sep-2012 Ted Kremenek <kremenek@apple.com> Further tweaks to hopefully make the PathDiagnostic emission more deterministic.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163430 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
b4b4523cc52bebc5ed47cc501959ab31286a1065 08-Sep-2012 Ted Kremenek <kremenek@apple.com> Attempt to make the PathDiagnostic emission order more deterministic by
looking at PathPieces.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163427 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
3a46f5fd1709f6df03bbb8b0abf84052dc0f39ff 31-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Ensure that PathDiagnostics profile the same regardless of path.

PathDiagnostics are actually profiled and uniqued independently of the
path on which the bug occurred. This is used to merge diagnostics that
refer to the same issue along different paths, as well as by the plist
diagnostics to reference files created by the HTML diagnostics.

However, there are two problems with the current implementation:

1) The bug description is included in the profile, but some
PathDiagnosticConsumers prefer abbreviated descriptions and some
prefer verbose descriptions. Fixed by including both descriptions in
the PathDiagnostic objects and always using the verbose one in the profile.

2) The "minimal" path generation scheme provides extra information about
which events came from macros that the "extensive" scheme does not.
This resulted not only in different locations for the plist and HTML
diagnostics, but also in diagnostics being uniqued in the plist output
but not in the HTML output. Fixed by storing the "end path" location
explicitly in the PathDiagnostic object, rather than trying to find the
last piece of the path when the diagnostic is requested.

This should hopefully finish unsticking our internal buildbot.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162965 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
b75e2602e246b44bb285be8cc31166302d77998f 24-Aug-2012 Ted Kremenek <kremenek@apple.com> Rework how PathDiagnosticConsumers pass knowledge of what files they
generated for a given diagnostic to another. Because PathDiagnostics
are specific to a give PathDiagnosticConsumer, store in
a FoldingSet a unique hash for a PathDiagnostic (that will be the same
for the same bug for different PathDiagnosticConsumers) that
stores a list of files generated. This can then be read by the
other PathDiagnosticConsumers.

This fixes breakage in the PLIST-HTML output.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162580 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
2b2c49d2ac5adb34f900f7a854a3ad5a6b0dff3c 16-Aug-2012 Ted Kremenek <kremenek@apple.com> Remove "range_iterator" from PathDiagnosticPiece and just use ArrayRef<SourceRange> for ranges. This
removes conceptual clutter, and can allow us to easy migrate to C++11 style for-range loops if we
ever move to using C++11 in Clang.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162029 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
c4bac8e376b98d633bb00ee5f510d5e58449753c 16-Aug-2012 Ted Kremenek <kremenek@apple.com> Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.

This fixes several issues:

- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.

- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).

As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.

There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162028 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
b0e1badc2a9b8275b48dfb15c6907a282b949b02 04-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Flatten path diagnostics for text output like we do for HTML.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161279 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
7ad4848d4744b8d60289f3e359250cebdaaf7114 04-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Provide useful PathDiagnosticLocations for CallEnter/Exit events.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161277 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
5b978519d2c5f5b4541768a827b675e997d4cd34 03-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] Fix a typo. Thanks Jordan.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161249 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
d015f4febe85d3e3340172d70042840c51bbd836 03-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] Solve another source of non-determinism in the diagnostic
engine.

The code that was supposed to split the tie in a deterministic way is
not deterministic. Most likely one of the profile methods uses a
pointer. After this change we do finally get the consistent diagnostic
output. Testing this requires running the analyzer on large code bases
and diffing the results.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161224 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
1d3ca251f9891623fac0dbe70eece42564e274ed 26-Jul-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Don't crash on implicit statements inside initializers.

Our BugReporter knows how to deal with implicit statements: it looks in
the ParentMap until it finds a parent with a valid location. However, since
initializers are not in the body of a constructor, their sub-expressions are
not in the ParentMap. That was easy enough to fix in AnalysisDeclContext.

...and then even once THAT was fixed, there's still an extra funny case
of Objective-C object pointer fields under ARC, which are initialized with
a top-level ImplicitValueInitExpr. To catch these cases,
PathDiagnosticLocation will now fall back to the start of the current
function if it can't find any other valid SourceLocations. This isn't great,
but it's miles better than a crash.

(All of this is only relevant when constructors and destructors are being
inlined, i.e. under -cfg-add-initializers and -cfg-add-implicit-dtors.)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160810 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
888c90ac0ef6baf7d47e86cf5cc4715707d223b1 26-Jul-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Handle base class initializers and destructors.

Most of the logic here is fairly simple; the interesting thing is that
we now distinguish complete constructors from base or delegate constructors.
We also make sure to cast to the base class before evaluating a constructor
or destructor, since non-virtual base classes may behave differently.

This includes some refactoring of VisitCXXConstructExpr and VisitCXXDestructor
in order to keep ExprEngine.cpp as clean as possible (leaving the details for
ExprEngineCXX.cpp).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160806 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
183ba8e19d49ab1ae25d3cdd0a19591369c5ab9f 26-Jul-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Show paths for destructor calls.

This modifies BugReporter and friends to handle CallEnter and CallExitEnd
program points that came from implicit call CFG nodes (read: destructors).

This required some extra handling for nested implicit calls. For example,
the added multiple-inheritance test case has a call graph that looks like this:

testMultipleInheritance3
~MultipleInheritance
~SmartPointer
~Subclass
~SmartPointer
***bug here***

In this case we correctly notice that we started in an inlined function
when we reach the CallEnter program point for the second ~SmartPointer.
However, when we reach the next CallEnter (for ~Subclass), we were
accidentally re-using the inner ~SmartPointer call in the diagnostics.

Rather than guess if we saw the corresponding CallExitEnd based on the
contents of the active path, we now just ask the PathDiagnostic if there's
any known stack before popping off the top path.

(A similar issue could have occured without multiple inheritance, but there
wasn't a test case for it.)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160804 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
852aa0d2c5d2d1faf2d77b5aa3c0848068a342c5 11-Jul-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Make CallEnter, CallExitBegin, and CallExitEnd not be StmtPoints

These ProgramPoints are used in inlining calls,
and not all calls have associated statements anymore.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160021 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
0b3ade86a1c60cf0c7b56aa238aff458eb7f5974 20-Apr-2012 Anna Zaks <ganna@apple.com> [analyzer] Run remove dead bindings right before leaving a function.

This is needed to ensure that we always report issues in the correct
function. For example, leaks are identified when we call remove dead
bindings. In order to make sure we report a callee's leak in the callee,
we have to run the operation in the callee's context.

This change required quite a bit of infrastructure work since:
- We used to only run remove dead bindings before a given statement;
here we need to run it after the last statement in the function. For
this, we added additional Program Point and special mode in the
SymbolReaper to remove all symbols in context lower than the current
one.
- The call exit operation turned into a sequence of nodes, which are
now guarded by CallExitBegin and CallExitEnd nodes for clarity and
convenience.

(Sorry for the long diff.)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155244 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
07189521a15d9c088216b943649cb9fe231cbb57 04-Apr-2012 Ted Kremenek <kremenek@apple.com> Include the "issue context" (e.g. function or method) where a static analyzer issue occurred in the plist output.

Fixes <rdar://problem/11004527>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154030 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
fbd58743fa6c793b84ed60a0e2325335a53da6c4 17-Mar-2012 Anna Zaks <ganna@apple.com> [analyzer] Shorten the stack hint diagnostic.

Do not display the standard "Returning from 'foo'", when a stack hint is
available.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152964 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
56a938ff85a444eb3d30d2634d92ce5b1f6fae56 17-Mar-2012 Anna Zaks <ganna@apple.com> [analyzer] Create symbol-aware stack hints (building upon r152837).

The symbol-aware stack hint combines the checker-provided message
with the information about how the symbol was passed to the callee: as
a parameter or a return value.

For malloc, the generated messages look like this :
"Returning from 'foo'; released memory via 1st parameter"
"Returning from 'foo'; allocated memory via 1st parameter"
"Returning from 'foo'; allocated memory returned"
"Returning from 'foo'; reallocation of 1st parameter failed"


(We are yet to handle cases when the symbol is a field in a struct or
an array element.)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152962 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
368a0d565f078666ca5bfb7fe08d04648688e4bc 15-Mar-2012 Anna Zaks <ganna@apple.com> [analyzer] Allow checkers to supply call stack diagnostic hints for the
BugVisitor DiagnosticPieces.

When checkers create a DiagnosticPieceEvent, they can supply an extra
string, which will be concatenated with the call exit message for every
call on the stack between the diagnostic event and the final bug report.
(This is a simple version, which could be/will be further enhanced.)

For example, this is used in Malloc checker to produce the ",
which allocated memory" in the following example:

static char *malloc_wrapper() { // 2. Entered call from 'use'
return malloc(12); // 3. Memory is allocated
}

void use() {
char *v;
v = malloc_wrapper(); // 1. Calling 'malloc_wrappers'
// 4. Returning from 'malloc_wrapper', which allocated memory
} // 5. Memory is never released; potential
memory leak

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152837 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
9373937945e1e075dfa08169eaccc1ad0b31f699 14-Mar-2012 Anna Zaks <ganna@apple.com> [analyzer] Diagnostics: Supply Caller information even if the bug occurs
in the callee.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152734 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
fc544e3d52c43746b1b273f38ec7d65461f0064a 13-Mar-2012 Anna Zaks <ganna@apple.com> [analyzer] Call enter/exit diagnostic should refer to caller/callee,
respectively.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152676 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
097ebb3d8ce55d1f78a3f1e7a0978dbde5ee2898 06-Mar-2012 Ted Kremenek <kremenek@apple.com> [analyzer] add a diagnostic event when entering a call via inlining, within the callee, and add an edge.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152086 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
62ff52868976a8494224a2914f1869329777944c 01-Mar-2012 Ted Kremenek <kremenek@apple.com> [analyzer] when scanning FIDs in a PathDiagnostic, correctly recurse calls and macros.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151774 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
56d8fd0b8a65a7ccae3669cd650ca443cf24b73e 29-Feb-2012 Ted Kremenek <kremenek@apple.com> [analyzer diagnostics] Refactor filtration for PathDiagnosticConsumers that don't support cross-file diagnostics
into a common place. Currently enable this filtration for Plist diagnostics as well.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151664 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
2042fc1f36d471f437023e8899f0c4fadded2341 24-Feb-2012 Ted Kremenek <kremenek@apple.com> Reapply r151317, but when computing the PathDiagnostic profile and size keep into account the nested structure. Also fix a problem with how
inlining impacted Plist diagnostics, and adjust some ranges in the Plist output due to richer information.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151346 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
68fbb3ee8ae374b6505885e907af92b30eef707f 24-Feb-2012 Chad Rosier <mcrosier@apple.com> Revert r151317 - Rework PathDiagnostics creation.. - to appease buildbots.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151338 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
4970ef8e3527ac356c3e9fde0710561fcb63e424 24-Feb-2012 Ted Kremenek <kremenek@apple.com> Rework PathDiagnostic creation so that call stacks are captured by a nested PathDiagnosticCallPiece.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151317 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
5a0917d1367115d5fddfe7551f8634759217b54b 16-Feb-2012 Anna Zaks <ganna@apple.com> [analyzer] Diagnostics: Ensure that the default end of diagnostic path
piece can always be generated.

The default end of diagnostic path piece was failing to generate on a
BlockEdge that was outgoing from a basic block without a terminator,
resulting in a very simple diagnostic being rendered (ex: no path
highlighting or custom visitors). Reuse another function, which is
essentially doing the same thing and correct it not to fail when a block
has no terminator.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150659 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
802e02463b880f53a6e645bde78cc412481ce9e0 08-Feb-2012 Ted Kremenek <kremenek@apple.com> Change PathDiagnosticPieces to be reference counted (simplifying their management), and introduce 'PathPieces' as a common container for PathDiagnosticPieces.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150054 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
eb2303c76971f3cc89bbb367ce77564ccb7042c1 08-Feb-2012 Ted Kremenek <kremenek@apple.com> Refactor pieces of PathDiagnostic into its own data structure. No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150053 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
a6215b93c45ee5931536b57d10b987747143313b 07-Feb-2012 Ted Kremenek <kremenek@apple.com> Create PathDiagnosticCallEnter and PathDiagnosticCallExit, to remark calls in PathDiagnostics from other events. This will
have potential uses later.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149960 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
bac341346f3c8e713a8f165120fd54b500ee3189 26-Jan-2012 Ted Kremenek <kremenek@apple.com> Rework flushing of diagnostics to PathDiagnosticConsumer. Now all the reports are batched up before being flushed
to the underlying consumer implementation. This allows us to unique reports across analyses to multiple functions (which
shows up with inlining).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148997 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
f660f4b1bedd6b614acf52108894b805b807c50d 10-Jan-2012 Ted Kremenek <kremenek@apple.com> Make PathDiagnosticLocation more resilient to null Stmt pointers.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147854 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
99ba9e3bd70671f3441fb974895f226a83ce0e66 20-Dec-2011 David Blaikie <dblaikie@gmail.com> Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146959 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
21a25167b8279df3d8f889d041a4fd98733d3c27 02-Nov-2011 Douglas Gregor <dgregor@apple.com> Fix various minor issues find via unreachable code warnings, from
Ahmed Charles!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143569 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
1d26f48dc2eea1c07431ca1519d7034a21b9bcff 24-Oct-2011 Ted Kremenek <kremenek@apple.com> Rename AnalysisContext to AnalysisDeclContext. Not only is this name more accurate, but it frees up the name AnalysisContext for other uses.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142782 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
ef3643fbbbf66247c5e205497fae0f46e240c143 26-Sep-2011 David Blaikie <dblaikie@gmail.com> Rename PathDiagnosticClient to PathDiagnosticConsumer as per issue 5397


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140492 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
09ca9ef5f92cf4375a19bf7a80d571779c9f370f 21-Sep-2011 Anna Zaks <ganna@apple.com> [analyzer] Fix a bug where PathDiagnosticLocation did not generate a valid range and add asserts to check validity of locations early on. Ignore invalid ranges in PathDiagnosticPiece (they could be added by checker writers).

Addresses radar://10124836 and radar://radar10102244.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140218 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
ef70724e66d8ede0edbe260fbcdd9781688bb1fd 21-Sep-2011 Anna Zaks <ganna@apple.com> [analyzer] Refactor PathDiagnosticLocation: Remove SourceRange member from PathDiagnosticLocation - FullSourceLoc Loc and PathDiagnosticRange Range are sufficient.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140206 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
bc0a3016b9fd51f84780f0f82fb0f7f2ca93e8ff 21-Sep-2011 Anna Zaks <ganna@apple.com> [analyzer] Remove dead code. (This code is trying to implement the idea that PathDiagnosticClient could implement DiagnosticClient and has been dead for a while).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140198 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
590dd8e0959d8df5621827768987c4792b74fc06 20-Sep-2011 Anna Zaks <ganna@apple.com> [analyzer] Refactor PathDiagnosticLocation: Make PathDiagnosticLocation(SourceLocation...) private. Most of the effort here goes to making BugReport refer to a PathDiagnosticLocation instead of FullSourceLocation.

(Another step closer to the goal of having Diagnostics which can recover from invalid SourceLocations.)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140182 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
77ce46d769b581b8a6ddb0d58231b8be9a8a6026 20-Sep-2011 Anna Zaks <ganna@apple.com> [analyzer] Refactor PathDiagnosticLocation: Use the pre-computed Range and Location for profile.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140180 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
b66f4867702697f1f097ab95f8a23a39310430e0 20-Sep-2011 Anna Zaks <ganna@apple.com> [analyzer] Refactor PathDiagnosticLocation: Use PointerUnion of LocationContext and AnalysisContext to support creation of PathDiagnosticLocations for checkers which no context sensitivity.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140162 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
e97436732c0f20aa15ecbf92a5f905eee888528f 20-Sep-2011 Anna Zaks <ganna@apple.com> [analyzer] Refactor PathDiagnosticLocation: Lazily query LocationContext for a ParentMap as needed.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140147 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
23803374d8db054192ea6fcb766b87e04f26c8fb 20-Sep-2011 Anna Zaks <ganna@apple.com> [analyzer] Remove LocationContext and a dependency from PathDiagnosticLoaction.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140146 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
b490c4bb01a5a3a86947851fa66823dda32ed012 20-Sep-2011 Anna Zaks <ganna@apple.com> [analyzer] Refactor PathDiagnosticLocation: Pre-compute Range and Location with gen methods on object creation instead of computing on demand. This would allow to remove dependency on the other members which help with construction and might not even be valid at later stages (to be removed later on).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140131 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
1531bb0c69d9afff6a6434e4cadf345eb628b287 20-Sep-2011 Anna Zaks <ganna@apple.com> [analyzer] Use more create methods in the PathDiagnostic, cleanup.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140130 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
0cd59482abd8aec9ed1eaad11f5fe9c1e42639f6 16-Sep-2011 Anna Zaks <ganna@apple.com> [analyzer] Refactor: make PathDiagnosticLocation responsible for validation of SourceLocations (commit 5 of ?):
- Get rid of PathDiagnosticLocation(SourceRange r,..) constructor by providing a bunch of create methods.
- The PathDiagnosticLocation(SourceLocation L,..), which is used by crate methods, will eventually become private.
- Test difference is in the case when the report starts at the beginning of the function. We used to represent that point as a range of the very first token in the first statement. Now, it's just a single location representing the first character of the first statement.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139932 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
f2b4e6652f15ed3b9492216badc9688ba7ccfe38 15-Sep-2011 Anna Zaks <ganna@apple.com> [analyzer] Refactor: make PathDiagnosticLocation responsible for validation of SourceLocations (commit 4 of ?):
- The closing brace is always a single location, not a range.
- The test case previously had a location key 57:1 followed by a range [57:1 - 57:1].

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139832 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
4fdf97bf51d2a156cec3232efd6dae110aa02aa0 15-Sep-2011 Anna Zaks <ganna@apple.com> [analyzer] Refactor: make PathDiagnosticLocation responsible for validation of SourceLocations (commit 2 of ?):
- Fix a fixme and move the logic of creating a PathDiagnosticLocation corresponding to a ProgramPoint into a PathDiagnosticLocation constructor.
- Rename PathDiagnosticLocation::create to differentiate from the added constructor.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139825 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
220ac8c175cb1bf9b18d82eefe036995d7a2164d 15-Sep-2011 Anna Zaks <ganna@apple.com> [analyzer] Refactor: make PathDiagnosticLocation responsible for validation of SourceLocations (commit 2 of ?):
- Modify all PathDiagnosticLocation constructors that take Stmt to also requre LocationContext.
- Add a constructor which should be used in case there is no valid statement/location (it will grab the location of the enclosing function).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139763 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
4d353eb8af7324c0ee3736c736668f6c9b162ee0 14-Sep-2011 Anna Zaks <ganna@apple.com> [analyzer] After CFG has been linearized, we can have a situation where an ExpoledNode has an invalid SourceLocation (which has no correspondence in the source code). This commit is the first step to solve this problem.
- It adds LocationContext to the PathDiagnosticLocation object and uses it to lookup the enclosing statement with a valid location.
- So far, the LocationContext is only available when the object is constructed from the ExplodedNode.
- Already found some subtle bugs(in plist-output-alternate.m) where the intermediate diagnostic steps were not previously shown.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139703 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
43f48b0b1bc763dc56db6e01de4fcc44ad389bef 14-Sep-2011 Anna Zaks <ganna@apple.com> [analyzer] Refactor: Make PathDiagnosticLocation responsible for creating a valid object given an ExploadedNode (the same logic can be reused by other checkers).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139672 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
07453ac7b3d46f930733b44a593737bdd98706b6 27-Aug-2011 Ted Kremenek <kremenek@apple.com> [analyzer] Rename current PathDiagnosticClient::HandlePathDiagnostic() to HandlePathDiagnosticImpl(), and slot in new HandlePathDiagnostic() for potentially handling concurrent access to PathDiagnosticClients (in the future).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138713 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
5f9e272e632e951b1efe824cd16acb4d96077930 23-Jul-2011 Chris Lattner <sabre@nondot.org> remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports
them into the clang namespace.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135852 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
56ca35d396d8692c384c785f9aeebcf22563fe1e 17-Feb-2011 John McCall <rjmccall@apple.com> Change the representation of GNU ?: expressions to use a different expression
class and to bind the shared value using OpaqueValueExpr. This fixes an
unnoticed problem with deserialization of these expressions where the
deserialized form would lose the vital pointer-equality trait; or rather,
it fixes it because this patch also does the right thing for deserializing
OVEs.

Change OVEs to not be a "temporary object" in the sense that copy elision is
permitted.

This new representation is not totally unawkward to work with, but I think
that's really part and parcel with the semantics we're modelling here. In
particular, it's much easier to fix things like the copy elision bug and to
make the CFG look right.

I've tried to update the analyzer to deal with this in at least some
obvious cases, and I think we get a much better CFG out, but the printing
of OpaqueValueExprs probably needs some work.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125744 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
9b663716449b618ba0390b1dbebc54fa8e971124 10-Feb-2011 Ted Kremenek <kremenek@apple.com> Split 'include/clang/StaticAnalyzer' into 'include/clang/StaticAnalyzer/Core' and 'include/clang/StaticAnalyzer/Checkers'.

This layout matches lib/StaticAnalyzer, which corresponds to two StaticAnalyzer libraries.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125251 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
811d75ee35b8b061a9b10a4e7b81e0c0eaf739c3 08-Feb-2011 Argyrios Kyrtzidis <akyrtzi@gmail.com> [analyzer] Move the files in lib/StaticAnalyzer to lib/StaticAnalyzer/Core.

Eventually there will also be a lib/StaticAnalyzer/Frontend that will handle initialization and checker registration.
Yet another library to avoid cyclic dependencies between Core and Checkers.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125124 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp