summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Frontend/FrontendActions.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-1/+1
| | | | | | | | | | 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
* 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
* Add support for the static analyzer to synthesize function implementations ↵Ted Kremenek2014-08-271-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | from external model files. Currently the analyzer lazily models some functions using 'BodyFarm', which constructs a fake function implementation that the analyzer can simulate that approximates the semantics of the function when it is called. BodyFarm does this by constructing the AST for such definitions on-the-fly. One strength of BodyFarm is that all symbols and types referenced by synthesized function bodies are contextual adapted to the containing translation unit. The downside is that these ASTs are hardcoded in Clang's own source code. A more scalable model is to allow these models to be defined as source code in separate "model" files and have the analyzer use those definitions lazily when a function body is needed. Among other things, it will allow more customization of the analyzer for specific APIs and platforms. This patch provides the initial infrastructure for this feature. It extends BodyFarm to use an abstract API 'CodeInjector' that can be used to synthesize function bodies. That 'CodeInjector' is implemented using a new 'ModelInjector' in libFrontend, which lazily parses a model file and injects the ASTs into the current translation unit. Models are currently found by specifying a 'model-path' as an analyzer option; if no path is specified the CodeInjector is not used, thus defaulting to the current behavior in the analyzer. Models currently contain a single function definition, and can be found by finding the file <function name>.model. This is an initial starting point for something more rich, but it bootstraps this feature for future evolution. This patch was contributed by Gábor Horváth as part of his Google Summer of Code project. Some notes: - This introduces the notion of a "model file" into FrontendAction and the Preprocessor. This nomenclature is specific to the static analyzer, but possibly could be generalized. Essentially these are sources pulled in exogenously from the principal translation. Preprocessor gets a 'InitializeForModelFile' and 'FinalizeForModelFile' which could possibly be hoisted out of Preprocessor if Preprocessor exposed a new API to change the PragmaHandlers and some other internal pieces. This can be revisited. FrontendAction gets a 'isModelParsingAction()' predicate function used to allow a new FrontendAction to recycle the Preprocessor and ASTContext. This name could probably be made something more general (i.e., not tied to 'model files') at the expense of losing the intent of why it exists. This can be revisited. - This is a moderate sized patch; it has gone through some amount of offline code review. Most of the changes to the non-analyzer parts are fairly small, and would make little sense without the analyzer changes. - Most of the analyzer changes are plumbing, with the interesting behavior being introduced by ModelInjector.cpp and ModelConsumer.cpp. - The new functionality introduced by this change is off-by-default. It requires an analyzer config option to enable. llvm-svn: 216550
* Recommit 213307: unique_ptr-ify ownership of ASTConsumers (reverted in r213325)David Blaikie2014-08-101-2/+2
| | | | | | | | After post-commit review and community discussion, this seems like a reasonable direction to continue, making ownership semantics explicit in the source using the type system. llvm-svn: 215323
* Revert "unique_ptr-ify ownership of ASTConsumers"David Blaikie2014-07-171-2/+2
| | | | | | | | | This reverts commit r213307. Reverting to have some on-list discussion/confirmation about the ongoing direction of smart pointer usage in the LLVM project. llvm-svn: 213325
* unique_ptr-ify ownership of ASTConsumersDavid Blaikie2014-07-171-2/+2
| | | | | | | | | (after fixing a bug in MultiplexConsumer I noticed the ownership of the nested consumers was implemented with raw pointers - so this fixes that... and follows the source back to its origin pushing unique_ptr ownership up through there too) llvm-svn: 213307
* Make clang::ento::CreateAnalysisConsumer a part of a public interface of the ↵Alexander Kornienko2014-01-031-1/+1
| | | | | | | | | | | | | | | | | | static analyzer. Summary: This allows for a better alternative to the FrontendAction hack used in clang-tidy in order to get static analyzer's ASTConsumer. Reviewers: jordan_rose, krememek Reviewed By: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2505 llvm-svn: 198426
* Sort all of Clang's files under 'lib', and fix up the broken headersChandler Carruth2012-12-041-1/+1
| | | | | | | | | | | | | uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
* [analyzer] Overhaul of checker registration in preparation for basic plugin ↵Jordy Rose2011-08-161-1/+2
| | | | | | support. Removes support for checker groups (we can add them back in later if we decide they are still useful), and -analyzer-checker-help output is a little worse for the time being (no packages). llvm-svn: 137758
* remove unneeded llvm:: namespace qualifiers on some core types now that ↵Chris Lattner2011-07-231-1/+1
| | | | | | | | LLVM.h imports them into the clang namespace. llvm-svn: 135852
* [analyzer] Overhauling of the checker registration mechanism.Argyrios Kyrtzidis2011-02-141-1/+1
| | | | | | | | | | | | | | -Checkers will be defined in the tablegen file 'Checkers.td'. -Apart from checkers, we can define checker "packages" that will contain a collection of checkers. -Checkers can be enabled with -analyzer-checker=<name> and disabled with -analyzer-disable-checker=<name> e.g: Enable checkers from 'cocoa' and 'corefoundation' packages except the self-initialization checker: -analyzer-checker=cocoa -analyzer-checker=corefoundation -analyzer-disable-checker=cocoa.SelfInit -Introduces CheckerManager and CheckerProvider. CheckerProviders get the set of checker names to enable/disable and register them with the CheckerManager which will be the entry point for all checker-related functionality. Currently only the self-initialization checker takes advantage of the new mechanism. llvm-svn: 125503
* [analyzer] Move include/clang/StaticAnalyzer/AnalysisConsumer.h -> ↵Argyrios Kyrtzidis2011-02-141-1/+1
| | | | | | | | lib/StaticAnalyzer/Frontend/AnalysisConsumer.h since FrontendActions.cpp is the only user. llvm-svn: 125501
* [analyzer] Move Checkers/FrontendActions.cpp -> Frontend/FrontendActions.cppArgyrios Kyrtzidis2011-02-141-0/+22
llvm-svn: 125500
OpenPOWER on IntegriCloud