Commit Graph

37 Commits

Author SHA1 Message Date
Ted Kremenek 04e860df2c [analyzer] add a diagnostic event when entering a call via inlining, within the callee, and add an edge.
llvm-svn: 152086
2012-03-06 01:25:01 +00:00
Ted Kremenek 0f0cc35935 [analyzer] when scanning FIDs in a PathDiagnostic, correctly recurse calls and macros.
llvm-svn: 151774
2012-02-29 23:59:20 +00:00
Ted Kremenek 0f70a6f51e [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.

llvm-svn: 151664
2012-02-28 23:27:39 +00:00
Ted Kremenek 60a7820ffe 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.

llvm-svn: 151346
2012-02-24 06:00:00 +00:00
Chad Rosier c0ea158a2b Revert r151317 - Rework PathDiagnostics creation.. - to appease buildbots.
llvm-svn: 151338
2012-02-24 02:06:33 +00:00
Ted Kremenek f2131e7d95 Rework PathDiagnostic creation so that call stacks are captured by a nested PathDiagnosticCallPiece.
llvm-svn: 151317
2012-02-24 00:38:56 +00:00
Anna Zaks 95308d3798 [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.

llvm-svn: 150659
2012-02-16 03:41:01 +00:00
Ted Kremenek afa6e249cb Change PathDiagnosticPieces to be reference counted (simplifying their management), and introduce 'PathPieces' as a common container for PathDiagnosticPieces.
llvm-svn: 150054
2012-02-08 04:32:34 +00:00
Ted Kremenek 3116c4e5cd Refactor pieces of PathDiagnostic into its own data structure. No functionality change.
llvm-svn: 150053
2012-02-08 04:32:27 +00:00
Ted Kremenek 0298834e46 Create PathDiagnosticCallEnter and PathDiagnosticCallExit, to remark calls in PathDiagnostics from other events. This will
have potential uses later.

llvm-svn: 149960
2012-02-07 02:27:37 +00:00
Ted Kremenek 8e4c4266de 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).

llvm-svn: 148997
2012-01-25 23:47:14 +00:00
Ted Kremenek c07e34ceed Make PathDiagnosticLocation more resilient to null Stmt pointers.
llvm-svn: 147854
2012-01-10 15:26:13 +00:00
David Blaikie 68e081d606 Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
llvm-svn: 146959
2011-12-20 02:48:34 +00:00
Douglas Gregor 07216d174e Fix various minor issues find via unreachable code warnings, from
Ahmed Charles!

llvm-svn: 143569
2011-11-02 20:52:01 +00:00
Ted Kremenek 81ce1c8a99 Rename AnalysisContext to AnalysisDeclContext. Not only is this name more accurate, but it frees up the name AnalysisContext for other uses.
llvm-svn: 142782
2011-10-24 01:32:45 +00:00
David Blaikie 53c125d063 Rename PathDiagnosticClient to PathDiagnosticConsumer as per issue 5397
llvm-svn: 140492
2011-09-26 00:51:36 +00:00
Anna Zaks 15ca5e7a21 [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.

llvm-svn: 140218
2011-09-21 00:35:58 +00:00
Anna Zaks d70da08160 [analyzer] Refactor PathDiagnosticLocation: Remove SourceRange member from PathDiagnosticLocation - FullSourceLoc Loc and PathDiagnosticRange Range are sufficient.
llvm-svn: 140206
2011-09-20 23:27:32 +00:00
Anna Zaks 6800ab437c [analyzer] Remove dead code. (This code is trying to implement the idea that PathDiagnosticClient could implement DiagnosticClient and has been dead for a while).
llvm-svn: 140198
2011-09-20 22:30:48 +00:00
Anna Zaks c29bed3989 [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.)

llvm-svn: 140182
2011-09-20 21:38:35 +00:00
Anna Zaks b2dfc2b7be [analyzer] Refactor PathDiagnosticLocation: Use the pre-computed Range and Location for profile.
llvm-svn: 140180
2011-09-20 21:25:00 +00:00
Anna Zaks 83128bc101 [analyzer] Refactor PathDiagnosticLocation: Use PointerUnion of LocationContext and AnalysisContext to support creation of PathDiagnosticLocations for checkers which no context sensitivity.
llvm-svn: 140162
2011-09-20 18:23:52 +00:00
Anna Zaks de03d72a7b [analyzer] Refactor PathDiagnosticLocation: Lazily query LocationContext for a ParentMap as needed.
llvm-svn: 140147
2011-09-20 16:37:36 +00:00
Anna Zaks 22fec1c4d9 [analyzer] Remove LocationContext and a dependency from PathDiagnosticLoaction.
llvm-svn: 140146
2011-09-20 16:23:37 +00:00
Anna Zaks 745486a5da [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).
llvm-svn: 140131
2011-09-20 01:51:40 +00:00
Anna Zaks de8c5eddb9 [analyzer] Use more create methods in the PathDiagnostic, cleanup.
llvm-svn: 140130
2011-09-20 01:38:47 +00:00
Anna Zaks efd182d992 [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.

llvm-svn: 139932
2011-09-16 19:18:30 +00:00
Anna Zaks 207c68012a [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]. 

llvm-svn: 139832
2011-09-15 20:06:34 +00:00
Anna Zaks 921f04924f [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.

llvm-svn: 139825
2011-09-15 18:56:07 +00:00
Anna Zaks 3a769bd996 [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).

llvm-svn: 139763
2011-09-15 01:08:34 +00:00
Anna Zaks 615e3a69c3 [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. 

llvm-svn: 139703
2011-09-14 17:48:01 +00:00
Anna Zaks 2c65eea947 [analyzer] Refactor: Make PathDiagnosticLocation responsible for creating a valid object given an ExploadedNode (the same logic can be reused by other checkers).
llvm-svn: 139672
2011-09-14 00:25:17 +00:00
Ted Kremenek 996bfab499 [analyzer] Rename current PathDiagnosticClient::HandlePathDiagnostic() to HandlePathDiagnosticImpl(), and slot in new HandlePathDiagnostic() for potentially handling concurrent access to PathDiagnosticClients (in the future).
llvm-svn: 138713
2011-08-27 21:39:14 +00:00
Chris Lattner 0e62c1cc0b remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports
them into the clang namespace.

llvm-svn: 135852
2011-07-23 10:55:15 +00:00
John McCall c07a0c7e48 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.

llvm-svn: 125744
2011-02-17 10:25:35 +00:00
Ted Kremenek f8cbac4b91 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.

llvm-svn: 125251
2011-02-10 01:03:03 +00:00
Argyrios Kyrtzidis fa0734ec4f [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.

llvm-svn: 125124
2011-02-08 22:30:36 +00:00