summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Frontend
Commit message (Collapse)AuthorAgeFilesLines
* [Analyzer] Fixes -Wrange-loop-analysis warningsMark de Wever2019-12-221-1/+2
| | | | | | This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D71809
* Move ASTRecordReader into its own header; NFC.John McCall2019-12-141-0/+1
| | | | | | | | | | | | | AbstractBasicReader.h has quite a few dependencies already, and that's only likely to increase. Meanwhile, ASTRecordReader is really an implementation detail of the ASTReader that is only used in a small number of places. I've kept it in a public header for the use of projects like Swift that might want to plug in to Clang's serialization framework. I've also moved OMPClauseReader into an implementation file, although it can't be made private because of friendship.
* [ObjC] Make sure that the implicit arguments for direct methods have been setupAlex Lorenz2019-12-061-7/+0
| | | | | | | | | | | | | | | | | | | | This commit sets the Self and Imp declarations for ObjC method declarations, in addition to the definitions. It also fixes a bunch of code in clang that had wrong assumptions about when getSelfDecl() would be set: - CGDebugInfo::getObjCMethodName and AnalysisConsumer::getFunctionName would assume that it was set for method declarations part of a protocol, which they never were, and that self would be a Class type, which it isn't as it is id for a protocol. Also use the Canonical Decl to index the set of Direct methods so that when calls and implementations interleave, the same llvm::Function is used and the same symbol name emitted. Radar-Id: rdar://problem/57661767 Patch by: Pierre Habouzit Differential Revision: https://reviews.llvm.org/D71091
* [analyzer][NFC] Fix inconsistent references to checkers as "checks"Kristof Umann2019-09-122-2/+2
| | | | | | | | | | | | | | Traditionally, clang-tidy uses the term check, and the analyzer uses checker, but in the very early years, this wasn't the case, and code originating from the early 2010's still incorrectly refer to checkers as checks. This patch attempts to hunt down most of these, aiming to refer to checkers as checkers, but preserve references to callback functions (like checkPreCall) as checks. Differential Revision: https://reviews.llvm.org/D67140 llvm-svn: 371760
* [analyzer] NFC: Move PathDiagnostic classes to libAnalysis.Artem Dergachev2019-09-111-1/+1
| | | | | | | | | | | | At this point the PathDiagnostic, PathDiagnosticLocation, PathDiagnosticPiece structures no longer rely on anything specific to Static Analyzer, so we can move them out of it for everybody to use. PathDiagnosticConsumers are still to be handed off. Differential Revision: https://reviews.llvm.org/D67419 llvm-svn: 371661
* [analyzer] Add minimal support for fix-it hints.Artem Dergachev2019-09-061-18/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | Allow attaching fixit hints to Static Analyzer BugReports. Fixits are attached either to the bug report itself or to its notes (path-sensitive event notes or path-insensitive extra notes). Add support for fixits in text output (including the default text output that goes without notes, as long as the fixit "belongs" to the warning). Add support for fixits in the plist output mode. Implement a fixit for the path-insensitive DeadStores checker. Only dead initialization warning is currently covered. Implement a fixit for the path-sensitive VirtualCall checker when the virtual method is not pure virtual (in this case the "fix" is to suppress the warning by qualifying the call). Both fixits are under an off-by-default flag for now, because they require more careful testing. Differential Revision: https://reviews.llvm.org/D65182 llvm-svn: 371257
* Removed some dead code in BugReporter and related filesDmitri Gribenko2019-08-211-3/+3
| | | | | | | | | | Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66473 llvm-svn: 369504
* [analyzer] NFC: Remove the BugTypes set from BugReporter.Artem Dergachev2019-08-201-0/+4
| | | | | | | Its only purpose was to avoid a bug that's caused by making a virtual call in BugReporter's destructor. llvm-svn: 369451
* [analyzer] Analysis: Silence checkersCsaba Dabis2019-08-161-9/+13
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch introduces a new `analyzer-config` configuration: `-analyzer-config silence-checkers` which could be used to silence the given checkers. It accepts a semicolon separated list, packed into quotation marks, e.g: `-analyzer-config silence-checkers="core.DivideZero;core.NullDereference"` It could be used to "disable" core checkers, so they model the analysis as before, just if some of them are too noisy it prevents to emit reports. This patch also adds support for that new option to the scan-build. Passing the option `-disable-checker core.DivideZero` to the scan-build will be transferred to `-analyzer-config silence-checkers=core.DivideZero`. Reviewed By: NoQ, Szelethus Differential Revision: https://reviews.llvm.org/D66042 llvm-svn: 369078
* [analyzer] Warn about -analyzer-configs being meant for development purposes ↵Kristof Umann2019-08-151-5/+16
| | | | | | | | | | | | only This is more of a temporary fix, long term, we should convert AnalyzerOptions.def into the universally beloved (*coughs*) TableGen format, where they can more easily be separated into developer-only, alpha, and user-facing configs. Differential Revision: https://reviews.llvm.org/D66261 llvm-svn: 368980
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-143-8/+8
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
* Move LangStandard*, InputKind::Language to BasicRainer Orth2019-08-051-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is a prerequisite for using LangStandard from Driver in https://reviews.llvm.org/D64793. It moves LangStandard* and InputKind::Language to Basic. It is mostly mechanical, with only a few changes of note: - enum Language has been changed into enum class Language : uint8_t to avoid a clash between OpenCL in enum Language and OpenCL in enum LangFeatures and not to increase the size of class InputKind. - Now that getLangStandardForName, which is currently unused, also checks both canonical and alias names, I've introduced a helper getLangKind which factors out a code pattern already used 3 times. The patch has been tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu. There's a companion patch for lldb which uses LangStandard.h (https://reviews.llvm.org/D65717). While polly includes isl which in turn uses InputKind::C, that part of the code isn't even built inside the llvm tree. I've posted a patch to allow for both InputKind::C and Language::C upstream (https://groups.google.com/forum/#!topic/isl-development/6oEvNWOSQFE). Differential Revision: https://reviews.llvm.org/D65562 llvm-svn: 367864
* [CrossTU] Added CTU argument to diagnostic consumer create fn.Balazs Keri2019-07-231-11/+11
| | | | | | | | | | | | | | | | | | Summary: The PListDiagnosticConsumer needs a new CTU parameter that is passed through the create functions. Reviewers: NoQ, Szelethus, xazax.hun, martong Reviewed By: Szelethus Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64635 llvm-svn: 366782
* [analyzer] Add more timers for performance profiling.Artem Dergachev2019-06-251-9/+34
| | | | | | | | | | | | | The -analyzer-stats flag now allows you to find out how much time was spent on AST-based analysis and on path-sensitive analysis and, separately, on bug visitors, as they're occasionally a performance problem on their own. The total timer wasn't useful because there's anyway a total time printed out. Remove it. Differential Revision: https://reviews.llvm.org/D63227 llvm-svn: 364266
* [analyzer] Add werror flag for analyzer warningsKeno Fischer2019-06-071-4/+13
| | | | | | | | | | | | | | | | | | | | | | | Summary: We're using the clang static analyzer together with a number of custom analyses in our CI system to ensure that certain invariants are statiesfied for by the code every commit. Unfortunately, there currently doesn't seem to be a good way to determine whether any analyzer warnings were emitted, other than parsing clang's output (or using scan-build, which then in turn parses clang's output). As a simpler mechanism, simply add a `-analyzer-werror` flag to CC1 that causes the analyzer to emit its warnings as errors instead. I briefly tried to have this be `Werror=analyzer` and make it go through that machinery instead, but that seemed more trouble than it was worth in terms of conflicting with options to the actual build and special cases that would be required to circumvent the analyzers usual attempts to quiet non-analyzer warnings. This is simple and it works well. Reviewed-By: NoQ, Szelethusw Differential Revision: https://reviews.llvm.org/D62885 llvm-svn: 362855
* [analyzer] List checker/plugin options in 3 categories: released, alpha, ↵Kristof Umann2019-05-231-16/+39
| | | | | | | | | | | | developer Same patch as D62093, but for checker/plugin options, the only difference being that options for alpha checkers are implicitly marked as alpha. Differential Revision: https://reviews.llvm.org/D62093 llvm-svn: 361566
* [analyzer] Hide developer-only checker/package options by defaultKristof Umann2019-05-231-10/+13
| | | | | | | | | These options are now only visible under -analyzer-checker-option-help-developer. Differential Revision: https://reviews.llvm.org/D61839 llvm-svn: 361561
* [analyzer] List checkers in 3 categories: released, alpha, developerKristof Umann2019-05-231-4/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the only way to display the list of available checkers was to invoke the analyzer with -analyzer-checker-help frontend flag. This however wasn't really great from a maintainer standpoint: users came across checkers meant strictly for development purposes that weren't to be tinkered with, or those that were still in development. This patch creates a clearer division in between these categories. From now on, we'll have 3 flags to display the list checkers. These lists are mutually exclusive and can be used in any combination (for example to display both stable and alpha checkers). -analyzer-checker-help: Displays the list for stable, production ready checkers. -analyzer-checker-help-alpha: Displays the list for in development checkers. Enabling is discouraged for non-development purposes. -analyzer-checker-help-developer: Modeling and debug checkers. Modeling checkers shouldn't be enabled/disabled by hand, and debug checkers shouldn't be touched by users. Differential Revision: https://reviews.llvm.org/D62093 llvm-svn: 361558
* [analyzer] Add a new frontend flag to display all checker optionsKristof Umann2019-05-232-46/+56
| | | | | | | | | Add the new frontend flag -analyzer-checker-option-help to display all checker/package options. Differential Revision: https://reviews.llvm.org/D57858 llvm-svn: 361552
* [analyzer] Remove the default value arg from getChecker*OptionKristof Umann2019-05-171-1/+7
| | | | | | | | | | | | | | | | | | | Since D57922, the config table contains every checker option, and it's default value, so having it as an argument for getChecker*Option is redundant. By the time any of the getChecker*Option function is called, we verified the value in CheckerRegistry (after D57860), so we can confidently assert here, as any irregularities detected at this point must be a programmer error. However, in compatibility mode, verification won't happen, so the default value must be restored. This implies something else, other than adding removing one more potential point of failure -- debug.ConfigDumper will always contain valid values for checker/package options! Differential Revision: https://reviews.llvm.org/D59195 llvm-svn: 361042
* [analyzer] Validate checker option names and valuesKristof Umann2019-05-171-18/+101
| | | | | | | | | | Validate whether the option exists, and also whether the supplied value is of the correct type. With this patch, invoking the analyzer should be, at least in the frontend mode, a lot safer. Differential Revision: https://reviews.llvm.org/D57860 llvm-svn: 361011
* [analyzer] Insert checker options into AnalyzerOption::ConfigTableKristof Umann2019-05-171-4/+8
| | | | | | | | | | | | | The more entries we have in AnalyzerOptions::ConfigTable, the more helpful debug.ConfigDumper is. With this patch, I'm pretty confident that it'll now emit the entire state of the analyzer, minus the frontend flags. It would be nice to reserve the config table specifically to checker options only, as storing the regular analyzer configs is kinda redundant. Differential Revision: https://reviews.llvm.org/D57922 llvm-svn: 361006
* [analyzer] Don't display implementation checkers under ↵Kristof Umann2019-05-011-4/+8
| | | | | | | | | | | | | | | | | | | | | | | -analyzer-checker-help, but do under the new flag -analyzer-checker-help-hidden During my work on analyzer dependencies, I created a great amount of new checkers that emitted no diagnostics at all, and were purely modeling some function or another. However, the user shouldn't really disable/enable these by hand, hence this patch, which hides these by default. I intentionally chose not to hide alpha checkers, because they have a scary enough name, in my opinion, to cause no surprise when they emit false positives or cause crashes. The patch introduces the Hidden bit into the TableGen files (you may remember it before I removed it in D53995), and checkers that are either marked as hidden, or are in a package that is marked hidden won't be displayed under -analyzer-checker-help. -analyzer-checker-help-hidden, a new flag meant for developers only, displays the full list. Differential Revision: https://reviews.llvm.org/D60925 llvm-svn: 359720
* [analyzer][CrossTU] Extend CTU to VarDecls with initializerRafael Stahl2019-04-231-0/+29
| | | | | | | | | | | | | | | | | | | | | | Summary: The existing CTU mechanism imports `FunctionDecl`s where the definition is available in another TU. This patch extends that to VarDecls, to bind more constants. - Add VarDecl importing functionality to CrossTranslationUnitContext - Import Decls while traversing them in AnalysisConsumer - Add VarDecls to CTU external mappings generator - Name changes from "external function map" to "external definition map" Reviewers: NoQ, dcoughlin, xazax.hun, george.karpenkov, martong Reviewed By: xazax.hun Subscribers: Charusso, baloghadamsoftware, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, george.karpenkov, mgorny, whisperity, szepet, rnkovacs, a.sidorin, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D46421 llvm-svn: 358968
* [analyzer][NFC] Reimplement checker optionsKristof Umann2019-04-191-14/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TL;DR: * Add checker and package options to the TableGen files * Added a new class called CmdLineOption, and both Package and Checker recieved a list<CmdLineOption> field. * Added every existing checker and package option to Checkers.td. * The CheckerRegistry class * Received some comments to most of it's inline classes * Received the CmdLineOption and PackageInfo inline classes, a list of CmdLineOption was added to CheckerInfo and PackageInfo * Added addCheckerOption and addPackageOption * Added a new field called Packages, used in addPackageOptions, filled up in addPackage Detailed description: In the last couple months, a lot of effort was put into tightening the analyzer's command line interface. The main issue is that it's spectacularly easy to mess up a lenghty enough invocation of the analyzer, and the user was given no warnings or errors at all in that case. We can divide the effort of resolving this into several chapters: * Non-checker analyzer configurations: Gather every analyzer configuration into a dedicated file. Emit errors for non-existent configurations or incorrect values. Be able to list these configurations. Tighten AnalyzerOptions interface to disallow making such a mistake in the future. * Fix the "Checker Naming Bug" by reimplementing checker dependencies: When cplusplus.InnerPointer was enabled, it implicitly registered unix.Malloc, which implicitly registered some sort of a modeling checker from the CStringChecker family. This resulted in all of these checker objects recieving the name "cplusplus.InnerPointer", making AnalyzerOptions asking for the wrong checker options from the command line: cplusplus.InnerPointer:Optimisic istead of unix.Malloc:Optimistic. This was resolved by making CheckerRegistry responsible for checker dependency handling, instead of checkers themselves. * Checker options: (this patch included!) Same as the first item, but for checkers. (+ minor fixes here and there, and everything else that is yet to come) There were several issues regarding checker options, that non-checker configurations didn't suffer from: checker plugins are loaded runtime, and they could add new checkers and new options, meaning that unlike for non-checker configurations, we can't collect every checker option purely by generating code. Also, as seen from the "Checker Naming Bug" issue raised above, they are very rarely used in practice, and all sorts of skeletons fell out of the closet while working on this project. They were extremely problematic for users as well, purely because of how long they were. Consider the following monster of a checker option: alpha.cplusplus.UninitializedObject:CheckPointeeInitialization=false While we were able to verify whether the checker itself (the part before the colon) existed, any errors past that point were unreported, easily resulting in 7+ hours of analyses going to waste. This patch, similarly to how dependencies were reimplemented, uses TableGen to register checker options into Checkers.td, so that Checkers.inc now contains entries for both checker and package options. Using the preprocessor, Checkers.inc is converted into code in CheckerRegistry, adding every builtin (checkers and packages that have an entry in the Checkers.td file) checker and package option to the registry. The new addPackageOption and addCheckerOption functions expose the same functionality to statically-linked non-builtin and plugin checkers and packages as well. Emitting errors for incorrect user input, being able to list these options, and some other functionalies will land in later patches. Differential Revision: https://reviews.llvm.org/D57855 llvm-svn: 358752
* [analyzer] Fix an assertion failure if plugins added dependenciesKristof Umann2019-04-191-10/+20
| | | | | | | | | | | | | | | | | | | Ideally, there is no reason behind not being able to depend on checkers that come from a different plugin (or on builtin checkers) -- however, this is only possible if all checkers are added to the registry before resolving checker dependencies. Since I used a binary search in my addDependency method, this also resulted in an assertion failure (due to CheckerRegistry::Checkers not being sorted), since the function used by plugins to register their checkers (clang_registerCheckers) calls addDependency. This patch resolves this issue by only noting which dependencies have to established when addDependency is called, and resolves them at a later stage when no more checkers are added to the registry, by which point CheckerRegistry::Checkers is already sorted. Differential Revision: https://reviews.llvm.org/D59461 llvm-svn: 358750
* [analyzer] Fix -Wunused-local-typedef after rC358695Fangrui Song2019-04-191-5/+2
| | | | llvm-svn: 358729
* [analyzer][NFC] Prefer binary searches in CheckerRegistryKristof Umann2019-04-181-22/+29
| | | | | | Differential Revision: https://reviews.llvm.org/D59459 llvm-svn: 358695
* [analyzer][NFC] Clang-format CheckerRegistryKristof Umann2019-04-181-39/+37
| | | | | | Differential Revision: https://reviews.llvm.org/D59458 llvm-svn: 358694
* [analyzer][NFC] Use capital variable names, move methods out-of-line, rename ↵Kristof Umann2019-04-182-117/+149
| | | | | | | | | | | | some in CheckerRegistry There are barely any lines I haven't changed in these files, so I think I could might as well leave it in an LLVM coding style conforming state. I also renamed 2 functions and moved addDependency out of line to ease on followup patches. Differential Revision: https://reviews.llvm.org/D59457 llvm-svn: 358676
* Frontend: Remove CompilerInstance::VirtualFileSystem, NFCDuncan P. N. Exon Smith2019-03-261-2/+0
| | | | | | | | | | | | | | | Remove CompilerInstance::VirtualFileSystem and CompilerInstance::setVirtualFileSystem, instead relying on the VFS in the FileManager. CompilerInstance and its clients already went to some trouble to make these match. Now they are guaranteed to match. As part of this, I added a VFS parameter (defaults to nullptr) to CompilerInstance::createFileManager, to avoid repeating construction logic in clients that just wanted to customize the VFS. https://reviews.llvm.org/D59377 llvm-svn: 357037
* [analyzer] Reimplement dependencies between checkersKristof Umann2019-01-261-3/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately, up until now, the fact that certain checkers depended on one another was known, but how these actually unfolded was hidden deep within the implementation. For example, many checkers (like RetainCount, Malloc or CString) modelled a certain functionality, and exposed certain reportable bug types to the user. For example, while MallocChecker models many many different types of memory handling, the actual "unix.MallocChecker" checker the user was exposed to was merely and option to this modeling part. Other than this being an ugly mess, this issue made resolving the checker naming issue almost impossible. (The checker naming issue being that if a checker registered more than one checker within its registry function, both checker object recieved the same name) Also, if the user explicitly disabled a checker that was a dependency of another that _was_ explicitly enabled, it implicitly, without "telling" the user, reenabled it. Clearly, changing this to a well structured, declarative form, where the handling of dependencies are done on a higher level is very much preferred. This patch, among the detailed things later, makes checkers declare their dependencies within the TableGen file Checkers.td, and exposes the same functionality to plugins and statically linked non-generated checkers through CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies, makes sure that checkers are added to CheckerManager in the correct order, and makes sure that if a dependency is disabled, so will be every checker that depends on it. In detail: * Add a new field to the Checker class in CheckerBase.td called Dependencies, which is a list of Checkers. * Move unix checkers before cplusplus, as there is no forward declaration in tblgen :/ * Add the following new checkers: - StackAddrEscapeBase - StackAddrEscapeBase - CStringModeling - DynamicMemoryModeling (base of the MallocChecker family) - IteratorModeling (base of the IteratorChecker family) - ValistBase - SecuritySyntaxChecker (base of bcmp, bcopy, etc...) - NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker) - IvarInvalidationModeling (base of IvarInvalidation checker family) - RetainCountBase (base of RetainCount and OSObjectRetainCount) * Clear up and registry functions in MallocChecker, happily remove old FIXMEs. * Add a new addDependency function to CheckerRegistry. * Neatly format RUN lines in files I looked at while debugging. Big thanks to Artem Degrachev for all the guidance through this project! Differential Revision: https://reviews.llvm.org/D54438 llvm-svn: 352287
* [analyzer] Fix an bug where statically linked, but not registered checkers ↵Kristof Umann2019-01-262-8/+14
| | | | | | | | | | | | | | weren't recognized My last patch, D56989, moved the validation of whether a checker exists into its constructor, but we do support statically linked (and non-plugin) checkers that were do not have an entry in Checkers.td. However, the handling of this happens after the creation of the CheckerRegistry object. This patch fixes this bug by moving even this functionality into CheckerRegistry's constructor. llvm-svn: 352284
* [analyzer][NFC] Keep track of whether enabling a checker was explictly ↵Kristof Umann2019-01-261-67/+77
| | | | | | | | | | | | | | | specified in command line arguments I added a new enum to CheckerInfo, so we can easily track whether the check is explicitly enabled, explicitly disabled, or isn't specified in this regard. Checkers belonging in the latter category may be implicitly enabled through dependencies in the followup patch. I also made sure that this is done within CheckerRegisty's constructor, leading to very significant simplifications in its query-like methods. Differential Revision: https://reviews.llvm.org/D56989 llvm-svn: 352282
* [analyzer][NFC] Supply CheckerRegistry with AnalyzerOptionsKristof Umann2019-01-262-19/+17
| | | | | | | | | Since pretty much all methods of CheckerRegistry has AnalyzerOptions as an argument, it makes sense to just simply require it in it's constructor. Differential Revision: https://reviews.llvm.org/D56988 llvm-svn: 352279
* [analyzer] Supply all checkers with a shouldRegister functionKristof Umann2019-01-262-13/+23
| | | | | | | | | | | | | | | | | | Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO) function very similarly to ento::register##CHECKERNAME. This will force every checker to implement this function, but maybe it isn't that bad: I saw a lot of ObjC or C++ specific checkers that should probably not register themselves based on some LangOptions (mine too), but they do anyways. A big benefit of this is that all registry functions now register their checker, once it is called, registration is guaranteed. This patch is a part of a greater effort to reinvent checker registration, more info here: D54438#1315953 Differential Revision: https://reviews.llvm.org/D55424 llvm-svn: 352277
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-197-28/+21
| | | | | | | | | | | | | | | | | 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
* Allow direct navigation to static analysis checker documentation through ↵Aaron Ballman2018-12-201-7/+7
| | | | | | | | SARIF exports. This adds anchors to all of the documented checks so that you can directly link to a check by a stable name. This is useful because the SARIF file format has a field for specifying a URI to documentation for a rule and some viewers, like CodeSonar, make use of this information. These links are then exposed through the SARIF exporter. llvm-svn: 349812
* [analyzer][NFC] Merge ClangCheckerRegistry to CheckerRegistryKristof Umann2018-12-152-99/+74
| | | | | | | | | | | Now that CheckerRegistry lies in Frontend, we can finally eliminate ClangCheckerRegistry. Fortunately, this also provides us with a DiagnosticsEngine, so I went ahead and removed some parameters from it's methods. Differential Revision: https://reviews.llvm.org/D54437 llvm-svn: 349280
* [analyzer][NFC] Move CheckerRegistry from the Core directory to FrontendKristof Umann2018-12-153-3/+202
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ClangCheckerRegistry is a very non-obvious, poorly documented, weird concept. It derives from CheckerRegistry, and is placed in lib/StaticAnalyzer/Frontend, whereas it's base is located in lib/StaticAnalyzer/Core. It was, from what I can imagine, used to circumvent the problem that the registry functions of the checkers are located in the clangStaticAnalyzerCheckers library, but that library depends on clangStaticAnalyzerCore. However, clangStaticAnalyzerFrontend depends on both of those libraries. One can make the observation however, that CheckerRegistry has no place in Core, it isn't used there at all! The only place where it is used is Frontend, which is where it ultimately belongs. This move implies that since include/clang/StaticAnalyzer/Checkers/ClangCheckers.h only contained a single function: class CheckerRegistry; void registerBuiltinCheckers(CheckerRegistry &registry); it had to re purposed, as CheckerRegistry is no longer available to clangStaticAnalyzerCheckers. It was renamed to BuiltinCheckerRegistration.h, which actually describes it a lot better -- it does not contain the registration functions for checkers, but only those generated by the tblgen files. Differential Revision: https://reviews.llvm.org/D54436 llvm-svn: 349275
* [analyzer] Prefer returns values to out-params in CheckerRegistry.cppKristof Umann2018-12-151-2/+3
| | | | | | | | | | | | | | | Renaming collectCheckers to getEnabledCheckers Changing the functionality to acquire all enabled checkers, rather then collect checkers for a specific CheckerOptInfo (for example, collecting all checkers for { "core", true }, which meant enabling all checkers from the core package, which was an unnecessary complication). Removing CheckerOptInfo, instead of storing whether the option was claimed via a field, we handle errors immediately, as getEnabledCheckers can now access a DiagnosticsEngine. Realize that the remaining information it stored is directly accessible through AnalyzerOptions.CheckerControlList. Fix a test with -analyzer-disable-checker -verify accidentally left in. llvm-svn: 349274
* [analyzer] Evaluate all non-checker config options before analysisKristof Umann2018-11-302-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [analyzer][NFC] Move CheckerOptInfo to CheckerRegistry.cpp, and make it localKristof Umann2018-11-181-25/+2
| | | | | | | | | 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
* Attempt to fix 'logical operation on address of string constant'Kristof Umann2018-11-021-2/+4
| | | | | | | Caused a lot of warnings for Windows: http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/21178/steps/build/logs/warnings%20%2867%29 llvm-svn: 346033
* [analyzer] New flag to print all -analyzer-config optionsKristof Umann2018-11-021-0/+72
| | | | | | | | A new -cc1 flag is avaible for the said purpose: -analyzer-config-help Differential Revision: https://reviews.llvm.org/D53296 llvm-svn: 345989
* [analyzer][NFC] Fix some incorrect uses of -analyzer-config optionsKristof Umann2018-11-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [analyzer] [NFC] Remove unused parameters, as found by -Wunused-parameterGeorge Karpenkov2018-09-281-28/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D52640 llvm-svn: 343353
* [analyzer] Provide an option to dump generated exploded graphs to a given file.George Karpenkov2018-09-281-0/+3
| | | | | | | | | | | Dumping graphs instead of opening them is often very useful, e.g. for transfer or converting to SVG. Basic sanity check for generated exploded graphs. Differential Revision: https://reviews.llvm.org/D52637 llvm-svn: 343352
* [analyzer] Remove traces of ubigraph visualizationGeorge Karpenkov2018-09-061-108/+0
| | | | | | | | | | Ubigraph project has been dead since about 2008, and to the best of my knowledge, no one was using it. Previously, I wasn't able to launch the existing binary at all. Differential Revision: https://reviews.llvm.org/D51655 llvm-svn: 341601
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-1/+1
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
OpenPOWER on IntegriCloud