aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/FrontendAction.cpp
AgeCommit message (Collapse)AuthorFilesLines
2017-06-29Teach ASTReader how to read only the Preprocessor state from an AST file, ↵Richard Smith1-4/+5
not the ASTContext state. We use this when running a preprocessor-only action on an AST file in order to avoid paying the runtime cost of loading the extra information. llvm-svn: 306760
2017-06-29Track the set of module maps read while building a .pcm file and reload ↵Richard Smith1-17/+25
those when preprocessing from that .pcm file. llvm-svn: 306628
2017-06-26Remove some redundant setup when preprocessing .pcm files.Richard Smith1-1/+0
Both of these steps are immediately overwritten by the FrontendAction setup. llvm-svn: 306325
2017-06-09Remove 'Filename' parameter from BeginSourceFileAction.Richard Smith1-6/+5
No-one was using this, and it's not meaningful in general -- FrontendActions can be run on inputs that don't have a corresponding source file. The current frontend input can be obtained by asking the FrontendAction if any future action actually needs it. llvm-svn: 305045
2017-06-06Retain header search and preprocessing options from AST file when emittingRichard Smith1-0/+3
preprocessed text for an AST file. llvm-svn: 304756
2017-06-05Factor out and unify emission of "module is unavailable" diagnostics.Richard Smith1-14/+2
Inspired by post-commit review of r304190. llvm-svn: 304728
2017-06-05Rather than rejecting attempts to run preprocessor-only actions on AST files,Richard Smith1-15/+63
replay the steps taken to create the AST file with the preprocessor-only action installed to produce preprocessed output. This can be used to produce the preprocessed text for an existing .pch or .pcm file. llvm-svn: 304726
2017-06-02Support lazy stat'ing of files referenced by module maps.Richard Smith1-6/+20
This patch adds support for a `header` declaration in a module map to specify certain `stat` information (currently, size and mtime) about that header file. This has two purposes: - It removes the need to eagerly `stat` every file referenced by a module map. Instead, we track a list of unresolved header files with each size / mtime (actually, for simplicity, we track submodules with such headers), and when attempting to look up a header file based on a `FileEntry`, we check if there are any unresolved header directives with that `FileEntry`'s size / mtime and perform deferred `stat`s if so. - It permits a preprocessed module to be compiled without the original files being present on disk. The only reason we used to need those files was to get the `stat` information in order to do header -> module lookups when using the module. If we're provided with the `stat` information in the preprocessed module, we can avoid requiring the files to exist. Unlike most `header` directives, if a `header` directive with `stat` information has no corresponding on-disk file the enclosing module is *not* marked unavailable (so that behavior is consistent regardless of whether we've resolved a header directive, and so that preprocessed modules don't get marked unavailable). We could actually do this for all `header` directives: the only reason we mark the module unavailable if headers are missing is to give a diagnostic slightly earlier (rather than waiting until we actually try to build the module / load and validate its .pcm file). Differential Revision: https://reviews.llvm.org/D33703 llvm-svn: 304515
2017-05-31[modules] When compiling a preprocessed module map, look for headers relativeRichard Smith1-8/+12
to the original module map. Also use the path and name of the original module map when emitting that information into the .pcm file. The upshot of this is that the produced .pcm file will track information for headers in their original locations (where the module was preprocessed), not relative to whatever directory the preprocessed module map was in when it was built. llvm-svn: 304346
2017-05-22Give files from #line the characteristics of the current fileReid Kleckner1-1/+2
This allows #line directives to appear in system headers that have code that clang would normally warn on. This is compatible with GCC, which is easy to test by running `gcc -E`. Fixes PR30752 llvm-svn: 303582
2017-05-05Add support for building modules from preprocessed source.Richard Smith1-81/+146
To support this, an optional marker "#pragma clang module contents" is recognized in module map files, and the rest of the module map file from that point onwards is treated as the source of the module. Preprocessing a module map produces the input module followed by the marker and then the preprocessed contents of the module. Ignoring line markers, a preprocessed module might look like this: module A { header "a.h" } #pragma clang module contents #pragma clang module begin A // ... a.h ... #pragma clang module end The preprocessed output generates line markers, which are not accepted by the module map parser, so -x c++-module-map-cpp-output should be used to compile such outputs. A couple of major parts do not work yet: 1) The files that are listed in the module map must exist on disk, in order to build the on-disk header -> module lookup table in the PCM file. To fix this, we need the preprocessed output to track the file size and other stat information we might use to build the lookup table. 2) Declaration ownership semantics don't work properly yet, since mapping from a source location to a module relies on mapping from FileIDs to modules, which we can't do if module transitions can occur in the middle of a file. llvm-svn: 302309
2017-04-28Move functionality for handling module maps as inputs from the -emit-moduleRichard Smith1-3/+263
action to the general FrontendAction infrastructure. This permits applying -E, -ast-dump, -fsyntax-only, and so on to a module map compilation. (The -E form is not currently especially useful yet as there's no good way to take the output and use it to actually build a module.) In order to support this, -cc1 now accepts -x <lang>-module-map in all cases where it accepts -x <lang> for a language we can parse (not ir/ast). And for uniformity, we also accept -x <lang>-header for all such languages (we used to reject for cuda and renderscript), and -x <lang>-cpp-output for all such languages (we used to reject for c, cl, and renderscript). (None of these new alternatives are accepted by the driver yet, so no user-visible changes.) llvm-svn: 301610
2017-04-26Refactor frontend InputKind to prepare for treating module maps as a ↵Richard Smith1-2/+3
distinct kind of input. No functionality change intended. llvm-svn: 301442
2017-03-07Use filename in linemarker when compiling preprocessed source (Revised)Taewook Oh1-2/+46
Summary: This is a revised version of D28796. Included test is changed to resolve the target compatibility issue reported (rL293032). Reviewers: inglorion, dblaikie, echristo, aprantl, probinson Reviewed By: inglorion Subscribers: mehdi_amini, cfe-commits Differential Revision: https://reviews.llvm.org/D30663 llvm-svn: 297194
2017-02-08Initialize builtins during modular codegenDavid Blaikie1-0/+3
llvm-svn: 294512
2017-02-07Enable -dump-deserialized-decls and -error-on-deserialized-decl for modules.Vassil Vassilev1-16/+22
llvm-svn: 294359
2017-01-25Revert "Use filename in linemarker when compiling preprocessed source"Diana Picus1-46/+2
This reverts commit r293004 because it broke the buildbots with "unknown CPU" errors. I tried to fix it in r293026, but that broke on Green Dragon with this kind of error: error: expected string not found in input // CHECK: l{{ +}}df{{ +}}*ABS*{{ +}}{{0+}}{{.+}}preprocessed-input.c{{$}} ^ <stdin>:2:1: note: scanning from here /Users/buildslave/jenkins/sharedspace/incremental@2/clang-build/tools/clang/test/Frontend/Output/preprocessed-input.c.tmp.o: file format Mach-O 64-bit x86-64 ^ <stdin>:2:67: note: possible intended match here /Users/buildslave/jenkins/sharedspace/incremental@2/clang-build/tools/clang/test/Frontend/Output/preprocessed-input.c.tmp.o: file format Mach-O 64-bit x86-64 I suppose this means that llvm-objdump doesn't support Mach-O, so the test should indeed check for linux (but not for x86). I'll leave it to someone that knows better. llvm-svn: 293032
2017-01-25Use filename in linemarker when compiling preprocessed sourceDavid Callahan1-2/+46
Summary: Clang appears to always use name as specified on the command line, whereas gcc uses the name as specified in the linemarker at the first line when compiling a preprocessed source. This results mismatch between two compilers in FILE symbol table entry. This patch makes clang to resemble gcc's behavior in finding the original source file name and use it as an input file name. Even with this patch, values of FILE symbol table entry may still be different because clang uses dirname+basename for the entry whlie gcc uses basename only. I'll write a patch for that once this patch is committed. Reviewers: dblaikie, inglorion Reviewed By: inglorion Subscribers: inglorion, aprantl, bruno Differential Revision: https://reviews.llvm.org/D28796 llvm-svn: 293004
2017-01-05Move Preprocessor over to std::shared_ptr rather than IntrusiveRefCntPtrDavid Blaikie1-1/+1
llvm-svn: 291166
2016-12-12[Frontend] Use vfs for directory iteration while searching PCHs. NFCIBruno Cardoso Lopes1-3/+4
Use the vfs lookup instead of real filesytem and handle the case where -include-pch is a directory and this dir is searched for a PCH. llvm-svn: 289459
2016-08-05Reapply r276973 "Adjust Registry interface to not require plugins to export ↵John Brawn1-1/+1
a registry" This differs from the previous version by being more careful about template instantiation/specialization in order to prevent errors when building with clang -Werror. Specifically: * begin is not defined in the template and is instead instantiated when Head is. I think the warning when we don't do that is wrong (PR28815) but for now at least do it this way to avoid the warning. * Instead of performing template specializations in LLVM_INSTANTIATE_REGISTRY instead provide a template definition then do explicit instantiation. No compiler I've tried has problems with doing it the other way, but strictly speaking it's not permitted by the C++ standard so better safe than sorry. Original commit message: Currently the Registry class contains the vestiges of a previous attempt to allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a plugin would have its own copy of a registry and export it to be imported by the tool that's loading the plugin. This only works if the plugin is entirely self-contained with the only interface between the plugin and tool being the registry, and in particular this conflicts with how IR pass plugins work. This patch changes things so that instead the add_node function of the registry is exported by the tool and then imported by the plugin, which solves this problem and also means that instead of every plugin having to export every registry they use instead LLVM only has to export the add_node functions. This allows plugins that use a registry to work on Windows if LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used. llvm-svn: 277806
2016-07-28Revert r276973 "Adjust Registry interface to not require plugins to export a ↵John Brawn1-1/+1
registry" Buildbot failures when building with clang -Werror. Reverting while I try to figure this out. llvm-svn: 277008
2016-07-28Reapply r276856 "Adjust Registry interface to not require plugins to export ↵John Brawn1-1/+1
a registry" This version has two fixes compared to the original: * In Registry.h the template static members are instantiated before they are used, as clang gives an error if you do it the other way around. * The use of the Registry template in clang-tidy is updated in the same way as has been done everywhere else. Original commit message: Currently the Registry class contains the vestiges of a previous attempt to allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a plugin would have its own copy of a registry and export it to be imported by the tool that's loading the plugin. This only works if the plugin is entirely self-contained with the only interface between the plugin and tool being the registry, and in particular this conflicts with how IR pass plugins work. This patch changes things so that instead the add_node function of the registry is exported by the tool and then imported by the plugin, which solves this problem and also means that instead of every plugin having to export every registry they use instead LLVM only has to export the add_node functions. This allows plugins that use a registry to work on Windows if LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used. llvm-svn: 276973
2016-07-27Revert r276856 "Adjust Registry interface to not require plugins to export a ↵John Brawn1-1/+1
registry" This is causing a huge pile of buildbot failures. llvm-svn: 276857
2016-07-27Adjust Registry interface to not require plugins to export a registryJohn Brawn1-1/+1
Currently the Registry class contains the vestiges of a previous attempt to allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a plugin would have its own copy of a registry and export it to be imported by the tool that's loading the plugin. This only works if the plugin is entirely self-contained with the only interface between the plugin and tool being the registry, and in particular this conflicts with how IR pass plugins work. This patch changes things so that instead the add_node function of the registry is exported by the tool and then imported by the plugin, which solves this problem and also means that instead of every plugin having to export every registry they use instead LLVM only has to export the add_node functions. This allows plugins that use a registry to work on Windows if LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used. Differential Revision: http://reviews.llvm.org/D21385 llvm-svn: 276856
2016-07-18[NFC] Header cleanupMehdi Amini1-1/+2
Summary: Removed unused headers, replaced some headers with forward class declarations Patch by: Eugene <claprix@yandex.ru> Differential Revision: https://reviews.llvm.org/D20100 llvm-svn: 275882
2016-03-15Make it possible for AST plugins to enable themselves by defaultJohn Brawn1-18/+36
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
2016-02-16[Frontend] Make sure WrapperFrontendAction updates CurrentInput after ↵Argyrios Kyrtzidis1-1/+4
calling BeginSourceFileAction. I don't have a test case to add unfortunately. llvm-svn: 260937
2016-02-07[Frontend] Make the memory management of FrontendAction pointers explicit by ↵Argyrios Kyrtzidis1-2/+3
using unique_ptr. llvm-svn: 260048
2015-10-20Roll-back r250822.Angel Garcia Gomez1-1/+1
Summary: It breaks the build for the ASTMatchers Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D13893 llvm-svn: 250827
2015-10-20Apply modernize-use-default to clang.Angel Garcia Gomez1-1/+1
Summary: Replace empty bodies of default constructors and destructors with '= default'. Reviewers: bkramer, klimek Subscribers: klimek, alexfh, cfe-commits Differential Revision: http://reviews.llvm.org/D13890 llvm-svn: 250822
2015-09-04Fix crash on invalid if we can't find a suitable PCH file in a specifiedRichard Smith1-1/+1
directory, and our frontend action cares whether the frontend setup actually succeeded. llvm-svn: 246881
2015-08-27Add a -gmodules option to the driver and a -dwarf-ext-refs to cc1Adrian Prantl1-3/+3
to enable the use of external type references in the debug info (a.k.a. module debugging). The driver expands -gmodules to "-g -fmodule-format=obj -dwarf-ext-refs" and passes that to cc1. All this does at the moment is set a flag codegenopts. http://reviews.llvm.org/D11958 llvm-svn: 246192
2015-08-15[modules] Stop dropping 'module.timestamp' files into the current directoryRichard Smith1-3/+5
when building with implicit modules disabled. llvm-svn: 245136
2015-08-06Rename the non-coding style conformant functions in namespace BuiltinsEric Christopher1-1/+1
to match the rest of their brethren and reformat the bits that need it. llvm-svn: 244186
2015-07-17Make the clang module container format selectable from the command line.Adrian Prantl1-3/+3
- introduces a new cc1 option -fmodule-format=[raw,obj] with 'raw' being the default - supports arbitrary module container formats that libclang is agnostic to - adds the format to the module hash to avoid collisions - splits the old PCHContainerOperations into PCHContainerWriter and a PCHContainerReader. Thanks to Richard Smith for reviewing this patch! llvm-svn: 242499
2015-06-20Introduce a PCHContainerOperations interface (NFC).Adrian Prantl1-8/+8
A PCHContainerOperations abstract interface provides operations for creating and unwrapping containers for serialized ASTs (precompiled headers and clang modules). The default implementation is RawPCHContainerOperations, which uses a flat file for the output. The main application for this interface will be an ObjectFilePCHContainerOperations implementation that uses LLVM to wrap the module in an ELF/Mach-O/COFF container to store debug info alongside the AST. rdar://problem/20091852 llvm-svn: 240225
2015-05-04Reapply "Frontend: Stop leaking when not -disable-free"Duncan P. N. Exon Smith1-14/+13
This reverts commit r236422, effectively reapplying r236419. ASan helped me diagnose the problem: the non-leaking logic would free the ASTConsumer before freeing Sema whenever `isCurrentASTFile()`, causing a use-after-free in `Sema::~Sema()`. This version unconditionally frees Sema and the ASTContext before freeing the ASTConsumer. Without the fix, these were either being freed before the ASTConsumer was freed or leaked after, but they were always spiritually released so this isn't really a functionality change. I ran all of check-clang with ASan locally this time, so I'm hoping there aren't any more problems lurking. Original commit message: Try again to plug a leak that's been around since at least r128011 after coming across the FIXME. Nico Weber tried something similar in r207065 but had to revert in r207070 due to a bot failure. The build failure isn't visible anymore so I'm not sure what went wrong. I'm doing this slightly differently -- when not -disable-free I'm still resetting the members (just not leaking them) -- so maybe it will work out this time? Tests pass locally, anyway. llvm-svn: 236424
2015-05-04Revert "Frontend: Stop leaking when not -disable-free"Duncan P. N. Exon Smith1-13/+6
This reverts commit r236419, since it caused some bots to fail. On: http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/26124 http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/35086 these tests: FAIL: Clang::import-decl.cpp FAIL: Clang::floating-literal.c FAIL: Clang::x86_64-linux-android.c fail with this output: Command Output (stderr): -- Stack dump: 0. Program arguments: /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/clang -cc1 -internal-isystem /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/../lib/clang/3.7.0/include -nostdsysteminc -ast-print -x ast - /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/tools/clang/test/Modules/Output/import-decl.cpp.script: line 3: 9665 Segmentation fault (core dumped) /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/clang -cc1 -internal-isystem /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/../lib/clang/3.7.0/include -nostdsysteminc -ast-print -x ast - < /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/tools/clang/test/Modules/Output/import-decl.cpp.tmp.ast 9666 Done | /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/FileCheck /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.src/tools/clang/test/Modules/import-decl.cpp -- llvm-svn: 236422
2015-05-04Frontend: Stop leaking when not -disable-freeDuncan P. N. Exon Smith1-6/+13
Try again to plug a leak that's been around since at least r128011 after coming across the FIXME. Nico Weber tried something similar in r207065 but had to revert in r207070 due to a bot failure. The build failure isn't visible anymore so I'm not sure what went wrong. I'm doing this slightly differently -- when not -disable-free I'm still resetting the members (just not leaking them) -- so maybe it will work out this time? Tests pass locally, anyway. llvm-svn: 236419
2015-05-04Rename MacroDefinition -> MacroDefinitionRecord, ↵Richard Smith1-1/+1
Preprocessor::MacroDefinition -> MacroDefinition. clang::MacroDefinition now models the currently-defined value of a macro. The previous MacroDefinition type, which represented a record of a macro definition directive for a detailed preprocessing record, is now called MacroDefinitionRecord. llvm-svn: 236400
2015-04-11Use 'override/final' instead of 'virtual' for overridden methodsAlexander Kornienko1-1/+1
Summary: The patch is generated using clang-tidy misc-use-override check. This command was used: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \ -checks='-*,misc-use-override' -header-filter='llvm|clang' -j=32 -fix Reviewers: dblaikie Reviewed By: dblaikie Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D8926 llvm-svn: 234678
2015-03-18Remove many superfluous SmallString::str() calls.Yaron Keren1-1/+1
Now that SmallString is a first-class citizen, most SmallString::str() calls are not required. This patch removes a whole bunch of them, yet there are lots more. There are two use cases where str() is really needed: 1) To use one of StringRef member functions which is not available in SmallString. 2) To convert to std::string, as StringRef implicitly converts while SmallString do not. We may wish to change this, but it may introduce ambiguity. llvm-svn: 232622
2015-02-19[PCH/Modules] Check that the specific module cache path the PCH was built ↵Argyrios Kyrtzidis1-1/+3
with, is the same as the one in the current compiler invocation. If they differ reject the PCH. This protects against the badness occurring from getting modules loaded from different module caches (see crashes). rdar://19889860 llvm-svn: 229909
2015-01-23PR22299: Relocate code for handling -fmodule-map-file= so that we don't try toRichard Smith1-0/+9
produce diagnostics with source locations before the diagnostics system is ready for them. llvm-svn: 226882
2014-10-27[modules] Load .pcm files specified by -fmodule-file lazily.Richard Smith1-9/+3
llvm-svn: 220731
2014-10-22[modules] Initial support for explicitly loading .pcm files.Richard Smith1-1/+12
Implicit module builds are not well-suited to a lot of build systems. In particular, they fare badly in distributed build systems, and they lead to build artifacts that are not tracked as part of the usual dependency management process. This change allows explicitly-built module files (which are already supported through the -emit-module flag) to be explicitly loaded into a build, allowing build systems to opt to manage module builds and dependencies themselves. This is only the first step in supporting such configurations, and it should be considered experimental and subject to change or removal for now. llvm-svn: 220359
2014-08-27Add support for the static analyzer to synthesize function implementations ↵Ted Kremenek1-4/+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
2014-08-10Recommit 213307: unique_ptr-ify ownership of ASTConsumers (reverted in r213325)David Blaikie1-18/+20
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
2014-08-10std::unique_ptr-ify the result of ASTUnit::LoadFromASTFileDavid Blaikie1-2/+2
llvm-svn: 215320
generated by cgit v1.1 at 2025-10-12 08:43:16 +0000