summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] Fix unknown block calls to have zero parameters.Artem Dergachev2018-12-151-1/+1
| | | | | | | | | | | | Right now they report to have one parameter with null decl, because initializing an ArrayRef of pointers with a nullptr yields an ArrayRef to an array of one null pointer. Fixes a crash in the OSObject section of RetainCountChecker. Differential Revision: https://reviews.llvm.org/D55671 llvm-svn: 349229
* Using llvm::find_if() instead of a range-based for loop; NFC.Aaron Ballman2018-12-141-12/+9
| | | | | | This addresses post-commit review feedback from r349188. llvm-svn: 349197
* Update our SARIF support from 10-10 to 11-28.Aaron Ballman2018-12-141-25/+54
| | | | | | | | | | | | | Functional changes include: * The run.files property is now an array instead of a mapping. * fileLocation objects now have a fileIndex property specifying the array index into run.files. * The resource.rules property is now an array instead of a mapping. * The result object was given a ruleIndex property that is an index into the resource.rules array. * rule objects now have their "id" field filled out in addition to the name field. * Updated the schema and spec version numbers to 11-28. llvm-svn: 349188
* Misc typos fixes in ./lib folderRaphael Isemann2018-12-105-8/+8
| | | | | | | | | | | | | | Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned` Reviewers: teemperor Reviewed By: teemperor Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D55475 llvm-svn: 348755
* [analyzer] Move out tracking retain count for OSObjects into a separate checkerGeorge Karpenkov2018-12-071-74/+127
| | | | | | | | | Allow enabling and disabling tracking of ObjC/CF objects separately from tracking of OS objects. Differential Revision: https://reviews.llvm.org/D55400 llvm-svn: 348638
* [CTU] Add DisplayCTUProgress analyzer switchGabor Marton2018-12-071-2/+2
| | | | | | | | | | | | | | | | Summary: With a new switch we may be able to print to stderr if a new TU is being loaded during CTU. This is very important for higher level scripts (like CodeChecker) to be able to parse this output so they can create e.g. a zip file in case of a Clang crash which contains all the related TU files. Reviewers: xazax.hun, Szelethus, a_sidorin, george.karpenkov Subscribers: whisperity, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, Differential Revision: https://reviews.llvm.org/D55135 llvm-svn: 348594
* [analyzer] Rely on os_consumes_this attribute to signify that the method ↵George Karpenkov2018-12-061-0/+3
| | | | | | | | call consumes a reference for "this" Differential Revision: https://reviews.llvm.org/D55158 llvm-svn: 348533
* [analyzer] Fix an infinite recursion bug while checking parent methods in ↵George Karpenkov2018-12-061-1/+1
| | | | | | | | RetainCountChecker Differential Revision: https://reviews.llvm.org/D55351 llvm-svn: 348531
* [analyzer] Attribute for RetainCountChecker for OSObject should propagate ↵George Karpenkov2018-12-051-18/+51
| | | | | | | | | | with inheritance rdar://46388388 Differential Revision: https://reviews.llvm.org/D55154 llvm-svn: 348396
* [Analyzer] Iterator Checkers - Use the region of the topmost base class for ↵Adam Balogh2018-12-041-0/+9
| | | | | | | | | | | | | | | | | | iterators stored in a region If an iterator is represented by a derived C++ class but its comparison operator is for its base the iterator checkers cannot recognize the iterators compared. This results in false positives in very straightforward cases (range error when dereferencing an iterator after disclosing that it is equal to the past-the-end iterator). To overcome this problem we always use the region of the topmost base class for iterators stored in a region. A new method called getMostDerivedObjectRegion() was added to the MemRegion class to get this region. Differential Revision: https://reviews.llvm.org/D54466 llvm-svn: 348244
* [analyzer] Dump stable identifiers for objects under construction.Artem Dergachev2018-12-031-2/+10
| | | | | | | | | | This continues the work that was started in r342313, which now gets applied to object-under-construction tracking in C++. Makes it possible to debug temporaries by dumping exploded graphs again. Differential Revision: https://reviews.llvm.org/D54459 llvm-svn: 348200
* [AST] [analyzer] NFC: Reuse code in stable ID dumping methods.Artem Dergachev2018-12-032-8/+2
| | | | | | | | Use the new fancy method introduced in r348197 to simplify some code. Differential Revision: https://reviews.llvm.org/D54488 llvm-svn: 348199
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-303-7/+5
| | | | | | | | | 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-303-5/+7
| | | | | | | | | | 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-3013-149/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Reverting r347949-r347951 because they broke the test bots."George Karpenkov2018-11-301-11/+17
| | | | | | | | This reverts commit 5bad6129c012fbf186eb055be49344e790448ecc. Hopefully fixing the issue which was breaking the bots. llvm-svn: 348030
* [analyzer][PlistMacroExpansion] Part 5.: Support for # and ##Kristof Umann2018-11-301-8/+17
| | | | | | | | | From what I can see, this should be the last patch needed to replicate macro argument expansions. Differential Revision: https://reviews.llvm.org/D52988 llvm-svn: 348025
* Reverting r347949-r347951 because they broke the test bots.Aaron Ballman2018-11-301-18/+4
| | | | | | http://lab.llvm.org:8011/builders/clang-cmake-armv8-lld/builds/440/steps/ninja%20check%202/logs/FAIL%3A%20Clang%3A%3Aosobject-retain-release.cpp llvm-svn: 348020
* lyzer] [HOTFIX!] SValBuilder crash when ↵Adam Balogh2018-11-301-3/+4
| | | | | | | | | | | | | `aggressive-binary-operation-simplification` enabled During the review of D41938 a condition check with an early exit accidentally slipped into a branch, leaving the other branch unprotected. This may result in an assertion later on. This hotfix moves this contition check outside of the branch. Differential Revision: https://reviews.llvm.org/D55051 llvm-svn: 347981
* [analyzer] Fix the "Zombie Symbols" bug.Artem Dergachev2018-11-305-70/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's an old bug that consists in stale references to symbols remaining in the GDM if they disappear from other program state sections as a result of any operation that isn't the actual dead symbol collection. The most common example here is: FILE *fp = fopen("myfile.txt", "w"); fp = 0; // leak of file descriptor In this example the leak were not detected previously because the symbol disappears from the public part of the program state due to evaluating the assignment. For that reason the checker never receives a notification that the symbol is dead, and never reports a leak. This patch not only causes leak false negatives, but also a number of other problems, including false positives on some checkers. What's worse, even though the program state contains a finite number of symbols, the set of symbols that dies is potentially infinite. This means that is impossible to compute the set of all dead symbols to pass off to the checkers for cleaning up their part of the GDM. No longer compute the dead set at all. Disallow iterating over dead symbols. Disallow querying if any symbols are dead. Remove the API for marking symbols as dead, as it is no longer necessary. Update checkers accordingly. Differential Revision: https://reviews.llvm.org/D18860 llvm-svn: 347953
* [analyzer] RetainCountChecker for OSObject model the "free" callGeorge Karpenkov2018-11-301-0/+11
| | | | | | | | | The "free" call frees the object immediately, ignoring the reference count. Sadly, it is actually used in a few places, so we need to model it. Differential Revision: https://reviews.llvm.org/D55092 llvm-svn: 347950
* [analyzer] RetainCountChecker: recognize that OSObject can be created ↵George Karpenkov2018-11-301-4/+7
| | | | | | | | directly using an operator "new" Differential Revision: https://reviews.llvm.org/D55076 llvm-svn: 347949
* [analyzer] Switch retain count checker for OSObject to use OS_* attributesGeorge Karpenkov2018-11-301-11/+18
| | | | | | | | Instead of generalized reference counting annotations. Differential Revision: https://reviews.llvm.org/D55041 llvm-svn: 347948
* [analyzer] For OSObject, trust that functions starting with GetGeorge Karpenkov2018-11-301-1/+3
| | | | | | | | (uppercase) are also getters. Differential Revision: https://reviews.llvm.org/D55035 llvm-svn: 347945
* [analyzer][PlistMacroExpansion] Part 4.: Support for __VA_ARGS__Kristof Umann2018-11-291-19/+40
| | | | | | Differential Revision: https://reviews.llvm.org/D52986 llvm-svn: 347888
* [analyzer] Cleanup constructors in the Z3 backendMikhail R. Gadelha2018-11-281-96/+31
| | | | | | | | | | | | | | Summary: Left only the constructors that are actually required, and marked the move constructors as deleted. They are not used anymore and we were never sure they've actually worked correctly. Reviewers: george.karpenkov, NoQ Reviewed By: george.karpenkov Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, Szelethus, donat.nagy, dkrupp Differential Revision: https://reviews.llvm.org/D54974 llvm-svn: 347777
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-283-7/+5
| | | | | | | 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-273-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [analyzer][PlistMacroExpansion] Part 3.: Macro arguments are expandedKristof Umann2018-11-271-22/+197
| | | | | | | | This part focuses on expanding macro arguments. Differential Revision: https://reviews.llvm.org/D52795 llvm-svn: 347629
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-213-7/+5
| | | | | | | | | 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-213-5/+7
| | | | llvm-svn: 347389
* Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-203-7/+5
| | | | | | | EvaluateAsInt() is sometimes called in a constant context. When that's the case, we need to specify it as so. llvm-svn: 347364
* Revert 347294, it turned many bots on lab.llvm.org:8011/console red.Nico Weber2018-11-201-0/+3
| | | | llvm-svn: 347314
* Use is.constant intrinsic for __builtin_constant_pBill Wendling2018-11-201-3/+0
| | | | | | | | | | | | | | | | Summary: A __builtin_constant_p may end up with a constant after inlining. Use the is.constant intrinsic if it's a variable that's in a context where it may resolve to a constant, e.g., an argument to a function after inlining. Reviewers: rsmith, shafik Subscribers: jfb, kristina, cfe-commits, nickdesaulniers, jyknight Differential Revision: https://reviews.llvm.org/D54355 llvm-svn: 347294
* [analyzer][NFC] Move CheckerOptInfo to CheckerRegistry.cpp, and make it localKristof Umann2018-11-181-6/+53
| | | | | | | | | CheckerOptInfo feels very much out of place in CheckerRegistration.cpp, so I moved it to CheckerRegistry.h. Differential Revision: https://reviews.llvm.org/D54397 llvm-svn: 347157
* Convert a condition into an assertion per post-review feedback; NFC intended.Aaron Ballman2018-11-121-20/+19
| | | | llvm-svn: 346714
* [analyzer] Drastically simplify the tblgen files used for checkersKristof Umann2018-11-122-2/+2
| | | | | | | | | | | | Interestingly, only about the quarter of the emitter file is used, the DescFile entry hasn't ever been touched [1], and the entire concept of groups is a mystery, so I removed them. [1] http://lists.llvm.org/pipermail/cfe-dev/2018-October/059664.html Differential Revision: https://reviews.llvm.org/D53995 llvm-svn: 346680
* Fix compatibility with z3-4.8.1Jan Kratochvil2018-11-121-1/+1
| | | | | | | | | | | | | | | | | With z3-4.8.1: ../tools/clang/lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp:49:40: error: 'Z3_get_error_msg_ex' was not declared in this scope ../tools/clang/lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp:49:40: note: suggested alternative: 'Z3_get_error_msg' Formerly used Z3_get_error_msg_ex() as one could find in z3-4.7.1 states: "Retained function name for backwards compatibility within v4.1" And it is implemented only as a forwarding call: return Z3_get_error_msg(c, err); Differential Revision: https://reviews.llvm.org/D54391 llvm-svn: 346635
* Compound literals, enums, et al require const exprBill Wendling2018-11-092-3/+5
| | | | | | | | | | | | | | | | | | Summary: Compound literals, enums, file-scoped arrays, etc. require their initializers and size specifiers to be constant. Wrap the initializer expressions in a ConstantExpr so that we can easily check for this later on. Reviewers: rsmith, shafik Reviewed By: rsmith Subscribers: cfe-commits, jyknight, nickdesaulniers Differential Revision: https://reviews.llvm.org/D53921 llvm-svn: 346455
* Don't use std::next() on an input iterator; NFC.Aaron Ballman2018-11-061-19/+21
| | | | | | Instead, advance the old-fashioned way, as std::next() cannot be used on an input iterator until C++17. llvm-svn: 346266
* [analyzer] Restrict AnalyzerOptions' interface so that non-checker objects ↵Kristof Umann2018-11-051-114/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | have to be registered One of the reasons why AnalyzerOptions is so chaotic is that options can be retrieved from the command line whenever and wherever. This allowed for some options to be forgotten for a looooooong time. Have you ever heard of "region-store-small-struct-limit"? In order to prevent this in the future, I'm proposing to restrict AnalyzerOptions' interface so that only checker options can be retrieved without special getters. I would like to make every option be accessible only through a getter, but checkers from plugins are a thing, so I'll have to figure something out for that. This also forces developers who'd like to add a new option to register it properly in the .def file. This is done by * making the third checker pointer parameter non-optional, and checked by an assert to be non-null. * I added new, but private non-checkers option initializers, meant only for internal use, * Renamed these methods accordingly (mind the consistent name for once with getBooleanOption!): - getOptionAsString -> getCheckerStringOption, - getOptionAsInteger -> getCheckerIntegerOption * The 3 functions meant for initializing data members (with the not very descriptive getBooleanOption, getOptionAsString and getOptionAsUInt names) were renamed to be overloads of the getAndInitOption function name. * All options were in some way retrieved via getCheckerOption. I removed it, and moved the logic to getStringOption and getCheckerStringOption. This did cause some code duplication, but that's the only way I could do it, now that checker and non-checker options are separated. Note that the non-checker version inserts the new option to the ConfigTable with the default value, but the checker version only attempts to find already existing entries. This is how it always worked, but this is clunky and I might end reworking that too, so we can eventually get a ConfigTable that contains the entire configuration of the analyzer. Differential Revision: https://reviews.llvm.org/D53483 llvm-svn: 346113
* Ensure the correct order of evaluation in part 2. of PlistMacroExpansionKristof Umann2018-11-051-1/+2
| | | | | | | | Windows buildbots break with the previous commit '[analyzer][PlistMacroExpansion] Part 2.: Retrieving the macro name and primitive expansion'. This patch attempts to solve this issue. llvm-svn: 346112
* Reland '[analyzer][PlistMacroExpansion] Part 2.: Retrieving the macro name ↵Kristof Umann2018-11-051-6/+194
| | | | | | and primitive expansion' llvm-svn: 346111
* Revert '[analyzer][PlistMacroExpansion] Part 2.: Retrieving the macro name ↵Kristof Umann2018-11-041-194/+6
| | | | | | and primitive expansion' llvm-svn: 346096
* [analyzer][PlistMacroExpansion] Part 2.: Retrieving the macro name and ↵Kristof Umann2018-11-041-6/+194
| | | | | | | | | | | primitive expansion This patch adds a couple new functions to acquire the macro's name, and also expands it, although it doesn't expand the arguments, as seen from the test files Differential Revision: https://reviews.llvm.org/D52794 llvm-svn: 346095
* Revert r345562: "PR23833, DR2140: an lvalue-to-rvalue conversion on a ↵Richard Smith2018-11-031-6/+1
| | | | | | | | | | | | glvalue of type" This exposes a (known) CodeGen bug: it can't cope with emitting lvalue expressions that denote non-odr-used but usable-in-constant-expression variables. See PR39528 for a testcase. Reverted for now until that issue can be fixed. llvm-svn: 346065
* [analyzer][NFC] Collect all -analyzer-config options in a .def fileKristof Umann2018-11-022-341/+94
| | | | | | | | | | | | | I'm in the process of refactoring AnalyzerOptions. The main motivation behind here is to emit warnings if an invalid -analyzer-config option is given from the command line, and be able to list them all. In this patch, I'm moving all analyzer options to a def file, and move 2 enums to global namespace. Differential Revision: https://reviews.llvm.org/D53277 llvm-svn: 345986
* [analyzer][NFC] Fix some incorrect uses of -analyzer-config optionsKristof Umann2018-11-022-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | I'm in the process of refactoring AnalyzerOptions. The main motivation behind here is to emit warnings if an invalid -analyzer-config option is given from the command line, and be able to list them all. In this patch, I found some flags that should've been used as checker options, or have absolutely no mention of in AnalyzerOptions, or are nonexistent. - NonLocalizedStringChecker now uses its "AggressiveReport" flag as a checker option - lib/StaticAnalyzer/Frontend/ModelInjector.cpp now accesses the "model-path" option through a getter in AnalyzerOptions - -analyzer-config path-diagnostics-alternate=false is not a thing, I removed it, - lib/StaticAnalyzer/Checkers/AllocationDiagnostics.cpp and lib/StaticAnalyzer/Checkers/AllocationDiagnostics.h are weird, they actually only contain an option getter. I deleted them, and fixed RetainCountChecker to get it's "leak-diagnostics-reference-allocation" option as a checker option, - "region-store-small-struct-limit" has a proper getter now. Differential Revision: https://reviews.llvm.org/D53276 llvm-svn: 345985
* Fix -Wimplicit-fallthrough warning in LLVM_ENABLE_ASSERTIONS=Off buildsFangrui Song2018-11-021-1/+1
| | | | llvm-svn: 345950
* Fix clang -Wimplicit-fallthrough warnings across llvm, NFCReid Kleckner2018-11-015-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch should not introduce any behavior changes. It consists of mostly one of two changes: 1. Replacing fall through comments with the LLVM_FALLTHROUGH macro 2. Inserting 'break' before falling through into a case block consisting of only 'break'. We were already using this warning with GCC, but its warning behaves slightly differently. In this patch, the following differences are relevant: 1. GCC recognizes comments that say "fall through" as annotations, clang doesn't 2. GCC doesn't warn on "case N: foo(); default: break;", clang does 3. GCC doesn't warn when the case contains a switch, but falls through the outer case. I will enable the warning separately in a follow-up patch so that it can be cleanly reverted if necessary. Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu Differential Revision: https://reviews.llvm.org/D53950 llvm-svn: 345882
OpenPOWER on IntegriCloud