summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] Add very limited support for temporary destructorsPavel Labath2013-07-173-2/+16
| | | | | | | | | | | | | | | | | Summary: This patch enables ExprEndgine to reason about temporary object destructors. However, these destructor calls are never inlined, since this feature is still broken. Still, this is sufficient to properly handle noreturn temporary destructors and close bug #15599. I have also enabled the cfg-temporary-dtors analyzer option by default. Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1131 llvm-svn: 186498
* Fix formatting. No functional change.Craig Topper2013-07-161-7/+5
| | | | llvm-svn: 186437
* Add 'const' qualifiers to static const char* variables.Craig Topper2013-07-161-2/+2
| | | | llvm-svn: 186383
* [analyzer] Remove bogus assert: in C++11, 'new' can do list-initialization.Jordan Rose2013-07-101-2/+0
| | | | | | | | | | | | | | Previously, we asserted that whenever 'new' did not include a constructor call, the type must be a non-record type. In C++11, however, uniform initialization syntax (braces) allow 'new' to construct records with list-initialization: "new Point{1, 2}". Removing this assertion should be perfectly safe; the code here matches what VisitDeclStmt does for regions allocated on the stack. <rdar://problem/14403437> llvm-svn: 186028
* [analyzer] Fixup for r185609: actually do suppress warnings coming out of ↵Anna Zaks2013-07-091-4/+4
| | | | | | | | | | | std::list. list is the name of a class, not a namespace. Change the test as well - the previous version did not test properly. Fixes radar://14317928. llvm-svn: 185898
* Use llvm::sys::fs::createUniqueFile.Rafael Espindola2013-07-051-3/+2
| | | | | | | Include a test that clang now produces output files with permissions matching the umask. llvm-svn: 185727
* Fix PR16547.Rafael Espindola2013-07-051-2/+3
| | | | | | | | | | | We should not be asking unique_file to prepend the system temporary directory when creating the html report. Unfortunately I don't think we can test this with the current infrastructure since unique_file ignores MakeAbsolute if the directory is already absolute and the paths provided by lit are. I will take a quick look at making this api a bit less error prone. llvm-svn: 185707
* Use SmallVectorImpl instead of SmallVector for iterators and references to ↵Craig Topper2013-07-041-1/+1
| | | | | | avoid specifying the vector size unnecessarily. llvm-svn: 185610
* [analyzer] Suppress reports reported in std::listAnna Zaks2013-07-041-8/+23
| | | | | | | | | | | The motivation is to suppresses false use-after-free reports that occur when calling std::list::pop_front() or std::list::pop_back() twice. The analyzer does not reason about the internal invariants of the list implementation, so just do not report any of warnings in std::list. Fixes radar://14317928. llvm-svn: 185609
* [analyzer] Make sure that inlined defensive checks work on div by zero.Anna Zaks2013-07-041-5/+9
| | | | | | | This suppresses a false positive in std::hash_map. Fixes radar://14255587. llvm-svn: 185608
* [analyzer] Pointers-to-members are (currently) Locs, not NonLocs.Jordan Rose2013-07-021-1/+1
| | | | | | | | | | While we don't model pointers-to-members besides "null" and "non-null", we were using Loc symbols for valid pointers and NonLoc integers for the null case. This hit the assert committed in r185401. Fixed by using a true (Loc) null for null member pointers. llvm-svn: 185444
* Teach static analyzer about AttributedStmtsPavel Labath2013-07-021-1/+1
| | | | | | | | | | | | | | | Summary: Static analyzer used to abort when encountering AttributedStmts, because it asserted that the statements should not appear in the CFG. This is however not the case, since at least the clang::fallthrough annotation makes it through. This commit simply makes the analyzer ignore the statement attributes. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1030 llvm-svn: 185417
* [analyzer] Explicitly disallow mixed Loc-NonLoc comparisons.Jordan Rose2013-07-021-22/+3
| | | | | | | | | The one bit of code that was using this is gone, and neither C nor C++ actually allows this. Add an assertion and remove dead code. Found by Matthew Dempsky! llvm-svn: 185401
* [analyzer] Handle zeroing CXXConstructExprs.Jordan Rose2013-06-251-1/+32
| | | | | | | | | | | | | | | Re-apply r184511, reverted in r184561, with the trivial default constructor fast path removed -- it turned out not to be necessary here. 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. <rdar://problem/14212563> llvm-svn: 184815
* [analyzer] Don't initialize virtual base classes more than once.Jordan Rose2013-06-251-1/+19
| | | | | | | | | | | | | | | In order to make sure virtual base classes are always initialized once, the AST contains initializers for the base class in /all/ of its descendents, not just the immediate descendents. However, at runtime, the most-derived object is responsible for initializing all the virtual base classes; all the other initializers will be ignored. The analyzer now checks to see if it's being called from another base constructor, and if so does not perform virtual base initialization. <rdar://problem/14236851> llvm-svn: 184814
* Revert "[analyzer] Handle zeroing CXXConstructExprs."Jordan Rose2013-06-211-49/+10
| | | | | | | | | | 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
* [analyzer] Handle zeroing CXXConstructExprs.Jordan Rose2013-06-211-10/+49
| | | | | | | | | | | | | | | | | 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
* Fix static analyzer crash when casting from an incomplete typePavel Labath2013-06-201-1/+4
| | | | | | | | | | | | | | Summary: When doing a reinterpret+dynamic cast from an incomplete type, the analyzer would crash (bug #16308). This fix makes the dynamic cast evaluator ignore incomplete types, as they can never be used in a dynamic_cast. Also adding a regression test. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1006 llvm-svn: 184403
* Fix a crash in the static analyzer (bug #16307)Pavel Labath2013-06-191-1/+4
| | | | | | | | | | | | | | | Summary: When processing a call to a function, which got passed less arguments than it expects, the analyzer would crash. I've also added a test for that and a analyzer warning which detects these cases. CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D994 llvm-svn: 184288
* [analyzer] Do not create a CompoundVal for lvalue InitListExprs.Anna Zaks2013-06-181-4/+7
| | | | | | These should be treated like scalars. This fixes a crash reported in radar://14164698. llvm-svn: 184257
* [AST] Don't include RecursiveASTVisitor.h in ASTContext.hReid Kleckner2013-06-171-0/+2
| | | | | | | | | | | | | | | | | | | | The untemplated implementation of getParents() doesn't need to be in a header file. RecursiveASTVisitor.h is full of repeated macro expansion. Moving this include to ASTContext.cpp speeds up compilation of LambdaMangleContext.cpp, a small C++ file with few includes, from 3.7s to 2.8s for me locally. I haven't measured a full build, but it can't hurt. I had to fix a few static analyzer files that were depending on transitive includes of C++ AST headers. Reviewers: rsmith, klimek Differential Revision: http://llvm-reviews.chandlerc.com/D982 llvm-svn: 184075
* PR12086, PR15117Richard Smith2013-06-121-0/+1
| | | | | | | | | | | | | | | | | | | Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
* Port HTMLDiagnostics to PathV2. No intended functionality change.Benjamin Kramer2013-06-121-34/+22
| | | | llvm-svn: 183849
* Include PathV1.h in files that use it.Rafael Espindola2013-06-111-0/+1
| | | | | | This is preparation for replacing Path.h with PathV2.h. llvm-svn: 183781
* [analyzer; alternate edges] Fix the edge locations in presence of macros.Anna Zaks2013-06-081-1/+1
| | | | | | | | | We drew the diagnostic edges to wrong statements in cases the note was on a macro. The fix is simple, but seems to work just fine for a whole bunch of test cases (plist-macros.cpp). Also, removes an unnecessary edge in edges-new.mm, when function signature starts with a macro. llvm-svn: 183599
* [analyzer] Address Jordan’s code review for r183451Anna Zaks2013-06-061-3/+3
| | | | llvm-svn: 183455
* [analyzer] Ensure that pieces with invalid locations always get removed from ↵Anna Zaks2013-06-061-9/+24
| | | | | | | | | | | the BugReport The function in which we were doing it used to be conditionalized. Add a new unconditional cleanup step. This fixes PR16227 (radar://14073870) - a crash when generating html output for one of the test files. llvm-svn: 183451
* [analyzer] fixup the commentAnna Zaks2013-06-061-1/+1
| | | | llvm-svn: 183450
* [analyzer; new edges] Simplify edges in a C++11 for-range loop.Jordan Rose2013-06-061-16/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously our edges were completely broken here; now, the final result is a very simple set of edges in most cases: one up to the "for" keyword for context, and one into the body of the loop. This matches the behavior for ObjC for-in loops. In the AST, however, CXXForRangeStmts are handled very differently from ObjCForCollectionStmts. Since they are specified in terms of equivalent statements in the C++ standard, we actually have implicit AST nodes for all of the semantic statements. This makes evaluation very easy, but diagnostic locations a bit trickier. Fortunately, the problem can be generally defined away by marking all of the implicit statements as part of the top-level for-range statement. One of the implicit statements in a for-range statement is the declaration of implicit iterators __begin and __end. The CFG synthesizes two separate DeclStmts to match each of these decls, but until now these synthetic DeclStmts weren't in the function's ParentMap. Now, the CFG keeps track of its synthetic statements, and the AnalysisDeclContext will make sure to add them to the ParentMap. <rdar://problem/14038483> llvm-svn: 183449
* [analyzer] Improve debug output for PathDiagnosticPieces.Jordan Rose2013-06-061-54/+75
| | | | | | You can now dump a single PathDiagnosticPiece or PathDiagnosticLocation. llvm-svn: 183367
* [analyzer] Fix a crash that occurs when processing an rvalue array.Anna Zaks2013-06-061-1/+18
| | | | | | | | | | When processing ArrayToPointerDecay, we expect the array to be a location, not a LazyCompoundVal. Special case the rvalue arrays by using a location to represent them. This case is handled similarly elsewhere in the code. Fixes PR16206. llvm-svn: 183359
* [analyzer; new edges] Don't crash if the top-level entry edge is missing.Jordan Rose2013-06-061-7/+13
| | | | | | | | | | | We previously asserted that there was a top-level function entry edge, but if the function decl's location is invalid (or within a macro) this edge might not exist. Change the assertion to an actual check, and don't drop the first path piece if it doesn't match. <rdar://problem/14070304> llvm-svn: 183358
* [analyzer; new edges] Ignore self-edges, not all edges with the same location.Jordan Rose2013-06-061-6/+7
| | | | | | | | | | | | | | | The edge optimizer needs to see edges for, say, implicit casts (which have the same source location as their operand) to uniformly simplify the entire path. However, we still don't want to produce edges from a statement to /itself/, which could occur when two nodes in a row have the same statement location. This necessitated moving the check for redundant notes to after edge optimization, since the check relies on notes being adjacent in the path. <rdar://problem/14061675> llvm-svn: 183357
* [analyzer] Enable the new edge algorithm by default.Jordan Rose2013-06-031-1/+1
| | | | | | | | | ...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
* [analyzer; new edges] Omit subexpression back-edges that span multiple lines.Jordan Rose2013-06-031-1/+16
| | | | | | | | | | | | | | | | A.1 -> A -> B becomes A.1 -> B This only applies if there's an edge from a subexpression to its parent expression, and that is immediately followed by another edge from the parent expression to a subsequent expression. Normally this is useful for bringing the edges back to the left side of the code, but when the subexpression is on a different line the backedge ends up looking strange, and may even obscure code. In these cases, it's better to just continue to the next top-level statement. llvm-svn: 183164
* [analyzer; new edges] Don't eliminate subexpr edge cycles if the line is long.Jordan Rose2013-06-031-23/+83
| | | | | | | | | Specifically, if the line is over 80 characters, or if the top-level statement spans mulitple lines, we should preserve sub-expression edges even if they form a simple cycle as described in the last commit, because it's harder to infer what's going on than it is for shorter lines. llvm-svn: 183163
* [analyzer; new edges] Eliminate "cycle edges" for a single subexpression.Jordan Rose2013-06-031-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | Generating context arrows can result in quite a few arrows surrounding a relatively simple expression, often containing only a single path note. | 1 +--2---+ v/ v auto m = new m // 3 (the path note) |\ | 5 +--4---+ v Note also that 5 and 1 are two ends of the "same" arrow, i.e. they go from event to event. 3 is not an arrow but the path note itself. Now, if we see a pair of edges like 2 and 4---where 4 is the reverse of 2 and there is optionally a single path note between them---we will eliminate /both/ edges. Anything more complicated will be left as is (more edges involved, an inlined call, etc). The next commit will refine this to preserve the arrows in a larger expression, so that we don't lose all context. llvm-svn: 183162
* [analyzer; new edges] Improve enclosing contexts for logical expressions.Jordan Rose2013-06-031-9/+20
| | | | | | | | | | | | | | | | The old edge builder didn't have a notion of nested statement contexts, so there was no special treatment of a logical operator inside an if (or inside another logical operator). The new edge builder always tries to establish the full context up to the top-level statement, so it's important to know how much context has been established already rather than just checking the innermost context. This restores some of the old behavior for the old edge generation: the context of a logical operator's non-controlling expression is the subexpression in the old edge algorithm, but the entire operator expression in the new algorithm. llvm-svn: 183160
* [analyzer; new edges] Include context for edges to sub-expressions.Jordan Rose2013-06-031-254/+177
| | | | | | | | | | | | | | | | | | | | | | | The current edge-generation algorithm sometimes creates edges from a top-level statement A to a sub-expression B.1 that's not at the start of B. This creates a "swoosh" effect where the arrow is drawn on top of the text at the start of B. In these cases, the results are clearer if we see an edge from A to B, then another one from B to B.1. Admittedly, this does create a /lot/ of arrows, some of which merely hop into a subexpression and then out again for a single note. The next commit will eliminate these if the subexpression is simple enough. This updates and reuses some of the infrastructure from the old edge- generation algorithm to find the "enclosing statement" context for a given expression. One change in particular marks the context of the LHS or RHS of a logical binary operator (&&, ||) as the entire operator expression, rather than the subexpression itself. This matches our behavior for ?:, and allows us to handle nested context information. <rdar://problem/13902816> llvm-svn: 183159
* [analyzer; new edges] Include a top-level function entry edge while optimizing.Jordan Rose2013-06-031-23/+29
| | | | | | | | | | Although we don't want to show a function entry edge for a top-level path, having it makes optimizing edges a little more uniform. This does not affect any edges now, but will affect context edge generation (next commit). llvm-svn: 183158
* [analyzer; new edges] add simplifySimpleBranches() to reduce edges for branches.Ted Kremenek2013-05-311-2/+95
| | | | | | | | | | | | In many cases, the edge from the "if" to the condition, followed by an edge from the branch condition to the target code, is uninteresting. In such cases, we should fold the two edges into one from the "if" to the target. This also applies to loops. Implements <rdar://problem/14034763>. llvm-svn: 183018
* [analyzer; new edges] in splitBranchConditionEdges() do not check that ↵Ted Kremenek2013-05-311-22/+26
| | | | | | | | predecessor edge has source in the same lexical scope as the target branch. Fixes <rdar://problem/14031292>. llvm-svn: 182987
* [analyzer;alternate arrows] Rename 'adjustBranchEdges' to ↵Ted Kremenek2013-05-311-4/+9
| | | | | | 'splitBranchConditionEdges'. llvm-svn: 182986
* Revert "[analyzer; alternate edges] don't add an edge incoming from the ↵Jordan Rose2013-05-301-1/+8
| | | | | | | | | | | | | | | | | | | start of a function" ...and make this work correctly in the current codebase. After living on this for a while, it turns out to look very strange for inlined functions that have only a single statement, and somewhat strange for inlined functions in general (since they are still conceptually in the middle of the path, and there is a function-entry path note). It's worth noting that this only affects inlined functions; in the new arrow generation algorithm, the top-level function still starts at the first real statement in the function body, not the enclosing CompoundStmt. This reverts r182078 / dbfa950abe0e55b173286a306ee620eff5f72ea. llvm-svn: 182963
* [analyzer] Don't crash if a block's signature just has the return type.Jordan Rose2013-05-301-4/+9
| | | | | | | | | | | It is okay to declare a block without an argument list: ^ {} or ^void {}. In these cases, the BlockDecl's signature-as-written will just contain the return type, rather than the entire function type. It is unclear if this is intentional, but the analyzer shouldn't crash because of it. <rdar://problem/14018351> llvm-svn: 182948
* [analyzer; new edges] In for(;;), use the ForStmt itself for loop notes.Jordan Rose2013-05-301-3/+6
| | | | | | | | | | | Most loop notes (like "entering loop body") are attached to the condition expression guarding a loop or its equivalent. For loops may not have a condition expression, though. Rather than crashing, just use the entire ForStmt as the location. This is probably the best we can do. <rdar://problem/14016063> llvm-svn: 182904
* [analyzer] Accept references to variables declared "extern void" (C only).Jordan Rose2013-05-292-2/+4
| | | | | | | | | | | | | | | In C, 'void' is treated like any other incomplete type, and though it is never completed, you can cast the address of a void-typed variable to do something useful. (In C++ it's illegal to declare a variable with void type.) Previously we asserted on this code; now we just treat it like any other incomplete type. And speaking of incomplete types, we don't know their extent. Actually check that in TypedValueRegion::getExtent, though that's not being used by any checkers that are on by default. llvm-svn: 182880
* [analyzer] Use the expression’s type instead of region’s type in ↵Anna Zaks2013-05-282-18/+7
| | | | | | | | | ArrayToPointer decay evaluation This gives slightly better precision, specifically, in cases where a non-typed region represents the array or when the type is a non-array type, which can happen when an array is a result of a reinterpret_cast. llvm-svn: 182810
* [analyzer] Re-enable reasoning about CK_LValueBitCastAnna Zaks2013-05-282-4/+7
| | | | | | | | | It’s important for us to reason about the cast as it is used in std::addressof. The reason we did not handle the cast previously was a crash on a test case (see commit r157478). The crash was in processing array to pointer decay when the region type was not an array. Address the issue, by just returning an unknown in that case. llvm-svn: 182808
* [analyzer] Use a more generic MemRegion.getAsOffset to evaluate bin ↵Anna Zaks2013-05-281-69/+71
| | | | | | | | | operators on MemRegions In addition to enabling more code reuse, this suppresses some false positives by allowing us to compare an element region to its base. See the ptr-arith.cpp test cases for an example. llvm-svn: 182780
OpenPOWER on IntegriCloud