summaryrefslogtreecommitdiffstats
path: root/clang/lib/Analysis/CFG.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [CFG] [analyzer] Add C++17-specific ctor-initializer construction contexts.Artem Dergachev2018-03-221-3/+11
| | | | | | | | | | CXXCtorInitializer-based constructors are also affected by the C++17 mandatory copy elision, like variable constructors and return value constructors. Extend r328248 to support those. Differential Revision: https://reviews.llvm.org/D44763 llvm-svn: 328255
* [CFG] [analyzer] Add C++17-specific variable and return construction contexts.Artem Dergachev2018-03-221-8/+19
| | | | | | | | | | | | | | | | | | | In C++17 copy elision is mandatory for variable and return value constructors (as long as it doesn't involve type conversion) which results in AST that does not contain elidable constructors in their usual places. In order to provide construction contexts in this scenario we need to cover more AST patterns. This patch makes the CFG prepared for these scenarios by: - Fork VariableConstructionContext and ReturnedValueConstructionContext into two different sub-classes (each) one of which indicates the C++17 case and contains a reference to an extra CXXBindTemporaryExpr. - Allow CFGCXXRecordTypedCall element to accept VariableConstructionContext and ReturnedValueConstructionContext as its context. Differential Revision: https://reviews.llvm.org/D44597 llvm-svn: 328248
* [CFG] Allow CallExpr's to be looked up in CFG'sRichard Trieu2018-03-151-0/+3
| | | | | | | | r327343 changed the handling for CallExpr in a CFG, which prevented lookups for CallExpr while other Stmt kinds still worked. This change carries over the necessary bits from Stmt function to CallExpr function. llvm-svn: 327593
* [CFG] [analyzer] Don't add construction context to a return-by-reference call.Artem Dergachev2018-03-121-2/+2
| | | | | | | | | | | | | | Call expressions that return objects by an lvalue reference or an rvalue reference have a value type in the AST but wear an auxiliary flag of being an lvalue or an xvalue respectively. Use the helper method for obtaining the actual return type of the function. Fixes a crash. Differential Revision: https://reviews.llvm.org/D44273 llvm-svn: 327352
* [CFG] [analyzer] Add construction context to C++ return-by-value call elements.Artem Dergachev2018-03-121-56/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a new CFGStmt sub-class, CFGCXXRecordTypedCall, which replaces the regular CFGStmt for the respective CallExpr whenever the CFG has additional information to provide regarding the lifetime of the returned value. This additional call site information is represented by a ConstructionContext (which was previously used for CFGConstructor elements) that provides references to CXXBindTemporaryExpr and MaterializeTemporaryExpr that surround the call. This corresponds to the common C++ calling convention solution of providing the target address for constructing the return value as an auxiliary implicit argument during function call. One of the use cases for such extra context at the call site would be to perform any sort of inter-procedural analysis over the CFG that involves functions returning objects by value. In this case the elidable constructor at the return site would construct the object explained by the context at the call site, and its lifetime would also be managed by the caller, not the callee. The extra context would also be useful for properly handling the return-value temporary at the call site, even if the callee is not being analyzed inter-procedurally. Differential Revision: https://reviews.llvm.org/D44120 llvm-svn: 327343
* [analyzer] Add scope information to CFGMaxim Ostapenko2018-03-121-4/+151
| | | | | | | | | | | This patch adds two new CFG elements CFGScopeBegin and CFGScopeEnd that indicate when a local scope begins and ends respectively. We use first VarDecl declared in a scope to uniquely identify it and add CFGScopeBegin and CFGScopeEnd elements into corresponding basic blocks. Differential Revision: https://reviews.llvm.org/D16403 llvm-svn: 327258
* [CFG] [analyzer] Add construction context for implicit constructor conversions.Artem Dergachev2018-03-091-1/+6
| | | | | | | | | | | | | Implicit constructor conversions such as A a = B() are represented by surrounding the constructor for B() with an ImplicitCastExpr of CK_ConstructorConversion kind, similarly to how explicit constructor conversions are surrounded by a CXXFunctionalCastExpr. Support this syntax pattern when extracting the construction context for the implicit constructor that performs the conversion. Differential Revision: https://reviews.llvm.org/D44051 llvm-svn: 327096
* Fix an unused variable warning; NFCGeorge Burgess IV2018-03-061-0/+1
| | | | llvm-svn: 326767
* [CFG] [analyzer] Recall that we only skip NoOp casts in construction contexts.Artem Dergachev2018-03-011-1/+3
| | | | | | | | | | | | For now. We should also add support for ConstructorConversion casts as presented in the attached test case, but this requires more changes because AST around them seems different. The check was originally present but was accidentally lost during r326021. Differential Revision: https://reviews.llvm.org/D43840 llvm-svn: 326402
* [CFG] NFC: Refactor ConstructionContext into a finite set of cases.Artem Dergachev2018-02-271-43/+75
| | | | | | | | | | | | | | | | | | | | | ConstructionContext is moved into a separate translation unit and is separated into multiple classes. The "old" "raw" ConstructionContext is renamed into ConstructionContextLayer - which corresponds to the idea of building the context gradually layer-by-layer, but it isn't easy to use in the clients. Once CXXConstructExpr is reached, layers that we've gathered so far are transformed into the actual, "new-style" "flat" ConstructionContext, which is put into the CFGConstructor element and has no layers whatsoever (until it actually needs them, eg. aggregate initialization). The new-style ConstructionContext is instead presented as a variety of sub-classes that enumerate different ways of constructing an object in C++. There are 5 of these supported for now, which is around a half of what needs to be supported. The layer-by-layer buildup process is still a little bit weird, but it hides all the weirdness in one place, that sounds like a good thing. Differential Revision: https://reviews.llvm.org/D43533 llvm-svn: 326238
* [CFG] Keep speculatively working around an MSVC compiler crash.Artem Dergachev2018-02-241-9/+31
| | | | | | | | | | | | | Replace if() with a switch(). Because random changes in the code seem to suppress the crash. Story so far: r325966 - Crash introduced. r325969 - Speculative fix had no effect. r325978 - Tried to bisect the offending function, crash suddenly disappeared. r326016 - After another random change in the code, bug appeared again. llvm-svn: 326021
* [CFG] Provide construction contexts for temporaries in conditional operators.Artem Dergachev2018-02-241-0/+3
| | | | | | | | | | | | | When a lifetime-extended temporary is on a branch of a conditional operator, materialization of such temporary occurs after the condition is resolved. This change allows us to understand, by including the MaterializeTemporaryExpr in the construction context, the target for temporary materialization in such cases. Differential Revision: https://reviews.llvm.org/D43483 llvm-svn: 326019
* [CFG] Provide construction contexts for temporaries bound to const references.Artem Dergachev2018-02-241-0/+3
| | | | | | | | | | In order to bind a temporary to a const lvalue reference, a no-op cast is added to make the temporary itself const, and only then the reference is taken (materialized). Skip the no-op cast when looking for the construction context. Differential Revision: https://reviews.llvm.org/D43481 llvm-svn: 326016
* [CFG] Provide construction contexts for functional cast-like constructors.Artem Dergachev2018-02-241-0/+2
| | | | | | | | | | When a constructor of a temporary with a single argument is treated as a functional cast expression, skip the functional cast expression and provide the correct construction context for the temporary. Differential Revision: https://reviews.llvm.org/D43480 llvm-svn: 326015
* [CFG] Provide construction contexts for lifetime-extended temporaries.Artem Dergachev2018-02-241-1/+24
| | | | | | | | | | | | | | When constructing a temporary that is going to be lifetime-extended through a MaterializeTemporaryExpr later, CFG elements for the respective constructor can now be queried to obtain the reference to that MaterializeTemporaryExpr and therefore gain information about lifetime extension. This may produce multi-layered construction contexts when information about both temporary destruction and lifetime extension is available. Differential Revision: https://reviews.llvm.org/D43477 llvm-svn: 326014
* [CFG] Try to narrow down MSVC compiler crash via binary search.Artem Dergachev2018-02-231-11/+17
| | | | | | | | | | Split the presumably offending function in two to see which part of it causes the crash to occur. The crash was introduced in r325966. r325969 did not help. llvm-svn: 325978
* [CFG] NFC: Speculative attempt to fix MSVC internal compiler error on buildbot.Artem Dergachev2018-02-231-3/+6
| | | | | | Don't use fancy initialization and member access in a DenseMap. llvm-svn: 325969
* [CFG] [analyzer] NFC: Allow more complicated construction contexts.Artem Dergachev2018-02-231-24/+50
| | | | | | | | | | | | | | ConstructionContexts introduced in D42672 are an additional piece of information included with CFGConstructor elements that help the client of the CFG (such as the Static Analyzer) understand where the newly constructed object is stored. The patch refactors the ConstructionContext class to prepare for including multi-layered contexts that are being constructed gradually, layer-by-layer, as the AST is traversed. Differential Revision: https://reviews.llvm.org/D43428 llvm-svn: 325966
* [CFG] Provide construction contexts for temproary objects.Artem Dergachev2018-02-151-1/+3
| | | | | | | | | | | | | | | Constructors of C++ temporary objects that have destructors now can be queried to discover that they're indeed constructing temporary objects. The respective CXXBindTemporaryExpr, which is also repsonsible for destroying the temporary at the end of full-expression, is now available at the construction site in the CFG. This is all the context we need to provide for temporary objects that are not lifetime extended. For lifetime-extended temporaries, more context is necessary. Differential Revision: https://reviews.llvm.org/D43056 llvm-svn: 325210
* Teach Wreturn-type, Wunreachable-code, and alpha.deadcode.UnreachableCode to ↵Nico Weber2018-02-131-1/+1
| | | | | | | | | treat __assume(0) like __builtin_unreachable. Fixes PR29134. https://reviews.llvm.org/D43221 llvm-svn: 325052
* [CFG] Provide construction contexts for return value constructors.Artem Dergachev2018-02-121-0/+2
| | | | | | | | | | | When the current function returns a C++ object by value, CFG elements for constructors that construct the return values can now be queried to discover that they're indeed participating in construction of the respective return value at the respective return statement. Differential Revision: https://reviews.llvm.org/D42875 llvm-svn: 324952
* [CFG] Provide construction contexts when constructors have cleanups.Artem Dergachev2018-02-101-0/+2
| | | | | | | | | | | | | | | Now that we make it possible to query the CFG constructor element to find information about the construction site, possible cleanup work represented by ExprWithCleanups should not prevent us from providing this information. This allows us to have a correct construction context for variables initialized "by value" via elidable copy-constructors, such as 'i' in iterator i = vector.begin(); Differential Revision: https://reviews.llvm.org/D42719 llvm-svn: 324798
* [CFG] Add construction context for constructor initializers.Artem Dergachev2018-02-101-20/+31
| | | | | | | | | | | | | | CFG elements for constructors of fields and base classes that are being initialized before the body of the whole-class constructor starts can now be queried to discover that they're indeed participating in initialization of their respective fields or bases before the whole-class constructor kicks in. CFG construction contexts are now capable of representing CXXCtorInitializer triggers, which aren't considered to be statements in the Clang AST. Differential Revision: https://reviews.llvm.org/D42700 llvm-svn: 324796
* [CFG] Add construction context for simple variable declarations.Artem Dergachev2018-02-101-1/+3
| | | | | | | | | Constructors of simple variables now can be queried to discover that they're constructing into simple variables. Differential Revision: https://reviews.llvm.org/D42699 llvm-svn: 324794
* [CFG] Squash an unused variable introduced in r324668.Artem Dergachev2018-02-091-1/+1
| | | | | | Found by -Werror buildbot. llvm-svn: 324697
* [CFG] Add extra context to C++ constructor statement elements.Artem Dergachev2018-02-081-11/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional information to provide regarding what sort of object is being constructed. It is useful for figuring out what memory is initialized in client of the CFG such as the Static Analyzer, which do not operate by recursive AST traversal, but instead rely on the CFG to provide all the information when they need it. Otherwise, the statement that triggers the construction and defines what memory is being initialized would normally occur after the construct-expression, and the client would need to peek to the next CFG element or use statement parent map to understand the necessary facts about the construct-expression. As a proof of concept, CFGConstructors are added for new-expressions and the respective test cases are provided to demonstrate how it works. For now, the only additional data contained in the CFGConstructor element is the "trigger statement", such as new-expression, which is the parent of the constructor. It will be significantly expanded in later commits. The additional data is organized as an auxiliary structure - the "construction context", which is allocated separately from the CFGElement. Differential Revision: https://reviews.llvm.org/D42672 llvm-svn: 324668
* [Analysis] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2017-12-071-130/+151
| | | | | | other minor fixes (NFC). llvm-svn: 320091
* [Analyzer] Stable iteration on indirect goto LabelDecl's to avoid ↵Aleksei Sidorin2017-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | non-determinism (attempt 2) CFG wass built in non-deterministic order due to the fact that indirect goto labels' declarations (LabelDecl's) are stored in the llvm::SmallSet container. LabelDecl's are pointers, whose order is not deterministic, and llvm::SmallSet sorts them by their non-deterministic addresses after "small" container is exceeded. This leads to non-deterministic processing of the elements of the container. The fix is to use llvm::SmallSetVector that was designed to have deterministic iteration order. Patch by Ilya Palachev! Differential Revision: https://reviews.llvm.org/D40073 llvm-svn: 318754
* Implement CFG construction for __try / __except / __leave.Nico Weber2017-08-231-10/+148
| | | | | | | | | | | | | | | | | | | | | | | This makes -Wunreachable-code work for programs containing SEH (except for __finally, which is still missing for now). __try is modeled like try (but simpler since it can only have a single __except or __finally), __except is fairly similar to catch (but simpler, since it can't contain declarations). __leave is implemented similarly to break / continue. Use the existing addTryDispatchBlock infrastructure (which FindUnreachableCode() in ReachableCode.cpp uses via cfg->try_blocks_begin()) to mark things in the __except blocks as reachable. Re-use TryTerminatedBlock. This means we add EH edges from calls to the __try block, but not from all other statements. While this is incomplete, it matches LLVM's SEH codegen support. Also, in practice, BuildOpts.AddEHEdges is always false in practice from what I can tell, so we never even insert the call EH edges either. https://reviews.llvm.org/D36914 llvm-svn: 311561
* [CFG] Add LoopExit information to CFGPeter Szecsi2017-08-191-0/+24
| | | | | | | | | | | | | | | | This patch introduces a new CFG element CFGLoopExit that indicate when a loop ends. It does not deal with returnStmts yet (left it as a TODO). It hidden behind a new analyzer-config flag called cfg-loopexit (false by default). Test cases added. The main purpose of this patch right know is to make loop unrolling and loop widening easier and more efficient. However, this information can be useful for future improvements in the StaticAnalyzer core too. Differential Revision: https://reviews.llvm.org/D35668 llvm-svn: 311235
* CFG: Add CFGElement for automatic variables that leave the scopeMatthias Gehre2017-07-121-45/+179
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This mimics the implementation for the implicit destructors. The generation of this scope leaving elements is hidden behind a flag to the CFGBuilder, thus it should not affect existing code. Currently, I'm missing a test (it's implicitly tested by the clang-tidy lifetime checker that I'm proposing). I though about a test using debug.DumpCFG, but then I would have to add an option to StaticAnalyzer/Core/AnalyzerOptions to enable the scope leaving CFGElement, which would only be useful to that particular test. Any other ideas how I could make a test for this feature? Reviewers: krememek, jordan_rose Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D15031 llvm-svn: 307759
* [analyzer] Fix crash when building CFG with variable of incomplete typeMartin Bohme2017-03-071-1/+1
| | | | | | | | | | | | | | | | | | Summary: I've included a unit test with a function template containing a variable of incomplete type. Clang compiles this without errors (the standard does not require a diagnostic in this case). Without the fix, this case triggers the crash. Reviewers: klimek Reviewed By: klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30636 llvm-svn: 297129
* PR31631: fix bad CFG (and bogus warnings) when an if-statement has an ↵Richard Smith2017-01-131-41/+36
| | | | | | init-statement and has binary operator as its condition. llvm-svn: 291964
* Extend -Wtautological-overlap-compare to more cases.Richard Trieu2017-01-041-3/+7
| | | | | | | | | | | Previously, -Wtautological-overlap-compare did not warn on cases where the boolean expression was in an assignment or return statement. This patch should cause all boolean statements to be passed to the tautological compare checks in the CFG analysis. This is one of the issues from PR13101 llvm-svn: 290920
* DR1295 and cleanup for P0135R1: Make our initialization code more directlyRichard Smith2016-12-091-6/+8
| | | | | | | | | | | | | | | mirror the description in the standard. Per DR1295, this means that binding a const / rvalue reference to a bit-field no longer "binds directly", and per P0135R1, this means that we materialize a temporary in reference binding after adjusting cv-qualifiers and before performing a derived-to-base cast. In C++11 onwards, this should have fixed the last case where we would materialize a temporary of the wrong type (with a subobject adjustment inside the MaterializeTemporaryExpr instead of outside), but we still have to deal with that possibility in C++98, unless we want to start using xvalues to represent materialized temporaries there too. llvm-svn: 289250
* CFGBuilder: Fix crash when visiting delete expression on dependent typeMartin Bohme2016-12-051-5/+7
| | | | | | | | | | | | | | Summary: CXXDeleteExpr::getDestroyedType() can return a null QualType if the destroyed type is a dependent type. This patch protects against this. Reviewers: klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D27350 llvm-svn: 288665
* Retire llvm::alignOf in favor of C++11 alignof.Benjamin Kramer2016-10-201-2/+1
| | | | | | No functionality change intended. llvm-svn: 284730
* [StaticAnalyzer] Fix UnreachableCode false positives.Daniel Marjamaki2016-10-031-11/+10
| | | | | | | | When there is 'do { } while (0);' in the code the ExplodedGraph and UnoptimizedCFG did not match. Differential Revision: https://reviews.llvm.org/D24759 llvm-svn: 283095
* [CFG] Fix crash finding destructor of lifetime-extended temporary.Devin Coughlin2016-08-021-1/+11
| | | | | | | | | | | Fix a crash under -Wthread-safety when finding the destructor for a lifetime-extending reference. A patch by Nandor Licker! Differential Revision: https://reviews.llvm.org/D22419 llvm-svn: 277522
* P0305R0: Semantic analysis and code generation for C++17 init-statement for ↵Richard Smith2016-07-141-4/+31
| | | | | | | | | | 'if' and 'switch': if (stmt; condition) { ... } Patch by Anton Bikineev! Some minor formatting and comment tweets by me. llvm-svn: 275350
* CFGBuilder: Fix crash when visiting a range-based for over a dependent typeAlexander Kornienko2016-07-081-0/+2
| | | | | | | | | | | | | | | | | Summary: CFG generation is expected to fail in this case, but it should not crash. Also added a test that reproduces the crash. Reviewers: klimek Subscribers: cfe-commits Patch by Martin Boehme! Differential Revision: http://reviews.llvm.org/D21895 llvm-svn: 274834
* Turn copies into references as suggested by clang-tidy's ↵Benjamin Kramer2016-05-271-1/+1
| | | | | | performance-unnecessary-copy-initialization. llvm-svn: 270994
* P0184R0: Allow types of 'begin' and 'end' expressions in range-based for ↵Richard Smith2016-03-201-3/+6
| | | | | | loops to differ. llvm-svn: 263895
* Annotate dump() methods with LLVM_DUMP_METHOD, addressing Richard Smith ↵Yaron Keren2016-01-291-1/+1
| | | | | | r259192 post commit comment. llvm-svn: 259232
* Use range-based for loop to avoid the need for calculating an array size. NFCCraig Topper2015-11-301-4/+1
| | | | llvm-svn: 254282
* [analyzer] Include block capture copy expressions in the CFG.Devin Coughlin2015-11-251-1/+14
| | | | | | | | | | | This prevents spurious dead store warnings when a C++ lambda is casted to a block. I've also added several tests documenting our still-incomplete support for lambda-to-block casts. rdar://problem/22236293 llvm-svn: 254107
* CFG: Delay creating Dtors for CompoundStmts which end in ReturnStmtMatthias Gehre2015-11-141-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: VisitReturnStmt would create a new block with including Dtors, so the Dtors created in VisitCompoundStmts would be in an unreachable block. Example: struct S { ~S(); }; void f() { S s; return; } void g() { S s; } Before this patch, f has one additional unreachable block containing just the destructor of S. With this patch, both f and g have the same blocks. Reviewers: krememek Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D13973 llvm-svn: 253107
* Roll-back r250822.Angel Garcia Gomez2015-10-201-1/+1
| | | | | | | | | | Summary: It breaks the build for the ASTMatchers Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D13893 llvm-svn: 250827
* Apply modernize-use-default to clang.Angel Garcia Gomez2015-10-201-1/+1
| | | | | | | | | | | | Summary: Replace empty bodies of default constructors and destructors with '= default'. Reviewers: bkramer, klimek Subscribers: klimek, alexfh, cfe-commits Differential Revision: http://reviews.llvm.org/D13890 llvm-svn: 250822
* Teach -Wtautological-overlap-compare about enumsGeorge Burgess IV2015-10-011-38/+89
| | | | | | | | | Prior to this patch, -Wtautological-overlap-compare would only warn us if there was a sketchy logical comparison between variables and IntegerLiterals. This patch makes -Wtautological-overlap-compare aware of EnumConstantDecls, so it can apply the same logic to them. llvm-svn: 249053
OpenPOWER on IntegriCloud