summaryrefslogtreecommitdiffstats
path: root/clang/test/Analysis
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] Enable cfg-temporary-dtors by default.Artem Dergachev2018-03-016-9/+10
| | | | | | | | | | | | 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-1/+160
| | | | | | | | | | | 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-160/+1
| | | | | | | | | | 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
* [analyzer] Add a checker for mmap()s which are both writable and executable.Artem Dergachev2018-03-011-0/+36
| | | | | | | | | | | | | | | | | | | This is a security check that warns when both PROT_WRITE and PROT_EXEC are set during mmap(). If mmap()ed memory is both writable and executable, it makes it easier for the attacker to execute arbitrary code when contents of this memory are compromised. Some applications require such mmap()s though, such as different sorts of JIT. Re-applied after a revert in r324167. Temporarily stays in the alpha package because it needs a better way of determining macro values that are not immediately available in the AST. Patch by David Carlier! Differential Revision: https://reviews.llvm.org/D42645 llvm-svn: 326405
* [CFG] [analyzer] Recall that we only skip NoOp casts in construction contexts.Artem Dergachev2018-03-011-0/+31
| | | | | | | | | | | | For now. We should also add support for ConstructorConversion casts as presented in the attached test case, but this requires more changes because AST around them seems different. The check was originally present but was accidentally lost during r326021. Differential Revision: https://reviews.llvm.org/D43840 llvm-svn: 326402
* [analyzer] Support for naive cross translation unit analysisGabor Horvath2018-02-285-1/+160
| | | | | | | | | | | | | | | | | | 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
* [analyzer] UndefinedAssignmentChecker: Better warning message in implicit ctors.Artem Dergachev2018-02-271-0/+75
| | | | | | | | | | | | | | | | | | When a class forgets to initialize a field in the constructor, and then gets copied around, a warning is emitted that the value assigned to a specific field is undefined. When the copy/move constructor is implicit (not written out in the code) but not trivial (is not a trivial memory copy, eg. because members have an explicit copy constructor), the body of such constructor is auto-generated in the AST. In this case the checker's warning message is squeezed at the top of the class declaration, and it gets hard to guess which field is at fault. Fix the warning message to include the name of the field. Differential Revision: https://reviews.llvm.org/D43798 llvm-svn: 326258
* [analyzer] MallocChecker: Suppress false positives in shared pointers.Artem Dergachev2018-02-271-0/+74
| | | | | | | | | | | | | | | | | | Throw away MallocChecker warnings that occur after releasing a pointer within a destructor (or its callees) after performing C11 atomic fetch_add or fetch_sub within that destructor (or its callees). This is an indication that the destructor's class is likely a reference-counting pointer. The analyzer is not able to understand that the original reference count is usually large enough to avoid most use-after-frees. Even when the smart pointer is a local variable, we still have these false positives that this patch suppresses, because the analyzer doesn't currently support atomics well enough. Differential Revision: https://reviews.llvm.org/D43791 llvm-svn: 326249
* [analyzer] Fix trivial copy for empty objects.Artem Dergachev2018-02-271-0/+20
| | | | | | | | | | | | | | 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-6/+11
| | | | | | | | | | | | | | | | | | | | | | 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-0/+28
| | | | | | | | | | | | | | | | | | | 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-271-18/+5
| | | | | | | | | | | | | 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] Introduce correct lifetime extension behavior in simple cases.Artem Dergachev2018-02-272-5/+181
| | | | | | | | | | | | | | | | | | | | | | | | 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] Only attempt to get the value of locations of known typeGeorge Karpenkov2018-02-271-0/+8
| | | | | | | | | | | | Fixes https://bugs.llvm.org/show_bug.cgi?id=36474 In general, getSVal API should be changed so that it does not crash on some non-obvious conditions. It should either be updated to require a type, or to return Optional<SVal>. Differential Revision: https://reviews.llvm.org/D43801 llvm-svn: 326233
* [analyzer] Logging test quickfix #2.George Karpenkov2018-02-271-3/+2
| | | | llvm-svn: 326229
* [analyzer] Switch the default exploration strategy to priority queue based ↵George Karpenkov2018-02-274-5/+10
| | | | | | | | | | on coverage After the investigation it seems safe to flip the switch. Differential Revision: https://reviews.llvm.org/D43782 llvm-svn: 326157
* [analyzer] Logging test typo quickfix.George Karpenkov2018-02-271-1/+1
| | | | llvm-svn: 326156
* [analyzer] Logging test quickfix.George Karpenkov2018-02-271-2/+1
| | | | llvm-svn: 326155
* Revert "Revert "[analyzer] Quickfix: do not overflow in calculating offset ↵George Karpenkov2018-02-272-1/+14
| | | | | | | | | | in RegionManager"" This reverts commit c4cc41166d93178a3ddd4b2b5a685cf74a459247. Revert and fix uninitialized read. llvm-svn: 326152
* [analyzer] Exploration strategy prioritizing unexplored nodes firstGeorge Karpenkov2018-02-261-0/+1
| | | | | | | | | | | | | | 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
* [analyzer] Do not analyze bison-generated filesGeorge Karpenkov2018-02-261-0/+13
| | | | | | | | | | | | | | | | | | | | | Bison/YACC generated files result in a very large number of (presumably) false positives from the analyzer. These false positives are "true" in a sense of the information analyzer sees: assuming that the lexer can return any token at any point a number of uninitialized reads does occur. (naturally, the analyzer can not capture a complex invariant that certain tokens can only occur under certain conditions). Current fix simply stops analysis on those files. I have examined a very large number of such auto-generated files, and they do all start with such a comment. Conversely, user code is very unlikely to contain such a comment. rdar://33608161 Differential Revision: https://reviews.llvm.org/D43421 llvm-svn: 326135
* Revert "[analyzer] Quickfix: do not overflow in calculating offset in ↵George Karpenkov2018-02-262-14/+1
| | | | | | | | | | 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-262-1/+14
| | | | | | | | | | | | | | 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
* [CFG] Provide construction contexts for temporaries in conditional operators.Artem Dergachev2018-02-242-14/+27
| | | | | | | | | | | | | When a lifetime-extended temporary is on a branch of a conditional operator, materialization of such temporary occurs after the condition is resolved. This change allows us to understand, by including the MaterializeTemporaryExpr in the construction context, the target for temporary materialization in such cases. Differential Revision: https://reviews.llvm.org/D43483 llvm-svn: 326019
* [CFG] Provide construction contexts for temporaries bound to const references.Artem Dergachev2018-02-243-26/+26
| | | | | | | | | | In order to bind a temporary to a const lvalue reference, a no-op cast is added to make the temporary itself const, and only then the reference is taken (materialized). Skip the no-op cast when looking for the construction context. Differential Revision: https://reviews.llvm.org/D43481 llvm-svn: 326016
* [CFG] Provide construction contexts for functional cast-like constructors.Artem Dergachev2018-02-241-8/+30
| | | | | | | | | | When a constructor of a temporary with a single argument is treated as a functional cast expression, skip the functional cast expression and provide the correct construction context for the temporary. Differential Revision: https://reviews.llvm.org/D43480 llvm-svn: 326015
* [CFG] Provide construction contexts for lifetime-extended temporaries.Artem Dergachev2018-02-242-10/+14
| | | | | | | | | | | | | | When constructing a temporary that is going to be lifetime-extended through a MaterializeTemporaryExpr later, CFG elements for the respective constructor can now be queried to obtain the reference to that MaterializeTemporaryExpr and therefore gain information about lifetime extension. This may produce multi-layered construction contexts when information about both temporary destruction and lifetime extension is available. Differential Revision: https://reviews.llvm.org/D43477 llvm-svn: 326014
* [analyzer] Relax the assert used when traversing the node graph.George Karpenkov2018-02-231-0/+17
| | | | | | | | | | | | | | 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-235-5/+500
| | | | | | | | | | | | | | | | | | 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-233-0/+53
| | | | | | | | | | | | 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] Prevent AnalyzerStatsChecker from crashPeter Szecsi2018-02-211-1/+17
| | | | | | | | | | | | The checker marks the locations where the analyzer creates sinks. However, it can happen that the sink was created because of a loop which does not contain condition statement, only breaks in the body. The exhausted block is the block which should contain the condition but empty, in this case. This change only emits this marking in order to avoid the undefined behavior. Differential Revision: https://reviews.llvm.org/D42266 llvm-svn: 325693
* [analyzer] Suppress temporary destructors for temporary arrays.Artem Dergachev2018-02-151-0/+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-0/+64
| | | | | | | | | | | | | | 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-153-1/+138
| | | | | | | | | | | | | | | | | | | 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] Inline constructors for destroyable temporaries.Artem Dergachev2018-02-151-16/+105
| | | | | | | | | | | | | | | | | | | | | 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
* [CFG] Provide construction contexts for temproary objects.Artem Dergachev2018-02-153-65/+264
| | | | | | | | | | | | | | | Constructors of C++ temporary objects that have destructors now can be queried to discover that they're indeed constructing temporary objects. The respective CXXBindTemporaryExpr, which is also repsonsible for destroying the temporary at the end of full-expression, is now available at the construction site in the CFG. This is all the context we need to provide for temporary objects that are not lifetime extended. For lifetime-extended temporaries, more context is necessary. Differential Revision: https://reviews.llvm.org/D43056 llvm-svn: 325210
* [analyzer] Decide on inlining destructors via EvalCallOptions.Artem Dergachev2018-02-151-1/+2
| | | | | | | | | | | | | | | | | | | | 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-151-2/+162
| | | | | | | | | | | | | | | | | 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
* Teach Wreturn-type, Wunreachable-code, and alpha.deadcode.UnreachableCode to ↵Nico Weber2018-02-131-0/+1
| | | | | | | | | treat __assume(0) like __builtin_unreachable. Fixes PR29134. https://reviews.llvm.org/D43221 llvm-svn: 325052
* [analyzer] Exploration strategy prioritizing unexplored coverage firstGeorge Karpenkov2018-02-121-0/+39
| | | | | | | | | | 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
* [CFG] Provide construction contexts for return value constructors.Artem Dergachev2018-02-122-2/+96
| | | | | | | | | | | When the current function returns a C++ object by value, CFG elements for constructors that construct the return values can now be queried to discover that they're indeed participating in construction of the respective return value at the respective return statement. Differential Revision: https://reviews.llvm.org/D42875 llvm-svn: 324952
* [analyzer] Fix a merge error in -analyzer-config tests.Artem Dergachev2018-02-102-2/+2
| | | | | | | | | | It was introduced when two -analyzer-config options were added almost simultaneously in r324793 and r324668 and the option count was not rebased correctly in the tests. Fixes the buildbots. llvm-svn: 324801
* [CFG] Provide construction contexts when constructors have cleanups.Artem Dergachev2018-02-102-13/+108
| | | | | | | | | | | | | | | Now that we make it possible to query the CFG constructor element to find information about the construction site, possible cleanup work represented by ExprWithCleanups should not prevent us from providing this information. This allows us to have a correct construction context for variables initialized "by value" via elidable copy-constructors, such as 'i' in iterator i = vector.begin(); Differential Revision: https://reviews.llvm.org/D42719 llvm-svn: 324798
* [CFG] Add construction context for constructor initializers.Artem Dergachev2018-02-102-5/+35
| | | | | | | | | | | | | | CFG elements for constructors of fields and base classes that are being initialized before the body of the whole-class constructor starts can now be queried to discover that they're indeed participating in initialization of their respective fields or bases before the whole-class constructor kicks in. CFG construction contexts are now capable of representing CXXCtorInitializer triggers, which aren't considered to be statements in the Clang AST. Differential Revision: https://reviews.llvm.org/D42700 llvm-svn: 324796
* [CFG] Add construction context for simple variable declarations.Artem Dergachev2018-02-106-61/+230
| | | | | | | | | Constructors of simple variables now can be queried to discover that they're constructing into simple variables. Differential Revision: https://reviews.llvm.org/D42699 llvm-svn: 324794
* [analyzer] Serialize statistics to plist when serialize-stats=true is setGeorge Karpenkov2018-02-103-0/+16
| | | | | | Differential Revision: https://reviews.llvm.org/D43131 llvm-svn: 324793
* [analyzer] Add missing pre-post-statement callbacks for OffsetOfExpr.Artem Dergachev2018-02-102-1/+16
| | | | | | | | | | | | | This expression may or may not be evaluated in compile time, so tracking the result symbol is of potential interest. However, run-time offsetof is not yet supported by the analyzer, so for now this callback is only there to assist future implementation. Patch by Henry Wong! Differential Revision: https://reviews.llvm.org/D42300 llvm-svn: 324790
* [analyzer] Add support for __builtin_constant_p.Artem Dergachev2018-02-101-0/+17
| | | | | | | | | | | This builtin is evaluated in compile time. But in the analyzer we don't yet automagically evaluate all calls that can be evaluated in compile time. Patch by Felix Kostenzer! Differential Revision: https://reviews.llvm.org/D42745 llvm-svn: 324789
* [analyzer] MallocChecker: Fix one more bug category.Artem Dergachev2018-02-081-0/+11
| | | | | | | | | | | Even though most of the inconsistencies in MallocChecker's bug categories were fixed in r302016, one more was introduced in r301913 which was later missed. Patch by Henry Wong! Differential Revision: https://reviews.llvm.org/D43074 llvm-svn: 324680
* [CFG] Add extra context to C++ constructor statement elements.Artem Dergachev2018-02-084-8/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional information to provide regarding what sort of object is being constructed. It is useful for figuring out what memory is initialized in client of the CFG such as the Static Analyzer, which do not operate by recursive AST traversal, but instead rely on the CFG to provide all the information when they need it. Otherwise, the statement that triggers the construction and defines what memory is being initialized would normally occur after the construct-expression, and the client would need to peek to the next CFG element or use statement parent map to understand the necessary facts about the construct-expression. As a proof of concept, CFGConstructors are added for new-expressions and the respective test cases are provided to demonstrate how it works. For now, the only additional data contained in the CFGConstructor element is the "trigger statement", such as new-expression, which is the parent of the constructor. It will be significantly expanded in later commits. The additional data is organized as an auxiliary structure - the "construction context", which is allocated separately from the CFGElement. Differential Revision: https://reviews.llvm.org/D42672 llvm-svn: 324668
OpenPOWER on IntegriCloud