summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] Add scope information to CFGMaxim Ostapenko2018-03-124-0/+12
| | | | | | | | | | | This patch adds two new CFG elements CFGScopeBegin and CFGScopeEnd that indicate when a local scope begins and ends respectively. We use first VarDecl declared in a scope to uniquely identify it and add CFGScopeBegin and CFGScopeEnd elements into corresponding basic blocks. Differential Revision: https://reviews.llvm.org/D16403 llvm-svn: 327258
* [StaticAnalyzer] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2018-03-082-188/+200
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 327074
* [analyzer] Correctly model iteration through "nil" objectsGeorge Karpenkov2018-03-081-39/+55
| | | | | | | | | | | | | | | | | | | | Previously, iteration through nil objects which resulted from objc-messages being set to nil were modeled incorrectly. There are a couple of notes about this patch: In principle, ExprEngineObjC might be left untouched IFF osx.loops checker is enabled. I however think that we should not do something completely incorrect depending on what checkers are left on. We should evaluate and potentially remove altogether the isConsumedExpr performance heuristic, as it seems very fragile. rdar://22205149 Differential Revision: https://reviews.llvm.org/D44178 llvm-svn: 326982
* Fix an unused variable warning; NFCGeorge Burgess IV2018-03-081-1/+1
| | | | llvm-svn: 326980
* [analyzer] Don't crash with assertion failure on structured bindingsGeorge Karpenkov2018-03-071-1/+6
| | | | | | | | | | | | Proper modeling still remains to be done. Note that BindingDecl#getHoldingVar() is almost always null, and this should probably be handled by dealing with DecompositionDecl beforehand. rdar://36852163 Differential Revision: https://reviews.llvm.org/D44183 llvm-svn: 326951
* [StaticAnalyzer] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2018-03-072-188/+190
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 326856
* [Analyzer] More accurate modeling about the increment operator of the ↵Henry Wong2018-03-061-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | operand with type bool. Summary: There is a problem with analyzer that a wrong value is given when modeling the increment operator of the operand with type bool. After `rL307604` is applied, a unsigned overflow may occur. Example: ``` void func() { bool b = true; // unsigned overflow occur, 2 -> 0 U1b b++; } ``` The use of an operand of type bool with the ++ operators is deprecated but valid untill C++17. And if the operand of the increment operator is of type bool, it is set to true. This patch includes two parts: - If the operand of the increment operator is of type bool or type _Bool, set to true. - Modify `BasicValueFactory::getTruthValue()`, use `getIntWidth()` instead `getTypeSize()` and use `unsigned` instead `signed`. Reviewers: alexshap, NoQ, dcoughlin, george.karpenkov Reviewed By: NoQ Subscribers: xazax.hun, szepet, a.sidorin, cfe-commits, MTC Differential Revision: https://reviews.llvm.org/D43741 llvm-svn: 326776
* [StaticAnalyzer] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2018-03-063-53/+84
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 326757
* [StaticAnalyzer] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2018-03-023-136/+149
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 326633
* [analyzer] Prevent crashing in NonNullParamCheckerGeorge Karpenkov2018-03-021-0/+2
| | | | | | | | | | | | | https://bugs.llvm.org/show_bug.cgi?id=36381 rdar://37543426 Turns out, the type passed for the lambda capture was incorrect. One more argument to abandon the getSVal overload which does not require the type information. Differential Revision: https://reviews.llvm.org/D43925 llvm-svn: 326520
* [StaticAnalyzer] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2018-03-021-203/+202
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 326519
* [analyzer] Enable cfg-temporary-dtors by default.Artem Dergachev2018-03-011-2/+2
| | | | | | | | | | | | Don't enable c++-temp-dtor-inlining by default yet, due to this reference counting pointe problem. Otherwise the new mode seems stable and allows us to incrementally fix C++ problems in much less hacky ways. Differential Revision: https://reviews.llvm.org/D43804 llvm-svn: 326461
* Resubmit [analyzer] Support for naive cross translation unit analysisIlya Biryukov2018-03-015-6/+67
| | | | | | | | | | | Originally submitted as r326323 and r326324. Reverted in r326432. Reverting the commit was a mistake. The breakage was due to invalid build files in our internal buildsystem, CMakeLists did not have any cyclic dependencies. llvm-svn: 326439
* Revert "[analyzer] Support for naive cross translation unit analysis"Ilya Biryukov2018-03-015-67/+6
| | | | | | | | | | Also revert "[analyzer] Fix a compiler warning" This reverts commits r326323 and r326324. Reason: the commits introduced a cyclic dependency in the build graph. This happens to work with cmake, but breaks out internal integrate. llvm-svn: 326432
* Remove redundant casts. NFCGeorge Burgess IV2018-03-014-7/+7
| | | | | | | | | | | | | | | | | | | So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and `dyn_cast`s for fun. This is a portion of what it found for clang; I plan to do similar cleanups in LLVM and other subprojects when I find time. Because of the volume of changes, I explicitly avoided making any change that wasn't highly local and obviously correct to me (e.g. we still have a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading is a thing and the cast<Bar> did actually change the type -- just up the class hierarchy). I also tried to leave the types we were cast<>ing to somewhere nearby, in cases where it wasn't locally obvious what we were dealing with before. llvm-svn: 326416
* [analyzer] Support for naive cross translation unit analysisGabor Horvath2018-02-285-6/+67
| | | | | | | | | | | | | | | | | | The aim of this patch is to be minimal to enable incremental development of the feature on the top of the tree. This patch should be an NFC when the feature is turned off. It is turned off by default and still considered as experimental. Technical details are available in the EuroLLVM Talk: http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#7 Note that the initial prototype was done by A. Sidorin et al.: http://lists.llvm.org/pipermail/cfe-dev/2015-October/045730.html Contributions to the measurements and the new version of the code: Peter Szecsi, Zoltan Gera, Daniel Krupp, Kareem Khazem. Differential Revision: https://reviews.llvm.org/D30691 llvm-svn: 326323
* [StaticAnalyzer] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2018-02-285-83/+132
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 326292
* [analyzer] Fix trivial copy for empty objects.Artem Dergachev2018-02-271-0/+11
| | | | | | | | | | | | | | The SVal for any empty C++ object is an UnknownVal. Because RegionStore does not have binding extents, binding an empty object to an UnknownVal may potentially overwrite existing bindings at the same offset. Therefore, when performing a trivial copy of an empty object, don't try to take the value of the object and bind it to the copy. Doing nothing is accurate enough, and it doesn't screw any existing bindings. Differential Revision: https://reviews.llvm.org/D43714 llvm-svn: 326247
* [analyzer] Track temporaries without construction contexts for destruction.Artem Dergachev2018-02-271-11/+44
| | | | | | | | | | | | | | | | | | | | | | Sometimes it is not known at compile time which temporary objects will be constructed, eg. 'x ? A() : B()' or 'C() || D()'. In this case we track which temporary was constructed to know how to properly call the destructor. Once the construction context for temporaries was introduced, we moved the tracking code to the code that investigates the construction context. Bring back the old mechanism because construction contexts are not always available yet - eg. in the case where a temporary is constructed without a constructor expression, eg. returned from a function by value. The mechanism should still go away eventually. Additionally, fix a bug in the temporary cleanup code for the case when construction contexts are not available, which could lead to temporaries staying in the program state and increasing memory consumption. Differential Revision: https://reviews.llvm.org/D43666 llvm-svn: 326246
* [analyzer] Don't crash when dynamic type of a variable is set via placement new.Artem Dergachev2018-02-271-1/+9
| | | | | | | | | | | | | | | | | | | If a variable or an otherwise a concrete typed-value region is being placement-new'ed into, its dynamic type may change in arbitrary manners. And when the region is used, there may be a third type that's different from both the static and the dynamic type. It cannot be *completely* different from the dynamic type, but it may be a base class of the dynamic type - and in this case there isn't (and shouldn't be) any indication anywhere in the AST that there is a derived-to-base cast from the dynamic type to the third type. Perform a generic cast (evalCast()) from the third type to the dynamic type in this case. From the point of view of the SVal hierarchy, this would have produced non-canonical SVals if we used such generic cast in the normal case, but in this case there doesn't seem to be a better option. Differential Revision: https://reviews.llvm.org/D43659 llvm-svn: 326245
* [analyzer] Disable constructor inlining when lifetime extending through a field.Artem Dergachev2018-02-272-0/+17
| | | | | | | | | | | | | Automatic destructors are missing in the CFG in situations like const int &x = C().x; For now it's better to disable construction inlining, because inlining constructors while doing nothing on destructors is very bad. Differential Revision: https://reviews.llvm.org/D43689 llvm-svn: 326240
* [analyzer] Self-debug: Dump dynamic type info and taint with the program state.Artem Dergachev2018-02-272-1/+31
| | | | | | | | Useful for debugging problems with dynamic type info and taint. Differential Revision: https://reviews.llvm.org/D43657 llvm-svn: 326239
* [CFG] NFC: Refactor ConstructionContext into a finite set of cases.Artem Dergachev2018-02-272-57/+81
| | | | | | | | | | | | | | | | | | | | | ConstructionContext is moved into a separate translation unit and is separated into multiple classes. The "old" "raw" ConstructionContext is renamed into ConstructionContextLayer - which corresponds to the idea of building the context gradually layer-by-layer, but it isn't easy to use in the clients. Once CXXConstructExpr is reached, layers that we've gathered so far are transformed into the actual, "new-style" "flat" ConstructionContext, which is put into the CFGConstructor element and has no layers whatsoever (until it actually needs them, eg. aggregate initialization). The new-style ConstructionContext is instead presented as a variety of sub-classes that enumerate different ways of constructing an object in C++. There are 5 of these supported for now, which is around a half of what needs to be supported. The layer-by-layer buildup process is still a little bit weird, but it hides all the weirdness in one place, that sounds like a good thing. Differential Revision: https://reviews.llvm.org/D43533 llvm-svn: 326238
* [analyzer] Introduce correct lifetime extension behavior in simple cases.Artem Dergachev2018-02-272-41/+143
| | | | | | | | | | | | | | | | | | | | | | | | This patch uses the reference to MaterializeTemporaryExpr stored in the construction context since r326014 in order to model that expression correctly. When modeling MaterializeTemporaryExpr, instead of copying the raw memory contents from the sub-expression's rvalue to a completely new temporary region, that we conjure up for the lack of better options, we now have the better option to recall the region into which the object was originally constructed and declare that region to be the value of the expression, which is semantically correct. This only works when the construction context is available, which is worked on independently. The temporary region's liveness (in the sense of removeDeadBindings) is extended until the MaterializeTemporaryExpr is resolved, in order to keep the store bindings around, because it wouldn't be referenced from anywhere else in the program state. Differential Revision: https://reviews.llvm.org/D43497 llvm-svn: 326236
* [analyzer] Remove redundant checkGeorge Karpenkov2018-02-271-2/+0
| | | | | | | | There is no point in assigning void just to crash on it in the next line Differential Revision: https://reviews.llvm.org/D43802 llvm-svn: 326234
* [analyzer] Quickfix: don't crash when runtime definition is not available.George Karpenkov2018-02-271-3/+5
| | | | llvm-svn: 326230
* [analyzer] Switch the default exploration strategy to priority queue based ↵George Karpenkov2018-02-271-1/+1
| | | | | | | | | | on coverage After the investigation it seems safe to flip the switch. Differential Revision: https://reviews.llvm.org/D43782 llvm-svn: 326157
* Revert "Revert "[analyzer] Quickfix: do not overflow in calculating offset ↵George Karpenkov2018-02-271-0/+47
| | | | | | | | | | in RegionManager"" This reverts commit c4cc41166d93178a3ddd4b2b5a685cf74a459247. Revert and fix uninitialized read. llvm-svn: 326152
* [StaticAnalyzer] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2018-02-263-186/+199
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 326146
* [analyzer] Exploration strategy prioritizing unexplored nodes firstGeorge Karpenkov2018-02-262-0/+66
| | | | | | | | | | | | | | See D42775 for discussion. Turns out, just exploring nodes which weren't explored first is not quite enough, as e.g. the first quick traversal resulting in a report can mark everything as "visited", and then subsequent traversals of the same region will get all the pitfalls of DFS. Priority queue-based approach in comparison shows much greater increase in coverage and even performance, without sacrificing memory. Differential Revision: https://reviews.llvm.org/D43354 llvm-svn: 326136
* Revert "[analyzer] Quickfix: do not overflow in calculating offset in ↵George Karpenkov2018-02-261-46/+0
| | | | | | | | | | RegionManager" This reverts commit df306c4c5ab4a6b8d3c47432346d1f9b90c328b4. Reverting until I can figured out the reasons for failures. llvm-svn: 326131
* [analyzer] Quickfix: do not overflow in calculating offset in RegionManagerGeorge Karpenkov2018-02-261-0/+46
| | | | | | | | | | | | | | Addresses https://bugs.llvm.org/show_bug.cgi?id=36206 rdar://37159026 A proper fix would be much harder, and would involve changing the appropriate code in ExprEngine to be aware of the size limitations of the type used for addressing. Differential Revision: https://reviews.llvm.org/D43218 llvm-svn: 326122
* Remove unused variable. We should be warning-free.Daniel Jasper2018-02-241-1/+1
| | | | llvm-svn: 326024
* [analyzer] Relax the assert used when traversing the node graph.George Karpenkov2018-02-231-1/+5
| | | | | | | | | | | | | | The assertion gets exposed when changing the exploration order. This is a quick hacky fix, but the intention is that if the nodes do merge, it should not matter which predecessor should be traverse. A proper fix would be not to traverse predecessors at all, as all information relevant for any decision should be avilable locally. rdar://37540480 Differential Revision: https://reviews.llvm.org/D42773 llvm-svn: 325977
* [analyzer] mark returns of functions where the region passed as parameter ↵George Karpenkov2018-02-231-0/+272
| | | | | | | | | | | | | | | | | | was not initialized In the wild, many cases of null pointer dereference, or uninitialized value read occur because the value was meant to be initialized by the inlined function, but did not, most often due to error condition in the inlined function. This change highlights the return branch taken by the inlined function, in order to help user understand the error report and see why the value was uninitialized. rdar://36287652 Differential Revision: https://reviews.llvm.org/D41848 llvm-svn: 325976
* [analyzer] Consider switch- and goto- labels when constructing the set of ↵George Karpenkov2018-02-231-6/+24
| | | | | | | | | | | | executed lines When viewing the report in the collapsed mode the label signifying where did the execution go is often necessary for properly understanding the context. Differential Revision: https://reviews.llvm.org/D43145 llvm-svn: 325975
* [Analyzer] Move UnexploredFirstStack into an anonymous namespace.Benjamin Kramer2018-02-181-0/+2
| | | | | | No functionality change intended. llvm-svn: 325468
* Silence a -Wparentheses warning; NFC.Aaron Ballman2018-02-151-1/+1
| | | | llvm-svn: 325293
* Silence some -Wunused-variable warnings; NFC.Aaron Ballman2018-02-151-2/+2
| | | | llvm-svn: 325292
* [analyzer] Suppress temporary destructors for temporary arrays.Artem Dergachev2018-02-151-3/+16
| | | | | | | | | | | | | | | Array destructors, like constructors, need to be called for each element of the array separately. We do not have any mechanisms to do this in the analyzer, so for now all we do is evaluate a single constructor or destructor conservatively and give up. It automatically causes the necessary invalidation and pointer escape for the whole array, because this is how RegionStore works. Implement this conservative behavior for temporary destructors. This fixes the crash on the provided test. Differential Revision: https://reviews.llvm.org/D43149 llvm-svn: 325286
* [analyzer] Implement path notes for temporary destructors.Artem Dergachev2018-02-151-2/+8
| | | | | | | | | | | | | | Temporary destructors fire at the end of the full-expression. It is reasonable to attach the path note for entering/leaving the temporary destructor to its CXXBindTemporaryExpr. This would not affect lifetime-extended temporaries with their automatic destructors which aren't temporary destructors. The path note may be confusing in the case of destructors after elidable copy constructors. Differential Revision: https://reviews.llvm.org/D43144 llvm-svn: 325284
* [analyzer] Compute the correct this-region for temporary destructors.Artem Dergachev2018-02-155-88/+147
| | | | | | | | | | | | | | | | | | | Inline them if possible - a separate flag is added to control this. The whole thing is under the cfg-temporary-dtors flag, off by default so far. Temporary destructors are called at the end of full-expression. If the temporary is lifetime-extended, automatic destructors kick in instead, which are not addressed in this patch, and normally already work well modulo the overally broken support for lifetime extension. The patch operates by attaching the this-region to the CXXBindTemporaryExpr in the program state, and then recalling it during destruction that was triggered by that CXXBindTemporaryExpr. It has become possible because CXXBindTemporaryExpr is part of the construction context since r325210. Differential revision: https://reviews.llvm.org/D43104 llvm-svn: 325282
* [analyzer] NFC: Eliminate ParentMap lookup in mayInlineCallKind().Artem Dergachev2018-02-152-9/+3
| | | | | | | | Don't look at the parent statement to figure out if the cxx-allocator-inlining flag should kick in and prevent us from inlining the constructor within a new-expression. We now have construction contexts for that purpose. llvm-svn: 325278
* [analyzer] Inline constructors for destroyable temporaries.Artem Dergachev2018-02-151-0/+3
| | | | | | | | | | | | | | | | | | | | | Since r325210, in cfg-temporary-dtors mode, we can rely on the CFG to tell us that we're indeed constructing a temporary, so we can trivially construct a temporary region and inline the constructor. Much like r325202, this is only done under the off-by-default cfg-temporary-dtors flag because the temporary destructor, even if available, will not be inlined and won't have the correct object value (target region). Unless this is fixed, it is quite unsafe to inline the constructor. If the temporary is lifetime-extended, the destructor would be an automatic destructor, which would be evaluated with a "correct" target region - modulo the series of incorrect relocations performed during the lifetime extension. It means that at least, values within the object are guaranteed to be properly escaped or invalidated. Differential Revision: https://reviews.llvm.org/D43062 llvm-svn: 325211
* [analyzer] Decide on inlining destructors via EvalCallOptions.Artem Dergachev2018-02-153-55/+59
| | | | | | | | | | | | | | | | | | | | EvalCallOptions were introduced in r324018 for allowing various parts of ExprEngine to notify the inlining mechanism, while preparing for evaluating a function call, of possible difficulties with evaluating the call that they foresee. Then mayInlineCall() would still be a single place for making the decision. Use that mechanism for destructors as well - pass the necessary flags from the CFG-element-specific destructor handlers. Part of this patch accidentally leaked into r324018, which led into a change in tests; this change is reverted now, because even though the change looked correct, the underlying behavior wasn't. Both of these commits were not intended to introduce any function changes otherwise. Differential Revision: https://reviews.llvm.org/D42991 llvm-svn: 325209
* [analyzer] Allow inlining constructors into return values.Artem Dergachev2018-02-152-4/+23
| | | | | | | | | | | | | | | | | This only affects the cfg-temporary-dtors mode - in this mode we begin inlining constructors that are constructing function return values. These constructors have a correct construction context since r324952. Because temporary destructors are not only never inlined, but also don't have the correct target region yet, this change is not entirely safe. But this will be fixed in the subsequent commits, while this stays off behind the cfg-temporary-dtors flag. Lifetime extension for return values is still not modeled correctly. Differential Revision: https://reviews.llvm.org/D42875 llvm-svn: 325202
* [analyzer] NFC: Remove dead checks when computing DeclStmt construction region.Artem Dergachev2018-02-151-9/+6
| | | | | | | | | In CFG, every DeclStmt has exactly one decl, which is always a variable. It is also pointless to check that the initializer is the constructor because that's how construction contexts work now. llvm-svn: 325201
* [analyzer] Exploration strategy prioritizing unexplored coverage firstGeorge Karpenkov2018-02-122-12/+79
| | | | | | | | | | See reviews.llvm.org/M1 for evaluation, and lists.llvm.org/pipermail/cfe-dev/2018-January/056718.html for discussion. Differential Revision: https://reviews.llvm.org/D42775 llvm-svn: 324956
* [analyzer] NFC: Assert that our fix for noreturn destructors keeps working.Artem Dergachev2018-02-101-5/+15
| | | | | | | | | | | | | | | | Massive false positives were known to be caused by continuing the analysis after a destructor with a noreturn attribute has been executed in the program but not modeled in the analyzer due to being missing in the CFG. Now that work is being done on enabling the modeling of temporary constructors and destructors in the CFG, we need to make sure that the heuristic that suppresses these false positives keeps working when such modeling is disabled. In particular, different code paths open up when the corresponding constructor is being inlined during analysis. Differential Revision: https://reviews.llvm.org/D42779 llvm-svn: 324802
* [analyzer] NFC: Use CFG construction contexts instead of homemade lookahead.Artem Dergachev2018-02-101-59/+11
| | | | | | | | | | | | | | | The analyzer was relying on peeking the next CFG element during analysis whenever it was trying to figure out what object is being constructed by a given constructor. This information is now available in the current CFG element in all cases that were previously supported by the analyzer, so no complicated lookahead is necessary anymore. No functional change intended - the context in the CFG should for now be available if and only if it was previously discoverable via CFG lookahead. Differential Revision: https://reviews.llvm.org/D42721 llvm-svn: 324800
OpenPOWER on IntegriCloud