summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [AST] Remove ASTContext from getThisType (NFC)Brian Gesiak2019-01-111-2/+2
| | | | | | | | | | | | | | | | | | | | | Summary: https://reviews.llvm.org/D54862 removed the usages of `ASTContext&` from within the `CXXMethodDecl::getThisType` method. Remove the parameter altogether, as well as all usages of it. This does not result in any functional change because the parameter was unused since https://reviews.llvm.org/D54862. Test Plan: check-clang Reviewers: akyrtzi, mikael Reviewed By: mikael Subscribers: mehdi_amini, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D56509 llvm-svn: 350914
* [analyzer] Assume that we always have a SubEngine availableGabor Horvath2018-12-151-1/+1
| | | | | | | | The removed codepath was dead. Differential Revision: https://reviews.llvm.org/D55697 llvm-svn: 349266
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-301-2/+2
| | | | | | | | | It seems the two failing tests can be simply fixed after r348037 Fix 3 cases in Analysis/builtin-functions.cpp Delete the bad CodeGen/builtin-constant-p.c for now llvm-svn: 348053
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Fangrui Song2018-11-301-2/+2
| | | | | | | | | | Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp while we are investigating why the following snippet fails: extern char extern_var; struct { int a; } a = {__builtin_constant_p(extern_var)}; llvm-svn: 348039
* [analyzer] Evaluate all non-checker config options before analysisKristof Umann2018-11-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | In earlier patches regarding AnalyzerOptions, a lot of effort went into gathering all config options, and changing the interface so that potential misuse can be eliminited. Up until this point, AnalyzerOptions only evaluated an option when it was querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions would store an Optional field for it that would be None up until somewhere in the code until the flag's getter function is called. However, now that we're confident that we've gathered all configs, we can evaluate off of them before analysis, so we can emit a error on invalid input even if that prticular flag will not matter in that particular run of the analyzer. Another very big benefit of this is that debug.ConfigDumper will now show the value of all configs every single time. Also, almost all options related class have a similar interface, so uniformity is also a benefit. The implementation for errors on invalid input will be commited shorty. Differential Revision: https://reviews.llvm.org/D53692 llvm-svn: 348031
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-281-2/+2
| | | | | | | This was reverted in r347656 due to me thinking it caused a miscompile of Chromium. Turns out it was the Chromium code that was broken. llvm-svn: 347756
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused a miscompile in Chrome (see crbug.com/908372) that's illustrated by this small reduction: static bool f(int *a, int *b) { return !__builtin_constant_p(b - a) || (!(b - a)); } int arr[] = {1,2,3}; bool g() { return f(arr, arr + 3); } $ clang -O2 -S -emit-llvm a.cc -o - g() should return true, but after r347417 it became false for some reason. This also reverts the follow-up commits. r347417: > Re-Reinstate 347294 with a fix for the failures. > > Don't try to emit a scalar expression for a non-scalar argument to > __builtin_constant_p(). > > Third time's a charm! r347446: > The result of is.constant() is unsigned. r347480: > A __builtin_constant_p() returns 0 with a function type. r347512: > isEvaluatable() implies a constant context. > > Assume that we're in a constant context if we're asking if the expression can > be compiled into a constant initializer. This fixes the issue where a > __builtin_constant_p() in a compound literal was diagnosed as not being > constant, even though it's always possible to convert the builtin into a > constant. r347531: > A "constexpr" is evaluated in a constant context. Make sure this is reflected > if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347656
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-211-2/+2
| | | | | | | | | Don't try to emit a scalar expression for a non-scalar argument to __builtin_constant_p(). Third time's a charm! llvm-svn: 347417
* Revert r347364 again, the fix was incomplete.Nico Weber2018-11-211-2/+2
| | | | llvm-svn: 347389
* Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-201-2/+2
| | | | | | | EvaluateAsInt() is sometimes called in a constant context. When that's the case, we need to specify it as so. llvm-svn: 347364
* [analyzer] [NFC] Remove unused "state" argument from makeSymExprValNNGeorge Karpenkov2018-08-291-2/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D51250 llvm-svn: 340962
* [analyzer] Fix constraint being dropped when analyzing a program without ↵Mikhail R. Gadelha2018-07-161-3/+1
| | | | | | | | | | | | | | | | | | | | | | | taint tracking enabled Summary: This patch removes the constraint dropping when taint tracking is disabled. It also voids the crash reported in D28953 by treating a SymSymExpr with non pointer symbols as an opaque expression. Updated the regressions and verifying the big projects now; I'll update here when they're done. Based on the discussion on the mailing list and the patches by @ddcc. Reviewers: george.karpenkov, NoQ, ddcc, baloghadamsoftware Reviewed By: george.karpenkov Subscribers: delcypher, llvm-commits, rnkovacs, xazax.hun, szepet, a.sidorin, ddcc Differential Revision: https://reviews.llvm.org/D48650 llvm-svn: 337167
* DR330: look through array types when forming the cv-decomposition of a type.Richard Smith2018-07-111-1/+5
| | | | | | | | | | This allows more qualification conversions, eg. conversion from 'int *(*)[]' -> 'const int *const (*)[]' is now permitted, along with all the consequences of that: more types are similar, more cases are permitted by const_cast, and conversely, fewer "casting away constness" cases are permitted by reinterpret_cast. llvm-svn: 336745
* [analyzer] Add option to set maximum symbol complexity thresholdMikhail R. Gadelha2018-07-101-1/+5
| | | | | | | | | | | | | | | | | | | Summary: This adds an option, max-symbol-complexity, so an user can set the maximum symbol complexity threshold. Note that the current behaviour is equivalent to max complexity = 0, when taint analysis is not enabled and tests show that in a number of tests, having complexity = 25 yields the same results as complexity = 10000. This patch was extracted and modified from Dominic Chen's patch, D35450. Reviewers: george.karpenkov, NoQ, ddcc Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49093 llvm-svn: 336671
* [analyzer] Treat more const variables and fields as known contants.Artem Dergachev2018-05-041-1/+8
| | | | | | | | | | | | | | | | When loading from a variable or a field that is declared as constant, the analyzer will try to inspect its initializer and constant-fold it. Upon success, the analyzer would skip normal load and return the respective constant. The new behavior also applies to fields/elements of brace-initialized structures and arrays. Patch by Rafael Stahl! Differential Revision: https://reviews.llvm.org/D45774 llvm-svn: 331556
* [StaticAnalyzer] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2018-03-061-18/+31
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 326757
* [analyzer] a few helper methods for getting and comparing symbolic valuesGeorge Karpenkov2018-01-181-1/+10
| | | | | | | | API calls should express intent, and that's a motivation behind this patch. Differential Revision: https://reviews.llvm.org/D42218 llvm-svn: 322809
* Revert "[analyzer] Support generating and reasoning over more symbolic ↵Dominic Chen2017-07-121-2/+5
| | | | | | | | | | constraint types" Assertion `Loc::isLocType(SSE->getLHS()->getType())' failed in Analysis/PR3991.m This reverts commit e469ff2759275e67f9072b3d67fac90f647c0fe6. llvm-svn: 307853
* [analyzer] Support generating and reasoning over more symbolic constraint typesDominic Chen2017-07-121-5/+2
| | | | | | | | | | | | Summary: Generate more IntSymExpr constraints, perform SVal simplification for IntSymExpr and SymbolCast constraints, and create fully symbolic SymExprs Reviewers: zaks.anna, dcoughlin, NoQ, xazax.hun Subscribers: mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D28953 llvm-svn: 307833
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-031-0/+1
| | | | llvm-svn: 304644
* [analyzer] Treat pointers to static member functions as function pointersDevin Coughlin2017-01-101-0/+12
| | | | | | | | | | | | Sema treats pointers to static member functions as having function pointer type, so treat treat them as function pointer values in the analyzer as well. This prevents an assertion failure in SValBuilder::evalBinOp caused by code that expects function pointers to be Locs (in contrast, PointerToMember values are nonlocs). Differential Revision: https://reviews.llvm.org/D28033 llvm-svn: 291581
* [analyzer] Add a new SVal to support pointer-to-member operations.Devin Coughlin2016-12-151-0/+4
| | | | | | | | | | | Add a new type of NonLoc SVal for C++ pointer-to-member operations. This SVal supports both pointers to member functions and pointers to member data. A patch by Kirill Romanenkov! Differential Revision: https://reviews.llvm.org/D25475 llvm-svn: 289873
* Remove custom handling of array copies in lambda by-value array capture andRichard Smith2016-12-141-1/+4
| | | | | | | | | | | copy constructors of classes with array members, instead using ArrayInitLoopExpr to represent the initialization loop. This exposed a bug in the static analyzer where it was unable to differentiate between zero-initialized and unknown array values, which has also been fixed here. llvm-svn: 289618
* [analyzer] Add LocationContext information to SymbolMetadata.Artem Dergachev2016-08-171-1/+2
| | | | | | | | | | | | | | | | | | | | | Like SymbolConjured, SymbolMetadata also needs to be uniquely identified by the moment of its birth. Such moments are coded by the (Statement, LocationContext, Block count) triples. Each such triple represents the moment of analyzing a statement with a certain call backtrace, with corresponding CFG block having been entered a given amount of times during analysis of the current code body. The LocationContext information was accidentally omitted for SymbolMetadata, which leads to reincarnation of SymbolMetadata upon re-entering a code body with a different backtrace; the new symbol is incorrectly unified with the old symbol, which leads to unsound assumptions. Patch by Alexey Sidorin! Differential Revision: https://reviews.llvm.org/D21978 llvm-svn: 278937
* [analyzer] Avoid crash when attempting to evaluate binary operation on ↵Devin Coughlin2016-02-081-0/+5
| | | | | | | | | | | LazyCompoundVal. Instead, return UnknownValue if either operand is a nonloc::LazyCompoundVal. This is a spot fix for PR 24951. rdar://problem/23682244 llvm-svn: 260066
* [analyzer] Fix an off-by-one in evalIntegralCast()Artem Dergachev2016-01-181-1/+1
| | | | | | | | | Make sure that we do not add SymbolCast at the very boundary of the range in which the cast would not certainly happen. Differential Revision: http://reviews.llvm.org/D16178 llvm-svn: 258039
* [analyzer] Fix SVal/SymExpr/MemRegion class and enum names for consistency.Artem Dergachev2016-01-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The purpose of these changes is to simplify introduction of definition files for the three hierarchies. 1. For every sub-class C of these classes, its kind in the relevant enumeration is changed to "CKind" (or C##Kind in preprocessor-ish terms), eg: MemRegionKind -> MemRegionValKind RegionValueKind -> SymbolRegionValueKind CastSymbolKind -> SymbolCastKind SymIntKind -> SymIntExprKind 2. MemSpaceRegion used to be inconsistently used as both an abstract base and a particular region. This region class is now an abstract base and no longer occupies GenericMemSpaceRegionKind. Instead, a new class, CodeSpaceRegion, is introduced for handling the unique use case for MemSpaceRegion as "the generic memory space" (when it represents a memory space that holds all executable code). 3. BEG_ prefixes in memory region kind ranges are renamed to BEGIN_ for consisitency with symbol kind ranges. 4. FunctionTextRegion and BlockTextRegion are renamed to FunctionCodeRegion and BlockCodeRegion, respectively. The term 'code' is less jargony than 'text' and we already refer to BlockTextRegion as a 'code region' in BlockDataRegion. Differential Revision: http://reviews.llvm.org/D16062 llvm-svn: 257598
* [analyzer] Evaluate integral casts as cast symbols if truncations are detected.Pierre Gousseau2016-01-121-0/+39
| | | | | | | | | | | | | The current workaround for truncations not being modelled is that the evaluation of integer to integer casts are simply bypassed and so the original symbol is used as the new casted symbol (cf SimpleSValBuilder::evalCastFromNonLoc). This lead to the issue described in PR25078, as the RangeConstraintManager associates ranges with symbols. The new evalIntegralCast method added by this patch wont bypass the cast if it finds the range of the symbol to be greater than the maximum value of the target type. The fix to RangeSet::pin mentioned in the initial review will be committed separately. Differential Revision: http://reviews.llvm.org/D12901 llvm-svn: 257464
* [analyzer] Improve modelling of nullptr_t in the analyzer. Fix PR25414.Gabor Horvath2015-12-041-0/+17
| | | | | | Differential Revision: http://reviews.llvm.org/D15007 llvm-svn: 254718
* [analyzer] Improve modeling of static initializers.Anna Zaks2015-11-191-4/+10
| | | | | | | | | | | | Conversions between unrelated pointer types (e.g. char * and void *) involve bitcasts which were not properly modeled in case of static initializers. The patch fixes this problem. The problem was originally spotted by Artem Dergachev. Patched by Yuri Gribov! Differential Revision: http://reviews.llvm.org/D14652 llvm-svn: 253532
* Analyzer: Teach analyzer how to handle TypeTraitExprIsmail Pazarbasi2015-09-221-0/+5
| | | | | | | | | | | | | | | | | | | | Summary: `TypeTraitExpr`s are not supported by the ExprEngine today. Analyzer creates a sink, and aborts the block. Therefore, certain bugs that involve type traits intrinsics cannot be detected (see PR24710). This patch creates boolean `SVal`s for `TypeTraitExpr`s, which are evaluated by the compiler. Test within the patch is a summary of PR24710. Reviewers: zaks.anna, dcoughlin, krememek Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D12482 llvm-svn: 248314
* [analyzer] Apply whitespace cleanups by Honggyu Kim.Ted Kremenek2015-09-081-5/+5
| | | | llvm-svn: 246978
* [analyzer] Always use 'bool' as the SValBuilder condition type in C++.Jordan Rose2013-12-191-1/+1
| | | | | | | | | We have assertions for this, but a few edge cases had snuck through where we were still unconditionally using 'int'. <rdar://problem/15703011> llvm-svn: 197733
* Correct hyphenations in comments and assert messagesAlp Toker2013-12-051-1/+1
| | | | | | | This patch tries to avoid unrelated changes other than fixing a few hyphen-related ambiguities in nearby lines. llvm-svn: 196466
* [analyzer] Fix an infinite recursion in region invalidation by adding block ↵Anna Zaks2013-11-201-2/+4
| | | | | | count to the BlockDataRegion. llvm-svn: 195174
* [analyzer] Don't even try to convert floats to booleans for now.Jordan Rose2013-09-181-0/+4
| | | | | | | | | | | We now have symbols with floating-point type to make sure that (double)x == (double)x comes out true, but we still can't do much with these. For now, don't even bother trying to create a floating-point zero value; just give up on conversion to bool. PR14634, C++ edition. llvm-svn: 190953
* [analyzer] Add support for testing the presence of weak functions.Jordan Rose2013-08-281-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | When casting the address of a FunctionTextRegion to bool, or when adding constraints to such an address, use a stand-in symbol to represent the presence or absence of the function if the function is weakly linked. This is groundwork for possible simple availability testing checks, and can already catch mistakes involving inverted null checks for weakly-linked functions. Currently, the implementation reuses the "extent" symbols, originally created for tracking the size of a malloc region. Since FunctionTextRegions cannot be dereferenced, the extent symbol will never be used for anything else. Still, this probably deserves a refactoring in the future. This patch does not attempt to support testing the presence of weak /variables/ (global variables), which would likely require much more of a change and a generalization of "region structure metadata", like the current "extents", vs. "region contents metadata", like CStringChecker's "string length". Patch by Richard <tarka.t.otter@googlemail.com>! llvm-svn: 189492
* [analyzer] Weaken assertion to account for pointer-to-integer casts.Jordan Rose2013-07-251-1/+1
| | | | | | PR16690 llvm-svn: 187132
* [analyzer] Handle C string default values for const char * arguments.Jordan Rose2013-07-171-0/+11
| | | | | | | | | | Previously, SValBuilder knew how to evaluate StringLiterals, but couldn't handle an array-to-pointer decay for constant values. Additionally, RegionStore was being too strict about loading from an array, refusing to return a 'char' value from a 'const char' array. Both of these have been fixed. llvm-svn: 186520
* [analyzer] Use the expression’s type instead of region’s type in ↵Anna Zaks2013-05-281-2/+4
| | | | | | | | | ArrayToPointer decay evaluation This gives slightly better precision, specifically, in cases where a non-typed region represents the array or when the type is a non-array type, which can happen when an array is a result of a reinterpret_cast. llvm-svn: 182810
* [analyzer] Don't try to evaluate MaterializeTemporaryExpr as a constant.Jordan Rose2013-05-021-2/+7
| | | | | | | | | | | | | | | ...and don't consider '0' to be a null pointer constant if it's the initializer for a float! Apparently null pointer constant evaluation looks through both MaterializeTemporaryExpr and ImplicitCastExpr, so we have to be more careful about types in the callers. For RegionStore this just means giving up a little more; for ExprEngine this means handling the MaterializeTemporaryExpr case explicitly. Follow-up to r180894. llvm-svn: 180944
* [analyzer] Consolidate constant evaluation logic in SValBuilder.Jordan Rose2013-05-011-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, this was scattered across Environment (literal expressions), ExprEngine (default arguments), and RegionStore (global constants). The former special-cased several kinds of simple constant expressions, while the latter two deferred to the AST's constant evaluator. Now, these are all unified as SValBuilder::getConstantVal(). To keep Environment fast, the special cases for simple constant expressions have been left in, but the main benefits are that (a) unusual constants like ObjCStringLiterals now work as default arguments and global constant initializers, and (b) we're not duplicating code between ExprEngine and RegionStore. This actually caught a bug in our test suite, which is awesome: we stop tracking allocated memory if it's passed as an argument along with some kind of callback, but not if the callback is 0. We were testing this in a case where the callback parameter had a default value, but that value was 0. After this change, the analyzer now (correctly) flags that as a leak! <rdar://problem/13773117> llvm-svn: 180894
* Re-apply "[analyzer] Model casts to bool differently from other numbers."Jordan Rose2013-05-011-0/+16
| | | | | | | | | | | | | | This doesn't appear to be the cause of the slowdown. I'll have to try a manual bisect to see if there's really anything there, or if it's just the bot itself taking on additional load. Meanwhile, this change helps with correctness. This changes an assertion and adds a test case, then re-applies r180638, which was reverted in r180714. <rdar://problem/13296133> and PR15863 llvm-svn: 180864
* Revert "[analyzer] Model casts to bool differently from other numbers."Jordan Rose2013-04-291-16/+0
| | | | | | | | | This seems to be causing quite a slowdown on our internal analyzer bot, and I'm not sure why. Needs further investigation. This reverts r180638 / 9e161ea981f22ae017b6af09d660bfc3ddf16a09. llvm-svn: 180714
* [analyzer] Model casts to bool differently from other numbers.Jordan Rose2013-04-261-0/+16
| | | | | | | | | | | | | | | | | | | Casts to bool (and _Bool) are equivalent to checks against zero, not truncations to 1 bit or 8 bits. This improved reasoning does cause a change in the behavior of the alpha BoolAssignment checker. Previously, this checker complained about statements like "bool x = y" if 'y' was known not to be 0 or 1. Now it does not, since that conversion is well-defined. It's hard to say what the "best" behavior here is: this conversion is safe, but might be better written as an explicit comparison against zero. More usefully, besides improving our model of booleans, this fixes spurious warnings when returning the address of a local variable cast to bool. <rdar://problem/13296133> llvm-svn: 180638
* [analyzer] Do not crash when processing binary "?:" in C++Anna Zaks2013-04-151-5/+12
| | | | | | | | | | | | | | | | | | | | | | When computing the value of ?: expression, we rely on the last expression in the previous basic block to be the resulting value of the expression. This is not the case for binary "?:" operator (GNU extension) in C++. As the last basic block has the expression for the condition subexpression, which is an R-value, whereas the true subexpression is the L-value. Note the operator evaluation just happens to work in C since the true subexpression is an R-value (like the condition subexpression). CFG is the same in C and C++ case, but the AST nodes are different, which the LValue to Rvalue conversion happening after the BinaryConditionalOperator evaluation. Changed the logic to only use the last expression from the predecessor only if it matches either true or false subexpression. Note, the logic needed fortification anyway: L and R were passed but not even used by the function. Also, change the conjureSymbolVal to correctly compute the type, when the expression is an LG-value. llvm-svn: 179574
* [analyzer] Replace isIntegerType() with isIntegerOrEnumerationType().Jordan Rose2013-04-091-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, the analyzer used isIntegerType() everywhere, which uses the C definition of "integer". The C++ predicate with the same behavior is isIntegerOrUnscopedEnumerationType(). However, the analyzer is /really/ using this to ask if it's some sort of "integrally representable" type, i.e. it should include C++11 scoped enumerations as well. hasIntegerRepresentation() sounds like the right predicate, but that includes vectors, which the analyzer represents by its elements. This commit audits all uses of isIntegerType() and replaces them with the general isIntegerOrEnumerationType(), except in some specific cases where it makes sense to exclude scoped enumerations, or any enumerations. These cases now use isIntegerOrUnscopedEnumerationType() and getAs<BuiltinType>() plus BuiltinType::isInteger(). isIntegerType() is hereby banned in the analyzer - lib/StaticAnalysis and include/clang/StaticAnalysis. :-) Fixes real assertion failures. PR15703 / <rdar://problem/12350701> llvm-svn: 179081
* Include llvm::Optional in clang/Basic/LLVM.hDavid Blaikie2013-02-201-11/+7
| | | | | | Post-commit CR feedback from Jordan Rose regarding r175594. llvm-svn: 175679
* Replace SVal llvm::cast support to be well-defined.David Blaikie2013-02-201-17/+22
| | | | | | See r175462 for another example/more details. llvm-svn: 175594
OpenPOWER on IntegriCloud