summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] Add minimal support for fix-it hints.Artem Dergachev2019-09-062-9/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | Allow attaching fixit hints to Static Analyzer BugReports. Fixits are attached either to the bug report itself or to its notes (path-sensitive event notes or path-insensitive extra notes). Add support for fixits in text output (including the default text output that goes without notes, as long as the fixit "belongs" to the warning). Add support for fixits in the plist output mode. Implement a fixit for the path-insensitive DeadStores checker. Only dead initialization warning is currently covered. Implement a fixit for the path-sensitive VirtualCall checker when the virtual method is not pure virtual (in this case the "fix" is to suppress the warning by qualifying the call). Both fixits are under an off-by-default flag for now, because they require more careful testing. Differential Revision: https://reviews.llvm.org/D65182 llvm-svn: 371257
* [analyzer] pr43179: Make CallDescription defensive against C variadic functions.Artem Dergachev2019-09-061-2/+4
| | | | | | | | | | | | | | | | | | | | | Most functions that our checkers react upon are not C-style variadic functions, and therefore they have as many actual arguments as they have formal parameters. However, it's not impossible to define a variadic function with the same name. This will crash any checker that relies on CallDescription to check the number of arguments but silently assumes that the number of parameters is the same. Change CallDescription to check both the number of arguments and the number of parameters by default. If we're intentionally trying to match variadic functions, allow specifying arguments and parameters separately (possibly omitting any of them). For now we only have one CallDescription which would make use of those, namely __builtin_va_start itself. Differential Revision: https://reviews.llvm.org/D67019 llvm-svn: 371256
* [analyzer] Fix analyzer warnings on analyzer.Artem Dergachev2019-08-285-10/+8
| | | | | | | | | Write tests for the actual crash that was found. Write comments and refactor code around 17 style bugs and suppress 3 false positives. Differential Revision: https://reviews.llvm.org/D66847 llvm-svn: 370246
* [analyzer] pr43036: Fix support for operator 'sizeof...'.Artem Dergachev2019-08-281-0/+1
| | | | | | | | | It was known to be a compile-time constant so it wasn't evaluated during symbolic execution, but it wasn't evaluated as a compile-time constant either. Differential Revision: https://reviews.llvm.org/D66565 llvm-svn: 370245
* [analyzer] Trust global initializers when analyzing main().Artem Dergachev2019-08-281-16/+58
| | | | | | | | | | | | | | | | | If the global variable has an initializer, we'll ignore it because we're usually not analyzing the program from the beginning, which means that the global variable may have changed before we start our analysis. However when we're analyzing main() as the top-level function, we can rely on global initializers to still be valid. At least in C; in C++ we have global constructors that can still break this logic. This patch allows the Static Analyzer to load constant initializers from global variables if the top-level function of the current analysis is main(). Differential Revision: https://reviews.llvm.org/D65361 llvm-svn: 370244
* Update the SARIF exporter to SARIF 2.1Joe Ranieri2019-08-271-43/+42
| | | | | | | | | | This updates the SARIF exporter to produce SARIF 2.1 output. The bulk of the diffs come from two changes to SARIF: * https://github.com/oasis-tcs/sarif-spec/issues/309 * https://github.com/oasis-tcs/sarif-spec/issues/179 Differential Revision: https://reviews.llvm.org/D65211 llvm-svn: 370068
* Fix a SARIF exporter crash with macro expansionsJoe Ranieri2019-08-271-4/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D65209 llvm-svn: 370061
* Fix text range end columns in SARIF to be exclusiveJoe Ranieri2019-08-271-3/+9
| | | | | | | | According to the SARIF specification, "a text region does not include the character specified by endColumn". Differential Revision: https://reviews.llvm.org/D65206 llvm-svn: 370060
* Do a sweep of symbol internalization. NFC.Benjamin Kramer2019-08-231-4/+5
| | | | llvm-svn: 369803
* [analyzer] CastValueChecker: Provide DynamicTypeMap with pointer types only.Artem Dergachev2019-08-231-3/+6
| | | | | | | | | The idea to drop this requirement is good, but for now every other user of DynamicTypeInfo expects pointer types. Fixes a crash. llvm-svn: 369728
* [analyzer] DynamicTypeInfo: Avoid putting null regions into dynamic typemap.Artem Dergachev2019-08-231-0/+3
| | | | | | Fixes a crash. llvm-svn: 369726
* [analyzer] Don't track the condition of foreach loopsKristof Umann2019-08-221-0/+5
| | | | | | | | | As discussed on the mailing list, notes originating from the tracking of foreach loop conditions are always meaningless. Differential Revision: https://reviews.llvm.org/D66131 llvm-svn: 369613
* [analyzer] CastValueChecker: Rewrite dead header hotfixCsaba Dabis2019-08-221-1/+1
| | | | llvm-svn: 369607
* [analyzer] CastValueChecker: Store the dynamic types and castsCsaba Dabis2019-08-224-99/+225
| | | | | | | | | | | | | | Summary: This patch introduces `DynamicCastInfo` similar to `DynamicTypeInfo` which is stored in `CastSets` which are storing the dynamic cast informations of objects based on memory regions. It could be used to store and check the casts and prevent infeasible paths. Reviewed By: NoQ Differential Revision: https://reviews.llvm.org/D66325 llvm-svn: 369605
* [analyzer] TrackConstraintBRVisitor: Do not track unknown valuesCsaba Dabis2019-08-221-3/+4
| | | | | | | | | | | | Summary: - Reviewers: NoQ, Szelethus Reviewed By: NoQ, Szelethus Differential Revision: https://reviews.llvm.org/D66267 llvm-svn: 369604
* [analyzer] Mention whether an event is about a condition in a bug report part 2Kristof Umann2019-08-211-0/+30
| | | | | | | | | In D65724, I do a pretty thorough explanation about how I'm solving this problem, I think that summary nails whats happening here ;) Differential Revision: https://reviews.llvm.org/D65725 llvm-svn: 369596
* [analyzer] Don't make ConditionBRVisitor events prunable when the condition ↵Kristof Umann2019-08-211-34/+46
| | | | | | | | | | | is an interesting field Exactly what it says on the tin! Note that we're talking about interestingness in general, hence this isn't a control-dependency-tracking specific patch. Differential Revision: https://reviews.llvm.org/D65724 llvm-svn: 369589
* [analyzer][NFC] Add different interestingness kindsKristof Umann2019-08-212-23/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We defined (on the mailing list and here on phabricator) 2 different cases where retrieving information about a control dependency condition is very important: * When the condition's last write happened in a different stack frame * When the collapse point of the condition (when we can constrain it to be true/false) didn't happen in the actual condition. It seems like we solved this problem with the help of expression value tracking, and have started working on better diagnostics notes about this process. Expression value tracking is nothing more than registering a variety of visitors to construct reports about it. Each of the registered visitors (ReturnVisitor, FindLastStoreVisitor, NoStoreFuncVisitor, etc) have something to go by: a MemRegion, an SVal, an ExplodedNode, etc. For this reason, better explaining a last write is super simple, we can always just pass on some more information to the visitor in question (as seen in D65575). ConditionBRVisitor is a different beast, as it was built for a different purpose. It is responsible for constructing events at, well, conditions, and is registered only once, and isn't a part of the "expression value tracking family". Unfortunately, it is also the visitor to tinker with for constructing better diagnostics about the collapse point problem. This creates a need for alternative way to communicate with ConditionBRVisitor that a specific condition is being tracked for for the reason of being a control dependency. Since at almost all PathDiagnosticEventPiece construction the visitor checks interestingness, it makes sense to pair interestingness with a reason as to why we marked an entity as such. Differential Revision: https://reviews.llvm.org/D65723 llvm-svn: 369583
* [analyzer] Mention whether an event is about a condition in a bug report part 1Kristof Umann2019-08-211-3/+15
| | | | | | | | | | Can't add much more to the title! This is part 1, the case where the collapse point isn't in the condition point is the responsibility of ConditionBRVisitor, which I'm addressing in part 2. Differential Revision: https://reviews.llvm.org/D65575 llvm-svn: 369574
* Removed some dead code in BugReporter and related filesDmitri Gribenko2019-08-214-68/+5
| | | | | | | | | | Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66473 llvm-svn: 369504
* [analyzer] NFC: Remove the BugTypes set from BugReporter.Artem Dergachev2019-08-201-13/+3
| | | | | | | Its only purpose was to avoid a bug that's caused by making a virtual call in BugReporter's destructor. llvm-svn: 369451
* [analyzer] Fix a crash when destroying a non-region.Artem Dergachev2019-08-202-15/+31
| | | | | | | | | Add defensive check that prevents a crash when we try to evaluate a destructor whose this-value is a concrete integer that isn't a null. Differential Revision: https://reviews.llvm.org/D65349 llvm-svn: 369450
* [analyzer] Improve VirtualCallChecker and enable parts of it by default.Artem Dergachev2019-08-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calling a pure virtual method during construction or destruction is undefined behavior. It's worth it to warn about it by default. That part is now known as the cplusplus.PureVirtualCall checker. Calling a normal virtual method during construction or destruction may be fine, but does behave unexpectedly, as it skips virtual dispatch. Do not warn about this by default, but let projects opt in into it by enabling the optin.cplusplus.VirtualCall checker manually. Give the two parts differentiated warning text: Before: Call to virtual function during construction or destruction: Call to pure virtual function during construction Call to virtual function during construction or destruction: Call to virtual function during destruction After: Pure virtual method call: Call to pure virtual method 'X::foo' during construction has undefined behavior Unexpected loss of virtual dispatch: Call to virtual method 'Y::bar' during construction bypasses virtual dispatch Also fix checker names in consumers that support them (eg., clang-tidy) because we now have different checker names for pure virtual calls and regular virtual calls. Also fix capitalization in the bug category. Differential Revision: https://reviews.llvm.org/D64274 llvm-svn: 369449
* [analyzer] NFC: Rename GRBugReporter to PathSensitiveBugReporter.Artem Dergachev2019-08-201-8/+13
| | | | | | The GR prefix is super ancient. llvm-svn: 369320
* [analyzer] NFC: Drop support for extra text attached to bug reports.Artem Dergachev2019-08-201-5/+0
| | | | | | It was introduced in 2011 but never used since then. llvm-svn: 369319
* [analyzer] Turn an assert into an if conditionKristof Umann2019-08-171-4/+3
| | | | | | | Shocker, turns out that terminator conditions that are binary operators aren't always logical operators. llvm-svn: 369195
* [analyzer] Analysis: Silence checkersCsaba Dabis2019-08-162-27/+18
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch introduces a new `analyzer-config` configuration: `-analyzer-config silence-checkers` which could be used to silence the given checkers. It accepts a semicolon separated list, packed into quotation marks, e.g: `-analyzer-config silence-checkers="core.DivideZero;core.NullDereference"` It could be used to "disable" core checkers, so they model the analysis as before, just if some of them are too noisy it prevents to emit reports. This patch also adds support for that new option to the scan-build. Passing the option `-disable-checker core.DivideZero` to the scan-build will be transferred to `-analyzer-config silence-checkers=core.DivideZero`. Reviewed By: NoQ, Szelethus Differential Revision: https://reviews.llvm.org/D66042 llvm-svn: 369078
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-146-37/+37
| | | | | | | | | | 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
* [analyzer][CFG] Don't track the condition of assertsKristof Umann2019-08-143-100/+57
| | | | | | | | | | | | | | 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
* [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
* [analyzer][NFC] Prepare visitors for different tracking kindsKristof Umann2019-08-141-59/+64
| | | | | | | | | | | | | | | | | | | | | | | 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
* [analyzer][NFC] Make sure that the BugReport is not modified during the ↵Kristof Umann2019-08-132-10/+13
| | | | | | | | | | | | 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
* [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
* [analyzer][NFC] Address inlines of D65484Kristof Umann2019-08-131-37/+38
| | | | llvm-svn: 368745
* [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-134-75/+77
| | | | | | | | | | | | | | 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
* [analyzer][NFC] Refactoring BugReporter.cpp P3.: ↵Kristof Umann2019-08-134-98/+85
| | | | | | | | | | | | | 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
* [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
* [analyzer] ConditionBRVisitor: Fix HTML PathDiagnosticPopUpPiecesCsaba Dabis2019-08-092-19/+41
| | | | | | | | | | | | | | | | Summary: A condition could be a multi-line expression where we create the highlight in separated chunks. PathDiagnosticPopUpPiece is not made for that purpose, it cannot be added to multiple lines because we have only one ending part which contains all the notes. So that it cannot have multiple endings and therefore this patch narrows down the ranges of the highlight to the given interesting variable of the condition. It prevents HTML-breaking injections. Reviewed By: NoQ Differential Revision: https://reviews.llvm.org/D65663 llvm-svn: 368382
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-052-2/+2
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* [analyzer] StackFrameContext: Add NodeBuilderContext::blockCount() to its ↵Csaba Dabis2019-08-013-10/+12
| | | | | | | | | | | | | | | | | | profile Summary: It allows discriminating between stack frames of the same call that is called multiple times in a loop. Thanks to Artem Dergachev for the great idea! Reviewed By: NoQ Tags: #clang Differential Revision: https://reviews.llvm.org/D65587 llvm-svn: 367608
* [CrossTU] Fix plist macro expansion if macro in other file.Balazs Keri2019-07-252-17/+28
| | | | | | | | | | | | | | | | | | | | | Summary: When cross TU analysis is used it is possible that a macro expansion is generated for a macro that is defined (and used) in other than the main translation unit. To get the expansion for it the source location in the original source file and original preprocessor is needed. Reviewers: martong, xazax.hun, Szelethus, ilya-biryukov Reviewed By: Szelethus Subscribers: mgorny, NoQ, ilya-biryukov, rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64638 llvm-svn: 367006
* PlistDiagnostics Fix for compile warning (NFC).Balazs Keri2019-07-231-1/+1
| | | | llvm-svn: 366792
* [CrossTU] Added CTU argument to diagnostic consumer create fn.Balazs Keri2019-07-233-32/+37
| | | | | | | | | | | | | | | | | | Summary: The PListDiagnosticConsumer needs a new CTU parameter that is passed through the create functions. Reviewers: NoQ, Szelethus, xazax.hun, martong Reviewed By: Szelethus Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64635 llvm-svn: 366782
* [analyzer] Fix -Wunused-function in NDEBUG builds with #ifdef LLVM_DUMP_METHODFangrui Song2019-07-221-2/+4
| | | | llvm-svn: 366663
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-167-12/+12
| | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud