summaryrefslogtreecommitdiffstats
path: root/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer] Don't run the analyzer for -analyzer-list-enabled-checkersKristof Umann2019-09-121-0/+1
| | | | | | | | | Short and sweet. Whenever I use -analyzer-list-enabled-checkers, I'm only interested about the configuration, not about the analysis. Differential Revision: https://reviews.llvm.org/D66714 llvm-svn: 371756
* [Driver] Use shared singleton instance of DriverOptTableIlya Biryukov2019-09-041-5/+5
| | | | | | | | | | | | | | | | | | | | | Summary: This significantly reduces the time required to run clangd tests, by ~10%. Should also have an effect on other tests that run command-line parsing multiple times inside a single invocation. Reviewers: gribozavr, sammccall Reviewed By: sammccall Subscribers: kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67163 llvm-svn: 370908
* [clang][ifs] Dropping older experimental interface stub formats.Puyan Lotfi2019-08-221-4/+0
| | | | | | | | | | | | I've been working on a new tool, llvm-ifs, for merging interface stub files generated by clang and I've iterated on my derivative format of TBE to a newer format. llvm-ifs will only support the new format, so I am going to drop the older experimental interface stubs formats in this commit to make things simpler. Differential Revision: https://reviews.llvm.org/D66573 llvm-svn: 369719
* [clang][ifs] New interface stubs format (llvm triple based).Puyan Lotfi2019-08-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | After posting llvm-ifs on phabricator, I made some progress in hardening up how I think the format for Interface Stubs should look. There are a number of things I think the TBE format was missing (no endianness, no info about the Object Format because it assumes ELF), so I have added those and broken off from being as similar to the TBE schema. In a subsequent commit I can drop the other formats. An example of how The format will look is as follows: --- !experimental-ifs-v1 IfsVersion: 1.0 Triple: x86_64-unknown-linux-gnu ObjectFileFormat: ELF Symbols: _Z9nothiddenv: { Type: Func } _Z10cmdVisiblev: { Type: Func } ... The format is still marked experimental. Differential Revision: https://reviews.llvm.org/D66446 llvm-svn: 369715
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-43/+43
| | | | | | | | | | 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
* [clang-ifs] Clang Interface Stubs, first version (second landing attempt).Puyan Lotfi2019-06-201-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change reverts r363649; effectively re-landing r363626. At this point clang::Index::CodegenNameGeneratorImpl has been refactored into clang::AST::ASTNameGenerator. This makes it so that the previous circular link dependency no longer exists, fixing the previous share lib (-DBUILD_SHARED_LIBS=ON) build issue which was the reason for r363649. Clang interface stubs (previously referred to as clang-ifsos) is a new frontend action in clang that allows the generation of stub files that contain mangled name info that can be used to produce a stub library. These stub libraries can be useful for breaking up build dependencies and controlling access to a library's internal symbols. Generation of these stubs can be invoked by: clang -fvisibility=<visibility> -emit-interface-stubs \ -interface-stub-version=<interface format> Notice that -fvisibility (along with use of visibility attributes) can be used to control what symbols get generated. Currently the interface format is experimental but there are a wide range of possibilities here. Currently clang-ifs produces .ifs files that can be thought of as analogous to object (.o) files, but just for the mangled symbol info. In a subsequent patch I intend to add support for merging the .ifs files into one .ifs/.ifso file that can be the input to something like llvm-elfabi to produce something like a .so file or .dll (but without any of the code, just symbols). Differential Revision: https://reviews.llvm.org/D60974 llvm-svn: 363948
* Revert D60974 "[clang-ifs] Clang Interface Stubs, first version."Fangrui Song2019-06-181-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit rC363626. clangIndex depends on clangFrontend. r363626 adds a dependency from clangFrontend to clangIndex, which creates a circular dependency. This is disallowed by -DBUILD_SHARED_LIBS=on builds: CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle): "clangFrontend" of type SHARED_LIBRARY depends on "clangIndex" (weak) "clangIndex" of type SHARED_LIBRARY depends on "clangFrontend" (weak) At least one of these targets is not a STATIC_LIBRARY. Cyclic dependencies are allowed only among static libraries. Note, the dependency on clangIndex cannot be removed because libclangFrontend.so is linked with -Wl,-z,defs: a shared object must have its full direct dependencies specified on the linker command line. In -DBUILD_SHARED_LIBS=off builds, this appears to work when linking `bin/clang-9`. However, it can cause trouble to downstream clang library users. The llvm build system links libraries this way: clang main_program_object_file ... lib/libclangIndex.a ... lib/libclangFrontend.a -o exe libclangIndex.a etc are not wrapped in --start-group. If the downstream application depends on libclangFrontend.a but not any other clang libraries that depend on libclangIndex.a, this can cause undefined reference errors when the linker is ld.bfd or gold. The proper fix is to not include clangIndex files in clangFrontend. llvm-svn: 363649
* [clang-ifs] Clang Interface Stubs, first version.Puyan Lotfi2019-06-171-0/+4
| | | | | | | | | | | | | | | | | | | Clang interface stubs (previously referred to as clang-ifsos) is a new frontend action in clang that allows the generation of stub files that contain mangled name info that can be used to produce a stub library. These stub libraries can be useful for breaking up build dependencies and controlling access to a library's internal symbols. Generation of these stubs can be invoked by: clang -fvisibility=<visibility> -emit-interface-stubs \ -interface-stub-version=<interface format> Notice that -fvisibility (along with use of visibility attributes) can be used to control what symbols get generated. Currently the interface format is experimental but there are a wide range of possibilities here. Differential Revision: https://reviews.llvm.org/D60974 llvm-svn: 363626
* Add clang source minimizer that reduces source to directivesAlex Lorenz2019-06-031-0/+2
| | | | | | | | | | | | | | | | | | | | | that might affect the dependency list for a compilation This commit introduces a dependency directives source minimizer to clang that minimizes header and source files to the minimum necessary preprocessor directives for evaluating includes. It reduces the source down to #define, #include, The source minimizer works by lexing the input with a custom fast lexer that recognizes the preprocessor directives it cares about, and emitting those directives in the minimized source. It ignores source code, comments, and normalizes whitespace. It gives up and fails if seems any directives that it doesn't recognize as valid (e.g. #define 0). In addition to the source minimizer this patch adds a -print-dependency-directives-minimized-source CC1 option that allows you to invoke the minimizer from clang directly. Differential Revision: https://reviews.llvm.org/D55463 llvm-svn: 362459
* [analyzer] List checker/plugin options in 3 categories: released, alpha, ↵Kristof Umann2019-05-231-1/+2
| | | | | | | | | | | | 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-1/+1
| | | | | | | | | 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-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-231-0/+10
| | | | | | | | | 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] Don't display implementation checkers under ↵Kristof Umann2019-05-011-7/+9
| | | | | | | | | | | | | | | | | | | | | | | -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][NFC] Supply CheckerRegistry with AnalyzerOptionsKristof Umann2019-01-261-2/+5
| | | | | | | | | 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-261-2/+3
| | | | | | | | | | | | | | | | | | 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-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
* [analyzer][NFC] Merge ClangCheckerRegistry to CheckerRegistryKristof Umann2018-12-151-1/+2
| | | | | | | | | | | 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] Prefer returns values to out-params in CheckerRegistry.cppKristof Umann2018-12-151-1/+2
| | | | | | | | | | | | | | | 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
* PTH-- Remove feature entirely-Erich Keane2018-12-041-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When debugging a boost build with a modified version of Clang, I discovered that the PTH implementation stores TokenKind in 8 bits. However, we currently have 368 TokenKinds. The result is that the value gets truncated and the wrong token gets picked up when including PTH files. It seems that this will go wrong every time someone uses a token that uses the 9th bit. Upon asking on IRC, it was brought up that this was a highly experimental features that was considered a failure. I discovered via googling that BoostBuild (mostly Boost.Math) is the only user of this feature, using the CC1 flag directly. I believe that this can be transferred over to normal PCH with minimal effort: https://github.com/boostorg/build/issues/367 Based on advice on IRC and research showing that this is a nearly completely unused feature, this patch removes it entirely. Note: I considered leaving the build-flags in place and making them emit an error/warning, however since I've basically identified and warned the only user, it seemed better to just remove them. Differential Revision: https://reviews.llvm.org/D54547 Change-Id: If32744275ef1f585357bd6c1c813d96973c4d8d9 llvm-svn: 348266
* Sink BuryPointer from Clang into LLVM for reuse thereDavid Blaikie2018-11-171-2/+3
| | | | llvm-svn: 347141
* [analyzer] New flag to print all -analyzer-config optionsKristof Umann2018-11-021-0/+8
| | | | | | | | A new -cc1 flag is avaible for the said purpose: -analyzer-config-help Differential Revision: https://reviews.llvm.org/D53296 llvm-svn: 345989
* [Driver][cc1][cc1as] Call OptTable::PrintHelp with explicit " [options] file..."Fangrui Song2018-10-101-1/+1
| | | | | | | | | | | | | | Summary: This is to accommodate a change in llvm/lib/Option/OptTable.cpp D51009 Reviewers: rupprecht, alexshap, jhenderson Reviewed By: rupprecht Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D51109 llvm-svn: 344098
* [Frontend] Delete -print-decl-contextsFangrui Song2018-10-031-1/+0
| | | | | | | | | | | | | | Summary: Its job is covered by -ast-dump. The option is rarely used and lacks many AST nodes which will lead to llvm_unreachable() crash. Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D52529 llvm-svn: 343660
* [modules] Frontend support for building a header module from a list ofRichard Smith2018-09-151-0/+2
| | | | | | headaer files. llvm-svn: 342304
* Remove trailing spaceFangrui Song2018-07-301-2/+2
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* Add a new driver mode to dump compiler feature and extension options.Aaron Ballman2018-05-311-0/+2
| | | | | | Add the ability to dump compiler option-related information to a JSON file via the -compiler-options-dump option. Specifically, it dumps the features/extensions lists -- however, this output could be extended to other information should it be useful. In order to support features and extensions, I moved them into a .def file so that we could build the various lists we care about from them without a significant increase in maintenance burden. llvm-svn: 333653
* Make a build bot happy.Gabor Horvath2018-02-101-1/+1
| | | | llvm-svn: 324809
* [Templight] Template Instantiation ObserverGabor Horvath2018-02-101-2/+7
| | | | | | | | | | | | | | | | | | | | | This patch adds a base-class called TemplateInstantiationObserver which gets notified whenever a template instantiation is entered or exited during semantic analysis. This is a base class used to implement the template profiling and debugging tool called Templight (https://github.com/mikael-s-persson/templight). The patch also makes a few more changes: * ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h). * CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function). * TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers. * Notifications to the template-inst observer are added at the key places where templates are instantiated. Patch by: Abel Sinkovics! Differential Revision: https://reviews.llvm.org/D5767 llvm-svn: 324808
* [CMake] Use #cmakedefine01 for ↵NAKAMURA Takumi2017-10-181-7/+7
| | | | | | | | | | | | CLANG_ENABLE_(ARCMT|OBJC_REWRITER|STATIC_ANALYZER) It'd be better that they are #cmakedefine01 rather than #cmakedefine. (#if FOO rather than #if defined(FOO)) Then we can find missing #include "clang/Config/config.h" in the future. Differential Revision: https://reviews.llvm.org/D35541 llvm-svn: 316061
* Update after LLVM change r309087George Rimar2017-07-261-1/+2
| | | | llvm-svn: 309088
* [CMake] Move CLANG_ENABLE_(ARCMT|OBJC_REWRITER|STATIC_ANALYZER) into ↵NAKAMURA Takumi2017-07-181-0/+1
| | | | | | | | | | | | | | clang/Config/config.h. LLVM_ENABLE_MODULES is sensitive of -D. Move them into config.h. FIXME: It'd be better that they are #cmakedefine01 rather than #cmakedefine. (#if FOO rather than #if defined(FOO)) Then we can find missing #include "clang/Config/config.h" in the future. Differential Revision: https://reviews.llvm.org/D35527 llvm-svn: 308277
* Add -frewrite-imports flag.Richard Smith2017-06-091-1/+2
| | | | | | | | If specified, when preprocessing, the contents of imported .pcm files will be included in preprocessed output. The resulting preprocessed file can then be compiled standalone without the module sources or .pcm files. llvm-svn: 305116
* unique_ptrify createDriverOptTableDavid Blaikie2017-01-131-1/+1
| | | | llvm-svn: 291919
* C++ Modules TS: add frontend support for building pcm files from moduleRichard Smith2016-08-261-1/+4
| | | | | | | interface files. At the moment, all declarations (and no macros) are exported, and 'export' declarations are not supported yet. llvm-svn: 279794
* [analyzer] Command line option to show enabled checker list.Gabor Horvath2016-08-081-0/+5
| | | | | | | | | | | | This patch adds a command line option to list the checkers that were enabled by analyzer-checker and not disabled by -analyzer-disable-checker. It can be very useful to debug long command lines when it is not immediately apparent which checkers are turned on and which checkers are turned off. Differential Revision: https://reviews.llvm.org/D23060 llvm-svn: 278006
* Make it possible for AST plugins to enable themselves by defaultJohn Brawn2016-03-151-1/+15
| | | | | | | | | | | | Currently when an AST plugin is loaded it must then be enabled by passing -plugin pluginname or -add-plugin pluginname to the -cc1 command line. This patch adds a method to PluginASTAction which allows it to declare that the action happens before, instead of, or after the main AST action, plus the relevant changes to make the plugin action happen at that time automatically. Differential Revision: http://reviews.llvm.org/D17959 llvm-svn: 263546
* Revert r260265, "clang-cl: Support loading plugins on Windows"NAKAMURA Takumi2016-02-111-8/+1
| | | | | | It causes memory exhaust on mingw-w64(x64). Investigating. llvm-svn: 260536
* clang-cl: Support loading plugins on WindowsEhsan Akhgari2016-02-091-1/+8
| | | | | | | | | | | | This builds on the support being added to LLVM to import and export registries from DLLs. This will allow us to pick up the registry entries added in the DLL's copy of FrontendPluginRegistry. This will allow us to use plugins on Windows using: $ clang-cl -Xclang -load -Xclang plugin.dll \ -Xclang -add-plugin -Xclang foo llvm-svn: 260265
* [Frontend] Make the memory management of FrontendAction pointers explicit by ↵Argyrios Kyrtzidis2016-02-071-42/+47
| | | | | | using unique_ptr. llvm-svn: 260048
* Provide a BuryPointer for unique_ptrs.David Blaikie2014-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In theory, it'd be nice if we could move to a case where all buried pointers were buried via unique_ptr to demonstrate that the program had finished with the value (that we could really have cleanly deallocated it) but instead chose to bury it. I think the main reason that's not possible right now is the various IntrusiveRefCntPtrs in the Frontend, sharing ownership for a variety of compiler bits (see the various similar "CompilerInstance::releaseAndLeak*" functions). I have yet to figure out their correct ownership semantics - but perhaps, even if the intrusiveness can be removed, the shared ownership may yet remain and that would lead to a non-unique burying as is there today. (though we could model that a little better - by passing in a shared_ptr, etc - rather than needing the two step that's currently used in those other releaseAndLeak* functions) This might be a bit more robust if BuryPointer took the boolean: BuryPointer(bool, unique_ptr<T>) and the choice to bury was made internally - that way, even when DisableFree was not set, the unique_ptr would still be null in the caller and there'd be no chance of accidentally having a different codepath where the value is used after burial in !DisableFree, but it becomes null only in DisableFree, etc... llvm-svn: 216742
* Make clang's rewrite engine a core featureAlp Toker2014-07-161-22/+4
| | | | | | | | | | | | | | | The rewrite facility's footprint is small so it's not worth going to these lengths to support disabling at configure time, particularly since key compiler features now depend on it. Meanwhile the Objective-C rewriters have been moved under the ENABLE_CLANG_ARCMT umbrella for now as they're comparatively heavy and still potentially worth excluding from lightweight builds. Tests are now passing with any combination of feature flags. The flags historically haven't been tested by LLVM's build servers so caveat emptor. llvm-svn: 213171
* [C++11] Use 'nullptr'.Craig Topper2014-05-261-4/+4
| | | | llvm-svn: 209612
* [objcmt] Don't wrap a PCH generation action with a ObjCMigrateAction one, it ↵Argyrios Kyrtzidis2014-05-171-1/+2
| | | | | | | | messes up the PCH file. rdar://16941811 llvm-svn: 209059
* [leaks] Don't leak the fake arguments we synthesize for LLVM optionChandler Carruth2014-05-031-2/+2
| | | | | | parsing. llvm-svn: 207899
* Replace OwningPtr with std::unique_ptr.Ahmed Charles2014-03-071-3/+3
| | | | | | This compiles cleanly with lldb/lld/clang-tools-extra/llvm. llvm-svn: 203279
* Change OwningPtr::take() to OwningPtr::release().Ahmed Charles2014-03-071-2/+2
| | | | | | This is a precursor to moving to std::unique_ptr. llvm-svn: 203275
* Add a CC1 option -verify-pchBen Langmuir2014-02-051-0/+1
| | | | | | | | | This option will: - load the given pch file - verify it is not out of date by stat'ing dependencies, and - return 0 on success and non-zero on error llvm-svn: 200884
* Bury leaked pointers in a global array to silence a leak detector in ↵Kostya Serebryany2013-12-271-1/+2
| | | | | | | | | | | | | | | | --disable-free mode Summary: This is an alternative to http://llvm-reviews.chandlerc.com/D2475 suggested by Chandler. Reviewers: chandlerc, rnk, dblaikie CC: cfe-commits, earthdok Differential Revision: http://llvm-reviews.chandlerc.com/D2478 llvm-svn: 198073
* Bring back a StringRef used in some build configurationsAlp Toker2013-11-271-0/+2
| | | | | | | | | | This was removed in the great unused local cleanup of r195814. Adding cast-to-void to suppress unused variable warnings. Should fix certain builds like ARCMT. llvm-svn: 195872
OpenPOWER on IntegriCloud