summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer] NFC: Move PathDiagnostic classes to libAnalysis.Artem Dergachev2019-09-1115-1229/+13
| | | | | | | | | | | | At this point the PathDiagnostic, PathDiagnosticLocation, PathDiagnosticPiece structures no longer rely on anything specific to Static Analyzer, so we can move them out of it for everybody to use. PathDiagnosticConsumers are still to be handed off. Differential Revision: https://reviews.llvm.org/D67419 llvm-svn: 371661
* [analyzer] NFC: Move resetDiagnosticLocationToMainFile() to BugReporter.Artem Dergachev2019-09-112-65/+66
| | | | | | | | | | This method of PathDiagnostic is a part of Static Analyzer's particular path diagnostic construction scheme. As such, it doesn't belong to the PathDiagnostic class, but to the Analyzer. Differential Revision: https://reviews.llvm.org/D67418 llvm-svn: 371660
* [analyzer] NFC: Move getStmt() and createEndOfPath() out of PathDiagnostic.Artem Dergachev2019-09-1117-178/+172
| | | | | | | | | | These static functions deal with ExplodedNodes which is something we don't want the PathDiagnostic interface to know anything about, as it's planned to be moved out of libStaticAnalyzerCore. Differential Revision: https://reviews.llvm.org/D67382 llvm-svn: 371659
* [analyzer] NFC: Re-implement stack hints as a side map in BugReport.Artem Dergachev2019-09-118-110/+104
| | | | | | | | | | That's one of the few random entities in the PathDiagnostic interface that are specific to the Static Analyzer. By moving them out we could let everybody use path diagnostics without linking against Static Analyzer. Differential Revision: https://reviews.llvm.org/D67381 llvm-svn: 371658
* [analyzer] NFC: Simplify bug report equivalence classes to not be ilists.Artem Dergachev2019-09-092-12/+11
| | | | | | | | Use a vector of unique pointers instead. Differential Revision: https://reviews.llvm.org/D67024 llvm-svn: 371451
* [analyzer] NFC: Introduce sub-classes for path-sensitive and basic reports.Artem Dergachev2019-09-0971-393/+493
| | | | | | | | | | | | | Checkers are now required to specify whether they're creating a path-sensitive report or a path-insensitive report by constructing an object of the respective type. This makes BugReporter more independent from the rest of the Static Analyzer because all Analyzer-specific code is now in sub-classes. Differential Revision: https://reviews.llvm.org/D66572 llvm-svn: 371450
* Move prop-sink branch to monorepo.Gabor Borsik2019-09-081-29/+65
| | | | llvm-svn: 371342
* [analyzer] Add minimal support for fix-it hints.Artem Dergachev2019-09-065-61/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-062-3/+7
| | | | | | | | | | | | | | | | | | | | | 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
* Unbreak the build after r370798Benjamin Kramer2019-09-031-1/+1
| | | | llvm-svn: 370807
* [analyzer] NonNullParamChecker and CStringChecker parameter number in ↵Kristof Umann2019-09-032-24/+35
| | | | | | | | | | | | | | | | | | | | checker message There are some functions which can't be given a null pointer as parameter either because it has a nonnull attribute or it is declared to have undefined behavior (e.g. strcmp()). Sometimes it is hard to determine from the checker message which parameter is null at the invocation, so now this information is included in the message. This commit fixes https://bugs.llvm.org/show_bug.cgi?id=39358 Reviewed By: NoQ, Szelethus, whisperity Patch by Tibor Brunner! Differential Revision: https://reviews.llvm.org/D66333 llvm-svn: 370798
* [analyzer] Add a checker option to detect nested dead storesKristof Umann2019-09-031-9/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enables the users to specify an optional flag which would warn for more dead stores. Previously it ignored if the dead store happened e.g. in an if condition. if ((X = generate())) { // dead store to X } This patch introduces the `WarnForDeadNestedAssignments` option to the checker, which is `false` by default - so this change would not affect any previous users. I have updated the code, tests and the docs as well. If I missed something, tell me. I also ran the analysis on Clang which generated 14 more reports compared to the unmodified version. All of them seemed reasonable for me. Related previous patches: rGf224820b45c6847b91071da8d7ade59f373b96f3 Reviewers: NoQ, krememek, Szelethus, baloghadamsoftware Reviewed By: Szelethus Patch by Balázs Benics! Differential Revision: https://reviews.llvm.org/D66733 llvm-svn: 370767
* [Analyzer] Iterator Checkers - Make range errors and invalidated access fatalAdam Balogh2019-08-291-8/+6
| | | | | | | | | | | | | | Range errors (dereferencing or incrementing the past-the-end iterator or decrementing the iterator of the first element of the range) and access of invalidated iterators lead to undefined behavior. There is no point to continue the analysis after such an error on the same execution path, but terminate it by a sink node (fatal error). This also improves the performance and helps avoiding double reports (e.g. in case of nested iterators). Differential Revision: https://reviews.llvm.org/D62893 llvm-svn: 370314
* [analyzer] Fix analyzer warnings on analyzer.Artem Dergachev2019-08-2817-61/+77
| | | | | | | | | 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] Avoid unnecessary enum range check on LValueToRValue castsKristof Umann2019-08-231-0/+16
| | | | | | | | | | | | | | | | Summary: EnumCastOutOfRangeChecker should not perform enum range checks on LValueToRValue casts, since this type of cast does not actually change the underlying type. Performing the unnecessary check actually triggered an assertion failure deeper in EnumCastOutOfRange for certain input (which is captured in the accompanying test code). Reviewers: #clang, Szelethus, gamesh411, NoQ Reviewed By: Szelethus, gamesh411, NoQ Subscribers: NoQ, gamesh411, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, Charusso, bjope, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66014 llvm-svn: 369760
* [analyzer] CastValueChecker: Correctly model results of based-to-derived casts.Artem Dergachev2019-08-231-9/+27
| | | | | | | | | | Our SVal hierarchy doesn't allow modeling pointer casts as no-op. The pointer type is instead encoded into the pointer object. Defer to our usual pointer casting facility, SValBuilder::evalBinOp(). Fixes a crash. llvm-svn: 369729
* [analyzer] CastValueChecker: Provide DynamicTypeMap with pointer types only.Artem Dergachev2019-08-232-28/+26
| | | | | | | | | 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] CastValueChecker: Avoid modeling casts between objects.Artem Dergachev2019-08-231-2/+7
| | | | | | | | | Our method only works correctly when casting a pointer to a pointer or a reference to a reference. Fixes a crash. llvm-svn: 369727
* [analyzer] DynamicTypeInfo: Avoid putting null regions into dynamic typemap.Artem Dergachev2019-08-231-0/+3
| | | | | | Fixes a crash. llvm-svn: 369726
* Remove an unused function, suppress -Wunused-function warning.Haojian Wu2019-08-221-6/+0
| | | | llvm-svn: 369629
* [analyzer] CastValueChecker: Model isa(), isa_and_nonnull()Csaba Dabis2019-08-221-5/+100
| | | | | | | | | | Summary: - Reviewed By: NoQ Differential Revision: https://reviews.llvm.org/D66423 llvm-svn: 369615
* [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: Try to fix the buildbotsCsaba Dabis2019-08-221-1/+1
| | | | llvm-svn: 369609
* [analyzer] CastValueChecker: Rewrite dead header hotfixCsaba Dabis2019-08-226-6/+6
| | | | llvm-svn: 369607
* [analyzer] CastValueChecker: Store the dynamic types and castsCsaba Dabis2019-08-226-211/+404
| | | | | | | | | | | | | | 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-215-71/+8
| | | | | | | | | | 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-202-13/+7
| | | | | | | 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-202-125/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-163-36/+31
| | | | | | | | | | | | | | | | | | | | | | | 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
* [analyzer] Warn about -analyzer-configs being meant for development purposes ↵Kristof Umann2019-08-151-5/+16
| | | | | | | | | | | | only This is more of a temporary fix, long term, we should convert AnalyzerOptions.def into the universally beloved (*coughs*) TableGen format, where they can more easily be separated into developer-only, alpha, and user-facing configs. Differential Revision: https://reviews.llvm.org/D66261 llvm-svn: 368980
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-1472-195/+195
| | | | | | | | | | 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] 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
OpenPOWER on IntegriCloud