summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Frontend/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer][NFC] Move CheckerRegistry from the Core directory to FrontendKristof Umann2018-12-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Sort source lists in lib/StaticAnalyzer.Nico Weber2018-04-071-1/+1
| | | | llvm-svn: 329481
* Resubmit [analyzer] Support for naive cross translation unit analysisIlya Biryukov2018-03-011-0/+1
| | | | | | | | | | | 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-011-1/+0
| | | | | | | | | | 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] Support for naive cross translation unit analysisGabor Horvath2018-02-281-0/+1
| | | | | | | | | | | | | | | | | | 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
* [CMake] clangStaticAnalyzerFrontend: Add clangLex, corresponding to r216550.NAKAMURA Takumi2014-08-281-0/+1
| | | | llvm-svn: 216664
* Add support for the static analyzer to synthesize function implementations ↵Ted Kremenek2014-08-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CMake] Use LINK_LIBS instead of target_link_libraries().NAKAMURA Takumi2014-02-261-2/+1
| | | | llvm-svn: 202238
* [CMake] Get rid of explicit dependencies to include/clang/*.inc and ↵NAKAMURA Takumi2014-02-211-10/+0
| | | | | | | | | | | | | | | | | | | introduce CLANG_TABLEGEN_TARGETS. This does; - clang_tablegen() adds each tblgen'd target to global property CLANG_TABLEGEN_TARGETS as list. - List of targets is added to LLVM_COMMON_DEPENDS. - all clang libraries and targets depend on generated headers. You might wonder this would be regression, but in fact, this is little loss. - Almost all of clang libraries depend on tblgen'd files and clang-tblgen. - clang-tblgen may cause short stall-out but doesn't cause unconditional rebuild. - Each library's dependencies to tblgen'd files might vary along headers' structure. It made hard to track and update *really optimal* dependencies. Each dependency to intrinsics_gen and ClangSACheckers is left as DEPENDS. llvm-svn: 201842
* [CMake] Prune stray entries in add_dependencies(). target_link_libraries() ↵NAKAMURA Takumi2014-01-311-2/+0
| | | | | | implies it. llvm-svn: 200531
* [CMake] clangStaticAnalyzerFrontend: Deprecate LLVM_NO_RTTI.NAKAMURA Takumi2014-01-281-2/+0
| | | | llvm-svn: 200296
* [CMake] clang/lib: Prune redundant dependencies.NAKAMURA Takumi2013-12-101-3/+0
| | | | llvm-svn: 196864
* [CMake] clang/lib: Satisfy dependencies to add *actually used* libraries on ↵NAKAMURA Takumi2013-12-091-2/+8
| | | | | | | | target_link_libraries() and LLVM_LINK_COMPONENTS. I will prune redundant dependencies later. llvm-svn: 196800
* Split library clangRewrite into clangRewriteCore and clangRewriteFrontend.Ted Kremenek2012-09-011-1/+2
| | | | | | | This is similar to how we divide up the StaticAnalyzer libraries to separate core functionality to what is clearly associated with Frontend actions. llvm-svn: 163050
* clang/lib: [CMake] Update tblgen'd dependencies.NAKAMURA Takumi2012-07-271-0/+2
| | | | llvm-svn: 160851
* Implement AST classes for comments, a real parser for Doxygen comments and aDmitri Gribenko2012-07-061-0/+1
| | | | | | | | | | | | | | very simple semantic analysis that just builds the AST; minor changes for lexer to pick up source locations I didn't think about before. Comments AST is modelled along the ideas of HTML AST: block and inline content. * Block content is a paragraph or a command that has a paragraph as an argument or verbatim command. * Inline content is placed within some block. Inline content includes plain text, inline commands and HTML as tag soup. llvm-svn: 159790
* Remove a goofy CMake hack and use the standard CMake facilities toChandler Carruth2012-06-211-3/+9
| | | | | | | | | express library-level dependencies within Clang. This is no more verbose really, and plays nicer with the rest of the CMake facilities. It should also have no change in functionality. llvm-svn: 158888
* Fix cmake build with -DBUILD_SHARED_LIBS=ON.Rafael Espindola2011-12-291-1/+2
| | | | llvm-svn: 147338
* Correct name of dependent target.Oscar Fuentes2011-02-201-1/+1
| | | | | | | CMake complained about this while generating VS project files but was okay with it while generating makefiles on Linux. llvm-svn: 126090
* Fix some add_dependencies.Oscar Fuentes2011-02-191-2/+8
| | | | | | The syntax is (add_dependencies target-name depend-target1 ...). llvm-svn: 126049
* When building StaticAnalyzer/Frontend add -I "<Checkers build dir>" to allow ↵Argyrios Kyrtzidis2011-02-171-0/+2
| | | | | | | | | | Checkers.inc to be included without '..', thus being compatible with build systems of *BSDs. Patch by Joerg Sonnenberger! llvm-svn: 125758
* [analyzer] Overhauling of the checker registration mechanism.Argyrios Kyrtzidis2011-02-141-0/+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 Checkers/FrontendActions.cpp -> Frontend/FrontendActions.cppArgyrios Kyrtzidis2011-02-141-0/+1
| | | | llvm-svn: 125500
* [analyzer] Introduce libclangStaticAnalyzerFrontend and move ↵Argyrios Kyrtzidis2011-02-141-0/+10
Checkers/AnalysisConsumer.cpp into Frontend lib. llvm-svn: 125499
OpenPOWER on IntegriCloud