summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [clang] Loop pragma parsing. NFC.Sjoerd Meijer2019-08-151-18/+13
| | | | | | | | Just a refactoring and a tidy up. Differential Revision: https://reviews.llvm.org/D64564 llvm-svn: 368976
* [Clang] Pragma vectorize_predicate implies vectorizeSjoerd Meijer2019-08-151-6/+15
| | | | | | | | | | New pragma "vectorize_predicate(enable)" now implies "vectorize(enable)", and it is ignored when vectorization is disabled with e.g. "vectorize(disable) vectorize_predicate(enable)". Differential Revision: https://reviews.llvm.org/D65776 llvm-svn: 368970
* [Tooling] Add a hack to work around issues with matcher binding in r368681.David L. Jones2019-08-151-2/+4
| | | | | | | | | | | | | | | | | | | | | | The change in r368681 contains a (probably unintentional) behavioral change for rewrite rules with a single matcher. Previously, the single matcher would not need to be bound (`joinCaseMatchers` returned it directly), even though a final DynTypeMatcher was created and bound by `buildMatcher`. With the new change, a single matcher will be bound, in addition to the final binding (which is now in `buildMatchers`, but happens roughly at the same point in the overall flow). This patch simply duplicates the "final matcher" trick: it creates an extra DynTypedMatcher for each rewrite rule case matcher, and unconditionally makes it bindable. This is probably not the right long-term fix, but it does allow existing code to continue to work with this interface. Subscribers: cfe-commits, gribozavr, ymandel Tags: #clang Differential Revision: https://reviews.llvm.org/D66273 llvm-svn: 368958
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-14199-606/+606
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
* Fix handling of class member access into a vector type.Richard Smith2019-08-142-8/+18
| | | | | | | | | | | | | | | | | | | | | | When handling a member access into a non-class, non-ObjC-object type, we would perform a lookup into the surrounding scope as if for an unqualified lookup. If the member access was followed by a '<' and this lookup (or the typo-correction for it) found a template name, we'd treat the member access as naming that template. Now we treat such accesses as never naming a template if the type of the object expression is of vector type, so that vector component accesses are never misinterpreted as naming something else. This is not entirely correct, since it is in fact valid to name a template from the enclosing scope in this context, when invoking a pseudo-destructor for the vector type via an alias template, but that's very much a corner case, and this change leaves that case only as broken as the corresponding case for Objective-C types is. This incidentally adds support for dr2292, which permits a 'template' keyword at the start of a member access naming a pseudo-destructor. llvm-svn: 368940
* [LifetimeAnalysis] Support std::stack::top() and std::optional::value()Matthias Gehre2019-08-141-1/+1
| | | | | | | | | | | | | | Summary: Diagnose dangling pointers that come from std::stack::top() and std::optional::value(). Reviewers: gribozavr Subscribers: cfe-commits, xazax.hun Tags: #clang Differential Revision: https://reviews.llvm.org/D66164 llvm-svn: 368929
* [AMDGPU] Do not assume a default GCN targetStanislav Mekhanoshin2019-08-141-4/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D66246 llvm-svn: 368917
* [OPENMP]Support for non-rectangular loops.Alexey Bataev2019-08-145-84/+580
| | | | | | | | Added basic support for non-rectangular loops. It requires an additional analysis of min/max boundaries for non-rectangular loops. Since only linear dependency is allowed, we can do this analysis. llvm-svn: 368903
* [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
* [NFC][clang] Moving argument handling: Driver::BuildActions -> handleArgumentsPuyan Lotfi2019-08-141-114/+118
| | | | | | | | | | This patch simply moves code that already exists into a new function. Specifically I think it will make the BuildActions code for building a clang job pipeline easier to read and work with. Differential Revision: https://reviews.llvm.org/D66058 llvm-svn: 368881
* [Sema][ObjC] Fix a -Wformat false positive with localizedStringForKeyErik Pilkington2019-08-143-15/+74
| | | | | | | | | | | | Only honour format_arg attributes on -[NSBundle localizedStringForKey] when its argument has a format specifier in it, otherwise its likely to just be a key to fetch localized strings. Fixes rdar://23622446 Differential revision: https://reviews.llvm.org/D27165 llvm-svn: 368878
* [LifetimeAnalysis] Fix false negatives of statement local lifetime analysis ↵Gabor Horvath2019-08-141-19/+42
| | | | | | | | for some STL implementation Differential Revision: https://reviews.llvm.org/D66152 llvm-svn: 368871
* [libTooling] Fix code to avoid unused-function warning after r368681.Yitzhak Mandelbaum2019-08-141-0/+2
| | | | llvm-svn: 368862
* [Tooling] Added DeclStmtClass to ExtractionSemicolonPolicyShaurya Gupta2019-08-141-0/+1
| | | | | | | Since the DeclStmt range includes the semicolon, it doesn't need a semicolon at the end during extraction llvm-svn: 368850
* [analyzer][CFG] Don't track the condition of assertsKristof Umann2019-08-144-100/+122
| | | | | | | | | | | | | | 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
* [clang] - An update after LLVM change.George Rimar2019-08-141-1/+5
| | | | | | SectionRef::getName() was changed to return Expected<> (D66089) llvm-svn: 368825
* Fix _WIN32 / _WIN64 Wundef warningsSven van Haastregt2019-08-141-1/+1
| | | | | | | | For these macros it is the definedness that matters rather than the value. Make new uses of these macros consistent with existing uses. llvm-svn: 368822
* [ASTImporter] Import default expression of param before creating the param.Balazs Keri2019-08-141-19/+47
| | | | | | | | | | | | | | | | | | | | | Summary: The default expression of a parameter variable should be imported before the parameter variable object is created. Otherwise the function is created with an incomplete parameter variable (default argument is nullptr) and in this intermediary state the expression is imported. This import can have a reference to the incomplete parameter variable that causes crash. Reviewers: martong, a.sidorin, shafik Reviewed By: martong Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65577 llvm-svn: 368818
* [analyzer] Note last writes to a condition only in a nested stackframeKristof Umann2019-08-141-4/+9
| | | | | | | | | Exactly what it says on the tin! The comments in the code detail this a little more too. Differential Revision: https://reviews.llvm.org/D64272 llvm-svn: 368817
* Fix the -Wunused-variable warning.Haojian Wu2019-08-142-2/+2
| | | | llvm-svn: 368808
* [NewPM][PassInstrumentation] IR printing support from clang driverTaewook Oh2019-08-141-1/+5
| | | | | | | | | | | | | | Summary: https://reviews.llvm.org/D50923 enabled the IR printing support for the new pass manager, but only for the case when `opt` tool is used as a driver. This patch is to enable the IR printing when `clang` is used as a driver. Reviewers: fedor.sergeev, philip.pfaffe Subscribers: cfe-commits, yamauchi, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65975 llvm-svn: 368804
* Add __has_builtin support for builtin function-like type traits.Richard Smith2019-08-141-13/+30
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously __has_builtin(__builtin_*) would return false for __builtin_*s that we modeled as keywords rather than as functions (because they take type arguments). With this patch, all builtins that are called with function-call-like syntax return true from __has_builtin (covering __builtin_* and also the __is_* and __has_* type traits and the handful of similar builtins without such a prefix). Update the documentation on __has_builtin and on type traits to match. While doing this I noticed the type trait documentation was out of date and incomplete; that's fixed here too. Reviewers: aaron.ballman Subscribers: jfb, kristina, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66100 llvm-svn: 368785
* [analyzer] Don't delete TaintConfig copy constructorAlex Langford2019-08-141-2/+2
| | | | | | | | | | | | | | | | | | | | | Summary: Explicitly deleting the copy constructor makes compiling the function `ento::registerGenericTaintChecker` difficult with some compilers. When we construct an `llvm::Optional<TaintConfig>`, the optional is constructed with a const TaintConfig reference which it then uses to invoke the deleted TaintConfig copy constructor. I've observered this failing with clang 3.8 on Ubuntu 16.04. Reviewers: compnerd, Szelethus, boga95, NoQ, alexshap Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, Charusso, llvm-commits, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66192 llvm-svn: 368779
* [analyzer][NFC] Prepare visitors for different tracking kindsKristof Umann2019-08-144-63/+70
| | | | | | | | | | | | | | | | | | | | | | | When we're tracking a variable that is responsible for a null pointer dereference or some other sinister programming error, we of course would like to gather as much information why we think that the variable has that specific value as possible. However, the newly introduced condition tracking shows that tracking all values this thoroughly could easily cause an intolerable growth in the bug report's length. There are a variety of heuristics we discussed on the mailing list[1] to combat this, all of them requiring to differentiate in between tracking a "regular value" and a "condition". This patch introduces the new `bugreporter::TrackingKind` enum, adds it to several visitors as a non-optional argument, and moves some functions around to make the code a little more coherent. [1] http://lists.llvm.org/pipermail/cfe-dev/2019-June/062613.html Differential Revision: https://reviews.llvm.org/D64270 llvm-svn: 368777
* [analyzer] Track the right hand side of the last store regardless of its valueKristof Umann2019-08-131-13/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The following code snippet taken from D64271#1572188 has an issue: namely, because `flag`'s value isn't undef or a concrete int, it isn't being tracked. int flag; bool coin(); void foo() { flag = coin(); } void test() { int *x = 0; int local_flag; flag = 1; foo(); local_flag = flag; if (local_flag) x = new int; foo(); local_flag = flag; if (local_flag) *x = 5; } This, in my opinion, makes no sense, other values may be interesting too. Originally added by rC185608. Differential Revision: https://reviews.llvm.org/D64287 llvm-svn: 368773
* [analyzer] Prune calls to functions with linear CFGs that return a non-zero ↵Kristof Umann2019-08-131-16/+34
| | | | | | | | | | | | | | | | constrained value During the evaluation of D62883, I noticed a bunch of totally meaningless notes with the pattern of "Calling 'A'" -> "Returning value" -> "Returning from 'A'", which added no value to the report at all. This patch (not only affecting tracked conditions mind you) prunes diagnostic messages to functions that return a value not constrained to be 0, and are also linear. Differential Revision: https://reviews.llvm.org/D64232 llvm-svn: 368771
* [clang][DirectoryWatcher] Fix Windows stub after LLVM changeJan Korous2019-08-131-2/+4
| | | | | | | | | r367979 changed DirectoryWatcher::Create to return an llvm::Expected. Adjust the Windows stub accordingly. (upstreamed from github.com/apple/swift-clang) llvm-svn: 368762
* [clang] DirectoryWatcher for Windows stubs (to fix build break).Jan Korous2019-08-132-0/+50
| | | | | | | | | This is just a code skeleton for DirectoryWatcher-windows.cpp so the build on Windows stops breaking. (upstreamed from github.com/apple/swift-clang) llvm-svn: 368761
* [analyzer][NFC] Make sure that the BugReport is not modified during the ↵Kristof Umann2019-08-133-11/+14
| | | | | | | | | | | | construction of non-visitor pieces I feel this is kinda important, because in a followup patch I'm adding different kinds of interestingness, and propagating the correct kind in BugReporter.cpp is just one less thing to worry about. Differential Revision: https://reviews.llvm.org/D65578 llvm-svn: 368755
* Add a missing header comment, NFCErik Pilkington2019-08-131-0/+13
| | | | llvm-svn: 368754
* [analyzer][NFC] Refactoring BugReporter.cpp P6.: Completely get rid of ↵Kristof Umann2019-08-131-97/+0
| | | | | | | | | | | | | | | | interestingness propagation Apparently this does literally nothing. When you think about this, it makes sense. If something is really important, we're tracking it anyways, and that system is sophisticated enough to mark actually interesting statements as such. I wouldn't say that it's even likely that subexpressions are also interesting (array[10 - x + x]), so I guess even if this produced any effects, its probably undesirable. Differential Revision: https://reviews.llvm.org/D65487 llvm-svn: 368752
* [WebAssembly] Make clang emit correct va_arg code for structsGuanzhong Chen2019-08-131-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | Summary: In the WebAssembly backend, when lowering variadic function calls, non-single member aggregate type arguments are always passed by pointer. However, when emitting va_arg code in clang, the arguments are instead read as if they are passed directly. This results in the pointer being read as the actual structure. Fixes https://github.com/emscripten-core/emscripten/issues/9042. Reviewers: tlively, sbc100, kripken, aheejin, dschuff Reviewed By: dschuff Subscribers: dschuff, jgravelle-google, sunfish, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66168 llvm-svn: 368750
* [analyzer][NFC] Address inlines of D65484Kristof Umann2019-08-131-37/+38
| | | | llvm-svn: 368745
* [Refactor] Moving SourceExtraction header from lib to includeShaurya Gupta2019-08-133-53/+2
| | | | | | | | | | | | | | | Summary: - Moved the SourceExtraction header from lib to include so that it can be used in clangd. Reviewers: arphaman Subscribers: ilya-biryukov, dexonsmith, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65878 llvm-svn: 368743
* Don't use std::errcAlexey Bataev2019-08-131-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As noted on Errc.h: // * std::errc is just marked with is_error_condition_enum. This means that // common patters like AnErrorCode == errc::no_such_file_or_directory take // 4 virtual calls instead of two comparisons. And on some libstdc++ those virtual functions conclude that ------------------------ int main() { std::error_code foo = std::make_error_code(std::errc::no_such_file_or_directory); return foo == std::errc::no_such_file_or_directory; } ------------------------- should exit with 0. Reviewers: thakis, rnk, jfb Reviewed By: thakis Subscribers: lebedev.ri, dexonsmith, xbolva00, cfe-commits, caomhin Tags: #clang Differential Revision: https://reviews.llvm.org/D66143 llvm-svn: 368739
* Revert "Fix crash on switch conditions of non-integer types in templates"Dmitri Gribenko2019-08-132-11/+0
| | | | | | This reverts commit r368706. It broke ClangTidy tests. llvm-svn: 368738
* [analyzer][NFC] Refactoring BugReporter.cpp P5.: Compact mile long function ↵Kristof Umann2019-08-132-378/+451
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | invocations into objects In D65379, I briefly described the construction of bug paths from an ExplodedGraph. This patch is about refactoring the code processing the bug path into a bug report. A part of finding a valid bug report was running all visitors on the bug path, so we already have a (possibly empty) set of diagnostics for each ExplodedNode in it. Then, for each diagnostic consumer, we construct non-visitor diagnostic pieces. * We first construct the final diagnostic piece (the warning), then * We start ascending the bug path from the error node's predecessor (since the error node itself was used to construct the warning event). For each node * We check the location (whether its a CallEnter, CallExit) etc. We simultaneously keep track of where we are with the execution by pushing CallStack when we see a CallExit (keep in mind that everything is happening in reverse!), popping it when we find a CallEnter, compacting them into a single PathDiagnosticCallEvent. void f() { bar(); } void g() { f(); error(); // warning } === The bug path === (root) -> f's CallEnter -> bar() -> f's CallExit -> (error node) === Constructed report === f's CallEnter -> bar() -> f's CallExit ^ / \ V (root) ---> f's CallEvent --> (error node) * We also keep track of different PathPieces different location contexts * (CallEvent::path in the above example has f's LocationContext, while the CallEvent itself is in g's context) in a LocationContextMap object. Construct whatever piece, if any, is needed for the note. * If we need to generate edges (or arrows) do so. Make sure to also connect these pieces with the ones that visitors emitted. * Clean up the constructed PathDiagnostic by making arrows nicer, pruning function calls, etc. So I complained about mile long function invocations with seemingly the same parameters being passed around. This problem, as I see it, a natural candidate for creating classes and tying them all together. I tried very hard to make the implementation feel natural, like, rolling off the tongue. I introduced 2 new classes: PathDiagnosticBuilder (I mean, I kept the name but changed almost everything in it) contains every contextual information (owns the bug path, the diagnostics constructed but the visitors, the BugReport itself, etc) needed for constructing a PathDiagnostic object, and is pretty much completely immutable. BugReportContruct is the object containing every non-contextual information (the PathDiagnostic object we're constructing, the current location in the bug path, the location context map and the call stack I meantioned earlier), and is passed around all over the place as a single entity instead of who knows how many parameters. I tried to used constness, asserts, limiting visibility of fields to my advantage to clean up the code big time and dramatically improve safety. Also, whenever I found the code difficult to understand, I added comments and/or examples. Here's a complete list of changes and my design philosophy behind it: * Instead of construcing a ReportInfo object (added by D65379) after finding a valid bug report, simply return an optional PathDiagnosticBuilder object straight away. Move findValidReport into the class as a static method. I find GRBugReporter::generatePathDiagnostics a joy to look at now. * Rename generatePathDiagnosticForConsumer to generate (maybe not needed, but felt that way in the moment) and moved it to PathDiagnosticBuilder. If we don't need to generate diagnostics, bail out straight away, like we always should have. After that, construct a BugReportConstruct object, leaving the rest of the logic untouched. * Move all static methods that would use contextual information into PathDiagnosticBuilder, reduce their parameter count drastically by simply passing around a BugReportConstruct object. * Glance at the code I removed: Could you tell what the original PathDiagnosticBuilder::LC object was for? It took a gooood long while for me to realize that nothing really. It is always equal with the LocationContext associated with our current position in the bug path. Remove it completely. * The original code contains the following expression quite a bit: LCM[&PD.getActivePath()], so what does it mean? I said that we collect the contexts associated with different PathPieces, but why would we ever modify that, shouldn't it be set? Well, theoretically yes, but in the implementation, the address of PathDiagnostic::getActivePath doesn't change if we move to an outer, previously unexplored function. Add both descriptive method names and explanations to BugReportConstruct to help on this. * Add plenty of asserts, both for safety and as a poor man's documentation. Differential Revision: https://reviews.llvm.org/D65484 llvm-svn: 368737
* [analyzer][NFC] Refactoring BugReporter.cpp P4.: If it can be const, make it ↵Kristof Umann2019-08-138-80/+82
| | | | | | | | | | | | | | const When I'm new to a file/codebase, I personally find C++'s strong static type system to be a great aid. BugReporter.cpp is still painful to read however: function calls are made with mile long parameter lists, seemingly all of them taken with a non-const reference/pointer. This patch fixes nothing but this: make a few things const, and hammer it until it compiles. Differential Revision: https://reviews.llvm.org/D65382 llvm-svn: 368735
* [NFC][clang] Adding argument based Phase list filtering to getComplicationPhasesPuyan Lotfi2019-08-132-10/+62
| | | | | | | | | | This patch removes usage of FinalPhase from anywhere outside of the scope where it is used to do argument handling. It also adds argument based trimming of the Phase list pulled out of the Types.def table. Differential Revision: https://reviews.llvm.org/D65993 llvm-svn: 368734
* [clang] Refactor doc comments to Decls attributionJan Korous2019-08-135-216/+281
| | | | | | | | | | | | - Create ASTContext::attachCommentsToJustParsedDecls so we don't have to load external comments in Sema when trying to attach existing comments to just parsed Decls. - Keep comments ordered and cache their decomposed location - faster SourceLoc-based searching. - Optimize work with redeclarations. - Keep one comment per redeclaration chain (represented by canonical Decl) instead of comment per redeclaration. - For redeclaration chains with no comment attached keep just the last declaration in chain that had no comment instead of every comment-less redeclaration. Differential Revision: https://reviews.llvm.org/D65301 llvm-svn: 368732
* clang: Don't warn on unused momit-leaf-frame-pointer when frame pointers are ↵Nico Weber2019-08-131-3/+14
| | | | | | | | | | | | | | | | | | | | off. This fixes a regression from r365860: As that commit message states, there are 3 valid states targeted by the combination of -f(no-)omit-frame-pointer and -m(no-)omit-leaf-frame-pointer. After r365860 it's impossible to get from state 10 (omit just leaf frame pointers) to state 11 (omit all frame pointers) in a single command line without getting a warning. This change restores that functionality. Fixes PR42966. Differential Revision: https://reviews.llvm.org/D66142 llvm-svn: 368728
* [analyzer][NFC] Refactoring BugReporter.cpp P3.: ↵Kristof Umann2019-08-1322-218/+189
| | | | | | | | | | | | | std::shared_pointer<PathDiagnosticPiece> -> PathDiagnosticPieceRef find clang/ -type f -exec sed -i 's/std::shared_ptr<PathDiagnosticPiece>/PathDiagnosticPieceRef/g' {} \; git diff -U3 --no-color HEAD^ | clang-format-diff-6.0 -p1 -i Just as C++ is meant to be refactored, right? Differential Revision: https://reviews.llvm.org/D65381 llvm-svn: 368717
* Fix crash on switch conditions of non-integer types in templatesElizabeth Andrews2019-08-132-0/+11
| | | | | | | | | | | | | | | | | | | Clang currently crashes for switch statements inside a template when the condition is a non-integer field. The crash is due to incorrect type-dependency of field. Type-dependency of member expressions is currently set based on the containing class. This patch changes this for 'members of the current instantiation' to set the type dependency based on the member's type instead. A few lit tests started to fail once I applied this patch because errors are now diagnosed earlier (does not wait till instantiation). I've modified these tests in this patch as well. Patch fixes PR#40982 Differential Revision: https://reviews.llvm.org/D61027 llvm-svn: 368706
* Enable memtag sanitizer in all AArch64 toolchainsMomchil Velikov2019-08-132-2/+3
| | | | | | | | That sanitizer does not have runtime library or other dependencies. Differential Revision: https://reviews.llvm.org/D65642 llvm-svn: 368697
* [AArch64] Make the memtag sanitizer require the memtag extensionMomchil Velikov2019-08-131-0/+15
| | | | | | | | ... or otherwise we get an ICE. Differential Revision: https://reviews.llvm.org/D65508 llvm-svn: 368696
* [analyzer][NFC] Refactoring BugReporter.cpp P2.: Clean up the construction ↵Kristof Umann2019-08-131-96/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of bug paths and finding a valid report This patch refactors the utility functions and classes around the construction of a bug path. At a very high level, this consists of 3 steps: * For all BugReports in the same BugReportEquivClass, collect all their error nodes in a set. With that set, create a new, trimmed ExplodedGraph whose leafs are all error nodes. * Until a valid report is found, construct a bug path, which is yet another ExplodedGraph, that is linear from a given error node to the root of the graph. * Run all visitors on the constructed bug path. If in this process the report got invalidated, start over from step 2. Now, to the changes within this patch: * Do not allow the invalidation of BugReports up to the point where the trimmed graph is constructed. Checkers shouldn't add bug reports that are known to be invalid, and should use visitors and argue about the entirety of the bug path if needed. * Do not calculate indices. I may be biased, but I personally find code like this horrible. I'd like to point you to one of the comments in the original code: SmallVector<const ExplodedNode *, 32> errorNodes; for (const auto I : bugReports) { if (I->isValid()) { HasValid = true; errorNodes.push_back(I->getErrorNode()); } else { // Keep the errorNodes list in sync with the bugReports list. errorNodes.push_back(nullptr); } } Not on my watch. Instead, use a far easier to follow trick: store a pointer to the BugReport in question, not an index to it. * Add range iterators to ExplodedGraph's successors and predecessors, and a visitor range to BugReporter. * Rename TrimmedGraph to BugPathGetter. Because that is what it has always been: no sane graph type should store an iterator-like state, or have an interface not exposing a single graph-like functionalities. * Rename ReportGraph to BugPathInfo, because it is only a linear path with some other context. * Instead of having both and out and in parameter (which I think isn't ever excusable unless we use the out-param for caching), return a record object with descriptive getter methods. * Where descriptive names weren't sufficient, compliment the code with comments. Differential Revision: https://reviews.llvm.org/D65379 llvm-svn: 368694
* [analyzer][NFC] Refactoring BugReporter.cpp P1.: Store interesting ↵Kristof Umann2019-08-131-46/+7
| | | | | | | | | | | | | | | | | | | | | | | | symbols/regions in a simple set The goal of this refactoring effort was to better understand how interestingness was propagated in BugReporter.cpp, which eventually turned out to be a dead end, but with such a twist, I wouldn't even want to spoil it ahead of time. However, I did get to learn a lot about how things are working in there. In these series of patches, as well as cleaning up the code big time, I invite you to study how BugReporter.cpp operates, and discuss how we could design this file to reduce the horrible mess that it is. This patch reverts a great part of rC162028, which holds the title "Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.". This, however doesn't imply that there's any need for multiple "layers" or stacks of interesting symbols and regions, quite the contrary, I would argue that we would like to generate the same amount of information for all output types, and only process them differently. Differential Revision: https://reviews.llvm.org/D65378 llvm-svn: 368689
* [libTooling] In Transformer, generalize `applyFirst` to admit rules with ↵Yitzhak Mandelbaum2019-08-131-60/+47
| | | | | | | | | | | | | | | | | | | | | incompatible matchers. Summary: This patch removes an (artificial) limitation of `applyFirst`, which requires that all of the rules' matchers can be grouped together in a single `anyOf()`. This change generalizes the code to group the matchers into separate `anyOf`s based on compatibility. Correspondingly, `buildMatcher` is changed to `buildMatchers`, to allow for returning a set of matchers rather than just one. Reviewers: gribozavr Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65877 llvm-svn: 368681
* [CodeGen] Disable UBSan for coroutine functionsBrian Gesiak2019-08-131-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As explained in http://lists.llvm.org/pipermail/llvm-dev/2018-March/121924.html, the LLVM coroutines transforms are not yet able to move the instructions for UBSan null checking past coroutine suspend boundaries. For now, disable all UBSan checks when generating code for coroutines functions. I also considered an approach where only '-fsanitize=null' would be disabled, However in practice this led to other LLVM errors when writing object files: "Cannot represent a difference across sections". For now, disable all UBSan checks until coroutine transforms are updated to handle them. Test Plan: 1. check-clang 2. Compile the program in https://gist.github.com/modocache/54a036c3bf9c06882fe85122e105d153 using the '-fsanitize=null' option and confirm it does not crash during LLVM IR generation. Reviewers: GorNishanov, vsk, eric_niebler, lewissbaker Reviewed By: vsk Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D44672 llvm-svn: 368675
* [ASTImporter] Import additional flags for functions.Balazs Keri2019-08-131-0/+3
| | | | | | | | | | | | | | | | | | Summary: At AST import of function delcarations import the flags for defaulted and deleted. Reviewers: martong, a.sidorin, shafik, a_sidorin Reviewed By: a_sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65999 llvm-svn: 368655
OpenPOWER on IntegriCloud