summaryrefslogtreecommitdiffstats
path: root/clang/lib/Analysis/CFG.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-301-7/+12
| | | | | | | | | It seems the two failing tests can be simply fixed after r348037 Fix 3 cases in Analysis/builtin-functions.cpp Delete the bad CodeGen/builtin-constant-p.c for now llvm-svn: 348053
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Fangrui Song2018-11-301-12/+7
| | | | | | | | | | Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp while we are investigating why the following snippet fails: extern char extern_var; struct { int a; } a = {__builtin_constant_p(extern_var)}; llvm-svn: 348039
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-281-7/+12
| | | | | | | This was reverted in r347656 due to me thinking it caused a miscompile of Chromium. Turns out it was the Chromium code that was broken. llvm-svn: 347756
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-271-12/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused a miscompile in Chrome (see crbug.com/908372) that's illustrated by this small reduction: static bool f(int *a, int *b) { return !__builtin_constant_p(b - a) || (!(b - a)); } int arr[] = {1,2,3}; bool g() { return f(arr, arr + 3); } $ clang -O2 -S -emit-llvm a.cc -o - g() should return true, but after r347417 it became false for some reason. This also reverts the follow-up commits. r347417: > Re-Reinstate 347294 with a fix for the failures. > > Don't try to emit a scalar expression for a non-scalar argument to > __builtin_constant_p(). > > Third time's a charm! r347446: > The result of is.constant() is unsigned. r347480: > A __builtin_constant_p() returns 0 with a function type. r347512: > isEvaluatable() implies a constant context. > > Assume that we're in a constant context if we're asking if the expression can > be compiled into a constant initializer. This fixes the issue where a > __builtin_constant_p() in a compound literal was diagnosed as not being > constant, even though it's always possible to convert the builtin into a > constant. r347531: > A "constexpr" is evaluated in a constant context. Make sure this is reflected > if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347656
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-211-7/+12
| | | | | | | | | Don't try to emit a scalar expression for a non-scalar argument to __builtin_constant_p(). Third time's a charm! llvm-svn: 347417
* Revert r347364 again, the fix was incomplete.Nico Weber2018-11-211-12/+7
| | | | llvm-svn: 347389
* Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-201-7/+12
| | | | | | | EvaluateAsInt() is sometimes called in a constant context. When that's the case, we need to specify it as so. llvm-svn: 347364
* Compound literals, enums, et al require const exprBill Wendling2018-11-091-0/+12
| | | | | | | | | | | | | | | | | | Summary: Compound literals, enums, file-scoped arrays, etc. require their initializers and size specifiers to be constant. Wrap the initializer expressions in a ConstantExpr so that we can easily check for this later on. Reviewers: rsmith, shafik Reviewed By: rsmith Subscribers: cfe-commits, jyknight, nickdesaulniers Differential Revision: https://reviews.llvm.org/D53921 llvm-svn: 346455
* [coroutines] Fix fallthrough warning on try/catchBrian Gesiak2018-11-031-12/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The test case added in this diff would incorrectly warn that control flow may fall through without returning. Here's a standalone example: https://godbolt.org/z/dCwXEi The same program, but using `return` instead of `co_return`, does not produce a warning: https://godbolt.org/z/mVldqQ The issue was in how Clang analysis would structure its representation of the control-flow graph. Specifically, when constructing the CFG, `CFGBuilder::Visit` had special handling of a `ReturnStmt`, in which it would place object destructors in the same CFG block as a `return` statement, immediately after it. Doing so would allow the logic in `lib/Sema/AnalysisBasedWarning.cpp` `CheckFallThrough` to work properly in the program that used `return`, correctly determining that no "plain edges" preceded the exit block of the function. Because a `co_return` statement would not enjoy the same treatment when it was being built into the control-flow graph, object destructors would not be placed in the same CFG block as the `co_return`, thus resulting in a "plain edge" preceding the exit block of the function, and so the warning logic would be triggered. Add special casing for `co_return` to Clang analysis, thereby remedying the mistaken warning. Test Plan: `check-clang` Reviewers: GorNishanov, tks2103, rsmith Reviewed By: GorNishanov Subscribers: EricWF, lewissbaker, cfe-commits Differential Revision: https://reviews.llvm.org/D54075 llvm-svn: 346074
* Fix clang -Wimplicit-fallthrough warnings across llvm, NFCReid Kleckner2018-11-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch should not introduce any behavior changes. It consists of mostly one of two changes: 1. Replacing fall through comments with the LLVM_FALLTHROUGH macro 2. Inserting 'break' before falling through into a case block consisting of only 'break'. We were already using this warning with GCC, but its warning behaves slightly differently. In this patch, the following differences are relevant: 1. GCC recognizes comments that say "fall through" as annotations, clang doesn't 2. GCC doesn't warn on "case N: foo(); default: break;", clang does 3. GCC doesn't warn when the case contains a switch, but falls through the outer case. I will enable the warning separately in a follow-up patch so that it can be cleanly reverted if necessary. Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu Differential Revision: https://reviews.llvm.org/D53950 llvm-svn: 345882
* [analyzer] Fix crash in exploded graph dumpingGeorge Karpenkov2018-10-021-4/+1
| | | | | | | | By allocating new DeclStmt to ASTContext Differential Revision: https://reviews.llvm.org/D52756 llvm-svn: 343635
* [cxx2a] P0614R1: Support init-statements in range-based for loops.Richard Smith2018-09-281-1/+4
| | | | | | | We don't yet support this for the case where a range-based for loop is implicitly rewritten to an ObjC for..in statement. llvm-svn: 343350
* [CFG] [analyzer] Disable argument construction contexts for variadic functions.Artem Dergachev2018-08-291-2/+7
| | | | | | | | | | | The analyzer doesn't make use of them anyway and they seem to have pretty weird AST from time to time, so let's just skip them for now. Fixes pr37769. Differential Revision: https://reviews.llvm.org/D50824 llvm-svn: 340975
* [CFG] [analyzer] Find argument constructors in CXXTemporaryObjectExprs.Artem Dergachev2018-08-141-0/+5
| | | | | | | | | | | CXXTemporaryObjectExpr is a sub-class of CXXConstructExpr. If it has arguments that are structures passed by value, their respective constructors need to be handled by providing a ConstructionContext, like for regular function calls and for regular constructors. Differential Revision: https://reviews.llvm.org/D50487 llvm-svn: 339727
* [CFG] [analyzer] NFC: Enumerate construction context layer kinds.Artem Dergachev2018-07-311-13/+12
| | | | | | | | | | | | | | This is a refactoring patch; no functional change intended. The common part of ConstructionContextLayer and ConstructedObjectKey is factored out into a new structure, ConstructionContextItem. Various sub-kinds of ConstructionContextItem are enumerated in order to provide richer information about construction contexts. Differential Revision: https://reviews.llvm.org/D49210. llvm-svn: 338439
* [CFG] [analyzer] Implement function argument construction contexts.Artem Dergachev2018-07-311-10/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | In r330377 and r338425 we have already identified what constitutes function argument constructors and added stubs in order to prevent confusing them with other temporary object constructors. Now we implement a ConstructionContext sub-class to carry all the necessary information about the construction site, namely call expression and argument index. On the analyzer side, the patch interacts with the recently implemented pre-C++17 copy elision support in an interesting manner. If on the CFG side we didn't find a construction context for the elidable constructor, we build the CFG as if the elidable constructor is not elided, and the non-elided constructor within it is a simple temporary. But the same problem may occur in the analyzer: if the elidable constructor has a construction context but the analyzer doesn't implement such context yet, the analyzer should also try to skip copy elision and still inline the non-elided temporary constructor. This was implemented by adding a "roll back" mechanism: when elision fails, roll back the changes and proceed as if it's a simple temporary. The approach is wonky, but i'm fine with that as long as it's merely a defensive mechanism that should eventually go away once all construction contexts become supported. Differential Revision: https://reviews.llvm.org/D48681. llvm-svn: 338436
* [CFG] [analyzer] Add construction contexts for returning C++ objects in ObjC++.Artem Dergachev2018-07-311-27/+43
| | | | | | | | | | | Like any normal funciton, Objective-C message can return a C++ object in Objective-C++. Such object would require a construction context. This patch, therefore, is an extension of r327343 onto Objective-C++. Differential Revision: https://reviews.llvm.org/D48608 llvm-svn: 338426
* [CFG] [analyzer] Add stubs for constructor and message argument constructors.Artem Dergachev2018-07-311-6/+41
| | | | | | | | | | | | | | | | | | CFG now correctly identifies construction context for temporaries constructed for the purpose of passing into a function as an argument. Such context is still not fully implemented because the information it provides is not rich enough: it doens't contain information about argument index. It will be addresssed later. This patch is an extension of r330377 to C++ construct-expressions and Objective-C message expressions which aren't call-expressions but require similar handling. C++ new-expressions with placement arguments still remain to be handled. Differential Revision: https://reviews.llvm.org/D49826 llvm-svn: 338425
* Remove trailing spaceFangrui Song2018-07-301-33/+33
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* Add missing temporary materialization conversion on left-hand side of .Richard Smith2018-07-271-3/+5
| | | | | | | | | in some member function calls. Specifically, when calling a conversion function, we would fail to create the AST node representing materialization of the class object. llvm-svn: 338135
* [CFG] [analyzer] Allow elidable copies to have more than one arguments.Artem Dergachev2018-07-171-1/+0
| | | | | | | | | | Copy-constructors and move-constructors may have default arguments. It is incorrect to assert that they only have one argument, i.e. the reference to the object being copied or moved. Remove the assertion. Differential Revision: https://reviews.llvm.org/D49215 llvm-svn: 337229
* [CFG] [analyzer] Add construction contexts that explain pre-C++17 copy elision.Artem Dergachev2018-06-281-25/+52
| | | | | | | | | | | | | | | | Before C++17 copy elision was optional, even if the elidable copy/move constructor had arbitrary side effects. The elidable constructor is present in the AST, but marked as elidable. In these cases CFG now contains additional information that allows its clients to figure out if a temporary object is only being constructed so that to pass it to an elidable constructor. If so, it includes a reference to the elidable constructor's construction context, so that the client could elide the elidable constructor and construct the object directly at its final destination. Differential Revision: https://reviews.llvm.org/D47616 llvm-svn: 335795
* [CFG] Fix automatic destructors when a member is bound to a reference.Artem Dergachev2018-06-041-33/+29
| | | | | | | | | | | | | | | | | | | In code like const int &x = A().x; automatic destructor for the object A() lifetime-extended by reference 'x' was not present in the clang CFG due to ad-hoc pattern-matching in getReferenceInitTemporaryType(). Re-use skipRValueSubobjectAdjustments() again to find the lifetime-extended object in the AST and emit the correct destructor. Lifetime extension through aggregates with references still needs to be covered. Differential Revision: https://reviews.llvm.org/D44238 llvm-svn: 333941
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-4/+4
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* Track the result of evaluating a computed noexcept specification on theRichard Smith2018-05-031-1/+1
| | | | | | | | | | | | | | FunctionProtoType. We previously re-evaluated the expression each time we wanted to know whether the type is noexcept or not. We now evaluate the expression exactly once. This is not quite "no functional change": it fixes a crasher bug during AST deserialization where we would try to evaluate the noexcept specification in a situation where we have not deserialized sufficient portions of the AST to permit such evaluation. llvm-svn: 331428
* [CFG] [analyzer] Add construction contexts for loop condition variables.Artem Dergachev2018-04-191-2/+14
| | | | | | | | | | | | | | | | | Loop condition variables, eg. while (shared_ptr<int> P = getIntPtr()) { ... }) weren't handled in r324794 because they don't go through the common CFGBuilder::VisitDeclStmt method. Which means that they regressed after r324800. Fix the regression by duplicating the necessary construction context scan in the loop visiting code. Differential Revision: https://reviews.llvm.org/D45706 llvm-svn: 330382
* [CFG] [analyzer] Don't treat argument constructors as temporary constructors.Artem Dergachev2018-04-191-0/+7
| | | | | | | | | | | | | | Function argument constructors (that are used for passing objects into functions by value) are completely unlike temporary object constructors, but we were treating them as such because they are also wrapped into a CXXBindTemporaryExpr. This patch adds a partial construction context layer for call argument values, but doesn't proceed to transform it into an actual construction context yet. This is tells the clients that we aren't supporting these constructors yet. Differential Revision: https://reviews.llvm.org/D45650 llvm-svn: 330377
* [CFG] [analyzer] Work around a disappearing CXXBindTemporaryExpr.Artem Dergachev2018-03-301-10/+10
| | | | | | | | | | | | | Sometimes template instantiation causes CXXBindTemporaryExpr to be missing in its usual spot. In CFG, temporary destructors work by relying on CXXBindTemporaryExprs, so they won't work in this case. Avoid the crash and notify the clients that we've encountered an unsupported AST by failing to provide the ill-formed construction context for the temporary. Differential Revision: https://reviews.llvm.org/D44955 llvm-svn: 328895
* [CFG] [analyzer] Avoid modeling C++17 constructors that aren't fully supported.Artem Dergachev2018-03-301-0/+9
| | | | | | | | | | | | | | Not enough work has been done so far to ensure correctness of construction contexts in the CFG when C++17 copy elision is in effect, so for now we should drop construction contexts in the CFG and in the analyzer when they seem different from what we support anyway. This includes initializations with conditional operators and return values across multiple stack frames. Differential Revision: https://reviews.llvm.org/D44854 llvm-svn: 328893
* [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
OpenPOWER on IntegriCloud