summaryrefslogtreecommitdiffstats
path: root/clang/lib/Analysis/CFG.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [CFG] Fix an assertion failure with static initializersGabor Horvath2019-12-231-1/+1
| | | | | | | | | | | | | The CFGBlock::getLastCondition was not prepared for static initializer branches. This patch also revamps CFG unit tests. Earlier the lifetime of the AST was smaller than the CFG. So all the AST pointers within the CFG blocks were dangling. This was OK, since none of the tests dereferenced those pointers. This was, however, a timed bomb. There were patches in the past that were reverted partially due to this problem. Differential revision: https://reviews.llvm.org/D71791
* [CFG] Add an option to expand CXXDefaultInitExpr into aggregate initializationGabor Horvath2019-12-171-3/+29
| | | | | | | | | | This is useful for clients that are relying on linearized CFGs for evaluating subexpressions and want the default initializer to be evaluated properly. The upcoming lifetime analysis is using this but it might also be useful for the static analyzer at some point. Differential Revision: https://reviews.llvm.org/D71642
* [analyzer] Do not cache out on some shared implicit AST nodesGabor Horvath2019-12-111-0/+5
| | | | | | | | | | | Some AST nodes which stands for implicit initialization is shared. The analyzer will do the same evaluation on the same nodes resulting in the same state. The analyzer will "cache out", i.e. it thinks that it visited an already existing node in the exploded graph. This is not true in this case and we lose coverage. Since these nodes do not really require any processing from the analyzer we just omit them from the CFG. Differential Revision: https://reviews.llvm.org/D71371
* [CFG] Fix a flaky crash in CFGBlock::getLastCondition().Artem Dergachev2019-11-211-0/+4
| | | | | | | Using an end iterator of an empty CFG block was causing a garbage pointer dereference. Differential Revision: https://reviews.llvm.org/D69962
* [NFC] Refactor representation of materialized temporariesTyker2019-11-191-4/+4
| | | | | | | | | | | | | | | Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: thakis, sammccall, ilya-biryukov, rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
* Revert "[NFC] Refactor representation of materialized temporaries"Nico Weber2019-11-171-4/+4
| | | | | | This reverts commit 08ea1ee2db5f9d6460fef1d79d0d1d1a5eb78982. It broke ./ClangdTests/FindExplicitReferencesTest.All on the bots, see comments on https://reviews.llvm.org/D69360
* [NFC] Refactor representation of materialized temporariesTyker2019-11-161-4/+4
| | | | | | | | | | | | | | | Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
* New tautological warning for bitwise-or with non-zero constant always true.Richard Trieu2019-10-191-1/+40
| | | | | | | | | | | | | | | | | | Taking a value and the bitwise-or it with a non-zero constant will always result in a non-zero value. In a boolean context, this is always true. if (x | 0x4) {} // always true, intended '&' This patch creates a new warning group -Wtautological-bitwise-compare for this warning. It also moves in the existing tautological bitwise comparisons into this group. A few other changes were needed to the CFGBuilder so that all bool contexts would be checked. The warnings in -Wtautological-bitwise-compare will be off by default due to using the CFG. Fixes: https://bugs.llvm.org/show_bug.cgi?id=42666 Differential Revision: https://reviews.llvm.org/D66046 llvm-svn: 375318
* [OPENMP]Dow not emit warnings for uninitialized loop counters.Alexey Bataev2019-10-171-1/+2
| | | | | | | In OpenMP constructs all counters are initialized and we should not emit warnings about uninitialized privatized loop control variables. llvm-svn: 375167
* Merge and improve code that detects same value in comparisons.Richard Trieu2019-09-211-17/+16
| | | | | | | | | | | | -Wtautological-overlap-compare and self-comparison from -Wtautological-compare relay on detecting the same operand in different locations. Previously, each warning had it's own operand checker. Now, both are merged together into one function that each can call. The function also now looks through member access and array accesses. Differential Revision: https://reviews.llvm.org/D66045 llvm-svn: 372453
* Improve -Wtautological-overlap-compareRichard Trieu2019-09-211-5/+39
| | | | | | | | | Allow this warning to detect a larger number of constant values, including negative numbers, and handle non-int types better. Differential Revision: https://reviews.llvm.org/D66044 llvm-svn: 372448
* [CFG] Add dumps for CFGElement and CFGElementRefKristof Umann2019-09-121-28/+70
| | | | | | | | | Seems like we never had these, so here we go! I also did some refactoring as I was chasing a bug unrelated to this revision. Differential Revision: https://reviews.llvm.org/D66715 llvm-svn: 371765
* [CFG] Fix CFG for statement-expressions in return values.Artem Dergachev2019-08-291-3/+2
| | | | | | | | | | | We're building the CFG from bottom to top, so when the return-value expression has a non-trivial CFG on its own, we need to continue building from the entry to the return-value expression CFG rather than from the block to which we've just appended the return statement. Fixes a false positive warning "control may reach end of non-void function". llvm-svn: 370406
* [analyzer] Fix more analyzer warnings on analyzer and libAnalysis.Artem Dergachev2019-08-281-13/+9
| | | | llvm-svn: 370263
* [CFG] Make representation of destructor calls more accurate.Artem Dergachev2019-08-281-43/+80
| | | | | | | | | | | | | | | | | Respect C++17 copy elision; previously it would generate destructor calls for elided temporaries, including in initialization and return statements. Don't generate duplicate destructor calls for statement expressions. Fix destructors in initialization lists and comma operators. Improve printing of implicit destructors. Patch by Nicholas Allegra! Differential Revision: https://reviews.llvm.org/D66404 llvm-svn: 370247
* [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
OpenPOWER on IntegriCloud