summaryrefslogtreecommitdiffstats
path: root/clang/lib/Analysis/CFG.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [CFG] Introduce CFGElementRef, a wrapper that knows it's position in a CFGBlockKristof Umann2019-08-141-0/+4
| | | | | | | | | | | | | | | | Previously, collecting CFGElements in a set was practially impossible, because both CFGBlock::operator[] and both the iterators returned it by value. One workaround would be to collect the iterators instead, but they don't really capture the concept of an element, and elements from different iterator types are incomparable. This patch introduces CFGElementRef, a wrapper around a (CFGBlock, Index) pair, and a variety of new iterators and iterator ranges to solve this problem. I guess you could say that this patch took a couple iterations to get right :^) Differential Revision: https://reviews.llvm.org/D65196 llvm-svn: 368883
* [analyzer][CFG] Don't track the condition of assertsKristof Umann2019-08-141-0/+65
| | | | | | | | | | | | | | Well, what is says on the tin I guess! Some more changes: * Move isInevitablySinking() from BugReporter.cpp to CFGBlock's interface * Rename and move findBlockForNode() from BugReporter.cpp to ExplodedNode::getCFGBlock() Differential Revision: https://reviews.llvm.org/D65287 llvm-svn: 368836
* Revert r367649: Improve raw_ostream so that you can "write" colors using ↵Rui Ueyama2019-08-021-2/+2
| | | | | | | | operator<< This reverts commit r367649 in an attempt to unbreak Windows bots. llvm-svn: 367658
* Improve raw_ostream so that you can "write" colors using operator<<Rui Ueyama2019-08-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. raw_ostream supports ANSI colors so that you can write messages to the termina with colors. Previously, in order to change and reset color, you had to call `changeColor` and `resetColor` functions, respectively. So, if you print out "error: " in red, for example, you had to do something like this: OS.changeColor(raw_ostream::RED); OS << "error: "; OS.resetColor(); With this patch, you can write the same code as follows: OS << raw_ostream::RED << "error: " << raw_ostream::RESET; 2. Add a boolean flag to raw_ostream so that you can disable colored output. If you disable colors, changeColor, operator<<(Color), resetColor and other color-related functions have no effect. Most LLVM tools automatically prints out messages using colors, and you can disable it by passing a flag such as `--disable-colors`. This new flag makes it easy to write code that works that way. Differential Revision: https://reviews.llvm.org/D65564 llvm-svn: 367649
* [OPENMP]Add support for analysis of if clauses.Alexey Bataev2019-07-161-2/+3
| | | | | | | | | | | | | | | | Summary: Added support for analysis of if clauses in the OpenMP directives to be able to check for the use of uninitialized variables. Reviewers: NoQ Subscribers: guansong, jfb, jdoerfert, caomhin, kkwli0, cfe-commits Tags: clang Differential Revision: https://reviews.llvm.org/D64646 llvm-svn: 366211
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-2/+2
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* [OPENMP]Initial fix PR42392: Improve -Wuninitialized warnings for OpenMP ↵Alexey Bataev2019-07-111-0/+36
| | | | | | | | | | | | | | | | | | | | | | | programs. Summary: Some OpenMP clauses rely on the values of the variables. If the variable is not initialized and used in OpenMP clauses that depend on the variables values, it should be reported that the uninitialized variable is used in the OpenMP clause expression. This patch adds initial processing for uninitialized variables in OpenMP constructs. Currently, it checks for use of the uninitialized variables in the structured blocks. Reviewers: NoQ, Szelethus, dcoughlin, xazax.hun, a.sidorin, george.karpenkov, szepet Subscribers: rnkovacs, guansong, jfb, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64356 llvm-svn: 365786
* [CFG] Add a new function to get the proper condition of a CFGBlockKristof Umann2019-07-051-0/+24
| | | | | | | | | | | | | getTerminatorCondition() returned a condition that may be outside of the block, while the new function returns the proper one: if (A && B && C) {} Return C instead of A && B && C. Differential Revision: https://reviews.llvm.org/D63538 llvm-svn: 365177
* Revert "[analyzer][CFG] Return the correct terminator condition"Kristof Umann2019-07-031-11/+59
| | | | | | | | This reverts commit 7a57118a6fcfa3770f984453543bbdfd0b233e84. Causes a bunch of crashes, I need to time to evaluate this. llvm-svn: 365037
* [analyzer][CFG] Return the correct terminator conditionKristof Umann2019-07-031-59/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the following terminator statement: if (A && B && C && D) The built CFG is the following: [B5 (ENTRY)] Succs (1): B4 [B1] 1: 10 2: j 3: [B1.2] (ImplicitCastExpr, LValueToRValue, int) 4: [B1.1] / [B1.3] 5: int x = 10 / j; Preds (1): B2 Succs (1): B0 [B2] 1: C 2: [B2.1] (ImplicitCastExpr, LValueToRValue, _Bool) T: if [B4.4] && [B3.2] && [B2.2] Preds (1): B3 Succs (2): B1 B0 [B3] 1: B 2: [B3.1] (ImplicitCastExpr, LValueToRValue, _Bool) T: [B4.4] && [B3.2] && ... Preds (1): B4 Succs (2): B2 B0 [B4] 1: 0 2: int j = 0; 3: A 4: [B4.3] (ImplicitCastExpr, LValueToRValue, _Bool) T: [B4.4] && ... Preds (1): B5 Succs (2): B3 B0 [B0 (EXIT)] Preds (4): B1 B2 B3 B4 However, even though the path of execution in B2 only depends on C's value, CFGBlock::getCondition() would return the entire condition (A && B && C). For B3, it would return A && B. I changed this the actual condition. Differential Revision: https://reviews.llvm.org/D63538 llvm-svn: 365036
* Re-check in clang support gun asm goto after fixing tests.Jennifer Yu2019-06-031-16/+58
| | | | llvm-svn: 362410
* Revert "clang support gnu asm goto."Erich Keane2019-05-301-58/+16
| | | | | | | | | | | This reverts commit 954ec09aed4f2be04bb5f4e10dbb4ea8bd19ef9a. Reverting due to test failures as requested by Jennifer Yu. Conflicts: clang/test/CodeGen/asm-goto.c llvm-svn: 362106
* clang support gnu asm goto.Jennifer Yu2019-05-301-16/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Syntax: asm [volatile] goto ( AssemblerTemplate : : InputOperands : Clobbers : GotoLabels) https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html New llvm IR is "callbr" for inline asm goto instead "call" for inline asm For: asm goto("testl %0, %0; jne %l1;" :: "r"(cond)::label_true, loop); IR: callbr void asm sideeffect "testl $0, $0; jne ${1:l};", "r,X,X,~{dirflag},~{fpsr},~{flags}"(i32 %0, i8* blockaddress(@foo, %label_true), i8* blockaddress(@foo, %loop)) #1 to label %asm.fallthrough [label %label_true, label %loop], !srcloc !3 asm.fallthrough: Compiler need to generate: 1> a dummy constarint 'X' for each label. 2> an unique fallthrough label for each asm goto stmt " asm.fallthrough%number". Diagnostic 1> duplicate asm operand name are used in output, input and label. 2> goto out of scope. llvm-svn: 362045
* [analyzer] print() JSONify: CFG implementationCsaba Dabis2019-05-291-1/+13
| | | | | | | | | | | | | | | | | Summary: - Reviewers: NoQ, xazax.hun, ravikandhadai, baloghadamsoftware, Szelethus Reviewed By: NoQ Subscribers: cfe-commits, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp Tags: #clang Differential Revision: https://reviews.llvm.org/D62496 llvm-svn: 362003
* [CFG] Add branch to skip vbase inits when they're handled by superclass.Artem Dergachev2019-05-241-2/+36
| | | | | | | | | | | | | | | | | | | This patch adds the run-time CFG branch that would skip initialization of virtual base classes depending on whether the constructor is called from a superclass constructor or not. Previously the Static Analyzer was already skipping virtual base-class initializers in such constructors, but it wasn't skipping their arguments and their potential side effects, which was causing pr41300 (and was generally incorrect). The previous skipping behavior is now replaced with a hard assertion that we're not even getting there due to how our CFG works. The new CFG element is under a CFG build option so that not to break other consumers of the CFG by this change. Static Analyzer support for this change is implemented. Differential Revision: https://reviews.llvm.org/D61816 llvm-svn: 361681
* [CFG] NFC: Remove implicit conversion from CFGTerminator to Stmt *.Artem Dergachev2019-05-241-10/+19
| | | | | | | | | | | Turn it into a variant class instead. This conversion does indeed save some code but there's a plan to add support for more kinds of terminators that aren't necessarily based on statements, and with those in mind it becomes more and more confusing to have CFGTerminators implicitly convertible to a Stmt *. Differential Revision: https://reviews.llvm.org/D61814 llvm-svn: 361586
* [c++20] Implement P1009R2: allow omitting the array bound in an arrayRichard Smith2019-05-061-2/+2
| | | | | | | | | | new expression. This was voted into C++20 as a defect report resolution, so we retroactively apply it to all prior language modes (though it can never actually be used before C++11 mode). llvm-svn: 360006
* [analyzer] Treat functions without run-time branches as "small".Artem Dergachev2019-04-301-0/+45
| | | | | | | | | | | | | | | | | | Currently we always inline functions that have no branches, i.e. have exactly three CFG blocks: ENTRY, some code, EXIT. This makes sense because when there are no branches, it means that there's no exponential complexity introduced by inlining such function. Such functions also don't trigger various fundamental problems with our inlining mechanism, such as the problem of inlined defensive checks. Sometimes the CFG may contain more blocks, but in practice it still has linear structure because all directions (except, at most, one) of all branches turned out to be unreachable. When this happens, still treat the function as "small". This is useful, in particular, for dealing with C++17 if constexpr. Differential Revision: https://reviews.llvm.org/D61051 llvm-svn: 359531
* [CFG] [analyzer] pr41142: C++17: Skip transparent InitListExprs in constructors.Artem Dergachev2019-03-211-0/+9
| | | | | | | | | | | | | | When searching for construction contexts, i.e. figuring out which statements define the object that is constructed by each construct-expression, ignore transparent init-list expressions because they don't add anything to the context. This allows the Static Analyzer to model construction, destruction, materialization, lifetime extension correctly in more cases. Also fixes a crash caused by incorrectly evaluating initial values of variables initialized with such expressions. Differential Revision: https://reviews.llvm.org/D59573 llvm-svn: 356634
* Add a new builtin: __builtin_dynamic_object_sizeErik Pilkington2019-01-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This builtin has the same UI as __builtin_object_size, but has the potential to be evaluated dynamically. It is meant to be used as a drop-in replacement for libraries that use __builtin_object_size when a dynamic checking mode is enabled. For instance, __builtin_object_size fails to provide any extra checking in the following function: void f(size_t alloc) { char* p = malloc(alloc); strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", __builtin_object_size(p, 0)) } This is an overflow if alloc < 7, but because LLVM can't fold the object size intrinsic statically, it folds __builtin_object_size to -1. With __builtin_dynamic_object_size, alloc is passed through to __builtin___strcpy_chk. rdar://32212419 Differential revision: https://reviews.llvm.org/D56760 llvm-svn: 352665
* 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
OpenPOWER on IntegriCloud