summaryrefslogtreecommitdiffstats
path: root/clang/lib/Lex/Preprocessor.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix some Clang-tidy modernize-use-using and Include What You Use warnings; ↵Eugene Zelenko2016-09-071-10/+18
| | | | | | | | other minor fixes. Differential revision: https://reviews.llvm.org/D24115 llvm-svn: 280870
* C++ Modules TS: add frontend support for building pcm files from moduleRichard Smith2016-08-261-1/+18
| | | | | | | interface files. At the moment, all declarations (and no macros) are exported, and 'export' declarations are not supported yet. llvm-svn: 279794
* C++ Modules TS: Add parsing support for module import declaration.Richard Smith2016-08-181-4/+8
| | | | llvm-svn: 279163
* PR28438: Update the information on an identifier with local definitions beforeRichard Smith2016-08-181-1/+6
| | | | | | | | trying to write out its macro graph, in case we imported a module that added another module macro between the most recent local definition and the end of the module. llvm-svn: 279024
* Reapply r276973 "Adjust Registry interface to not require plugins to export ↵John Brawn2016-08-051-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
* Revert r276973 "Adjust Registry interface to not require plugins to export a ↵John Brawn2016-07-281-1/+1
| | | | | | | | | registry" Buildbot failures when building with clang -Werror. Reverting while I try to figure this out. llvm-svn: 277008
* Reapply r276856 "Adjust Registry interface to not require plugins to export ↵John Brawn2016-07-281-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
* Implement filtering for code completion of identifiers.Vassil Vassilev2016-07-271-1/+4
| | | | | | | | Patch by Cristina Cristescu and Axel Naumann! Agreed on post commit review (D17820). llvm-svn: 276878
* Revert r276856 "Adjust Registry interface to not require plugins to export a ↵John Brawn2016-07-271-1/+1
| | | | | | | | registry" This is causing a huge pile of buildbot failures. llvm-svn: 276857
* Adjust Registry interface to not require plugins to export a registryJohn Brawn2016-07-271-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
* [NFC] Header cleanupMehdi Amini2016-07-181-1/+1
| | | | | | | | | | 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
* Apply clang-tidy's misc-move-constructor-init throughout Clang.Benjamin Kramer2016-05-271-1/+2
| | | | | | No functionality change intended, maybe a tiny performance improvement. llvm-svn: 270996
* AnnotateFunctions: Tweak for mingw.NAKAMURA Takumi2016-04-041-0/+2
| | | | | | | - Externalize the registry. - Update libdeps. llvm-svn: 265301
* [modules] Flatten -fmodule-name= and -fmodule-implementation-of= into a singleRichard Smith2016-02-191-1/+1
| | | | | | | | | | | | option. Previously these options could both be used to specify that you were compiling the implementation file of a module, with a different set of minor bugs in each case. This change removes -fmodule-implementation-of, and instead tracks a flag to determine whether we're currently building a module. -fmodule-name now behaves the same way that -fmodule-implementation-of previously did. llvm-svn: 261372
* Sink some PTHManager includes out of Preprocessor.hReid Kleckner2015-11-021-0/+1
| | | | | | | This reduces the number of .cpp files needed to be rebuilt after touching OnDiskHashTable from 120 to 21 for me. llvm-svn: 251810
* Roll-back r250822.Angel Garcia Gomez2015-10-201-4/+4
| | | | | | | | | | Summary: It breaks the build for the ASTMatchers Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D13893 llvm-svn: 250827
* Apply modernize-use-default to clang.Angel Garcia Gomez2015-10-201-4/+4
| | | | | | | | | | | | 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
* Replace double negation of !FileID.isInvalid() with FileID.isValid().Yaron Keren2015-10-031-1/+1
| | | | | | +couple more of double-negated !SourceLocation.isInvalid() unfixed in r249228. llvm-svn: 249235
* Fix typo.Yaron Keren2015-09-291-1/+1
| | | | llvm-svn: 248807
* [CUDA] Allow parsing of host and device code simultaneously.Artem Belevich2015-09-221-14/+18
| | | | | | | | | | | | * adds -aux-triple option to specify target triple * propagates aux target info to AST context and Preprocessor * pulls in target specific preprocessor macros. * pulls in target-specific builtins from aux target. * sets appropriate host or device attribute on builtins. Differential Revision: http://reviews.llvm.org/D12917 llvm-svn: 248299
* Rename the non-coding style conformant functions in namespace BuiltinsEric Christopher2015-08-061-1/+1
| | | | | | to match the rest of their brethren and reformat the bits that need it. llvm-svn: 244186
* [Preprocessor] Iterating over all macros should include those from modules.Jordan Rose2015-06-241-0/+4
| | | | | | | | | | | | So, iterate over the list of macros mentioned in modules, and make sure those are in the master table. This isn't particularly efficient, but hopefully it's something that isn't done too often. PR23929 and rdar://problem/21480635 llvm-svn: 240571
* [modules] If we re-enter a submodule from within itself (when submoduleRichard Smith2015-05-211-6/+11
| | | | | | | | | | visibility is enabled) or leave and re-enter it, restore the macro and module visibility state from last time we were in that submodule. This allows mutually-#including header files to stand a chance at being modularized with local visibility enabled. llvm-svn: 237871
* Generalize future keyword compat diagnostics.Richard Smith2015-05-141-6/+24
| | | | | | | | | | | | This, in preparation for the introduction of more new keywords in the implementation of the C++ language, generalizes the support for future keyword compat diagnostics (e.g., diag::warn_cxx11_keyword) by extending the applicability of the relevant property in IdentifierTable with appropriate renaming. Patch by Hubert Tong! llvm-svn: 237332
* [modules] Rearrange preprocessor module visibility handling, no observable ↵Richard Smith2015-05-141-1/+1
| | | | | | change intended. llvm-svn: 237331
* [modules] Remove dead code from Module for tracking macro import locations.Richard Smith2015-05-021-1/+1
| | | | llvm-svn: 236376
* [modules] If a module #includes a modular header that #undef's its macro, itRichard Smith2015-05-021-4/+1
| | | | | | | | should not export the macro. ... at least, not unless we have local submodule visibility enabled. llvm-svn: 236369
* [modules] Start moving the module visibility information off the Module itself.Richard Smith2015-05-011-4/+22
| | | | | | | It has no place there; it's not a property of the Module, and it makes restoring the visibility set when we leave a submodule more difficult. llvm-svn: 236300
* Add an assert to get information on buildbot failure.Richard Smith2015-04-291-0/+1
| | | | llvm-svn: 236181
* [modules] Stop trying to fake up a linear MacroDirective history.Richard Smith2015-04-291-4/+6
| | | | | | | | | | | | | | Modules builds fundamentally have a non-linear macro history. In the interest of better source fidelity, represent the macro definition information faithfully: we have a linear macro directive history within each module, and at any point we have a unique "latest" local macro directive and a collection of visible imported directives. This also removes the attendent complexity of attempting to create a correct MacroDirective history (which we got wrong in the general case). No functionality change intended. llvm-svn: 236176
* Refactor to make MacroState ownership and lifetime clearer.Richard Smith2015-04-281-3/+0
| | | | llvm-svn: 236032
* Fix memory leak found by asan buildbot.Richard Smith2015-04-281-0/+3
| | | | llvm-svn: 235957
* [modules] Incrementally compute the list of overridden module macros based onRichard Smith2015-04-271-2/+5
| | | | | | | the active module macros at the point of definition, rather than reconstructing it from the macro history. No functionality change intended. llvm-svn: 235941
* [modules] Determine the set of macros exported by a submodule at the end of ↵Richard Smith2015-04-231-1/+1
| | | | | | | | | | | that submodule. Previously we'd defer this determination until writing the AST, which doesn't allow us to use this information when building other submodules of the same module. This change also allows us to use a uniform mechanism for writing module macro records, independent of whether they are local or imported. llvm-svn: 235614
* [Modules] Fix crash in Preprocessor::getLastMacroWithSpelling().Argyrios Kyrtzidis2015-03-041-3/+3
| | | | | | Macro names that got undefined inside a module may not have their MacroInfo set. llvm-svn: 231251
* Modified the Objective-C lexer and parser (only Sean Callanan2014-12-091-7/+10
| | | | | | | | | | | | | | | | in debugger mode) to accept @import declarations and pass them to the debugger. In the preprocessor, accept import declarations if the debugger is enabled, but don't actually load the module, just pass the import path on to the preprocessor callbacks. In the Objective-C parser, if it sees an import declaration in statement context (usual for LLDB), ignore it and return a NullStmt. llvm-svn: 223855
* [modules] Track how 'header' directives were written in module map files,Richard Smith2014-12-021-1/+1
| | | | | | | | | | | | | rather than trying to extract this information from the FileEntry after the fact. This has a number of beneficial effects. For instance, diagnostic messages for failed module builds give a path relative to the "module root" rather than an absolute file path, and the contents of the module includes file is no longer dependent on what files the including TU happened to inspect prior to triggering the module build. llvm-svn: 223095
* [libclang] If the code-completion point is inside the preamble, adjust the ↵Argyrios Kyrtzidis2014-10-181-0/+9
| | | | | | | | | position at the beginning of the file after the preamble. Otherwise we will not hit the code-completion point. llvm-svn: 220136
* [libclang] Allow code-completion when pointing at the end-of-file.Argyrios Kyrtzidis2014-10-181-15/+14
| | | | llvm-svn: 220135
* Unique_ptrify Preprocessor::PragmaHandlersBackupDavid Blaikie2014-09-151-2/+2
| | | | | | Follow up to r217656 llvm-svn: 217829
* Use unique_ptr for ScratchBuf and PragmaHandlers in the preprocessor.Craig Topper2014-09-121-14/+8
| | | | llvm-svn: 217656
* Unique_ptrify PPCallbacks ownership.Craig Topper2014-09-101-3/+1
| | | | | | Unique_ptr creation stil needs to be moved earlier at some of the call sites. llvm-svn: 217474
* unique_ptrify Preprocessor's TokenLexerCacheDavid Blaikie2014-08-291-2/+1
| | | | llvm-svn: 216756
* unique_ptrify SourceManager::createFileIDDavid Blaikie2014-08-291-1/+1
| | | | llvm-svn: 216715
* Overload SourceManager::overrideFileContents so that unconditionally passing ↵David Blaikie2014-08-271-1/+1
| | | | | | | | | | ownership is explicitly done using unique_ptr. Only those callers who are dynamically passing ownership should need the 3 argument form. Those accepting the default ("do pass ownership") should do so explicitly with a unique_ptr now. llvm-svn: 216614
* Update for LLVM api change.Rafael Espindola2014-08-271-4/+4
| | | | llvm-svn: 216585
* Add support for the static analyzer to synthesize function implementations ↵Ted Kremenek2014-08-271-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* unique_ptr-ify FileSystemStatCache::setNextStatCacheDavid Blaikie2014-08-111-0/+1
| | | | | | | | | | And in the process, discover that FileManager::removeStatCache had a double-delete when removing an element from the middle of the list (at the beginning or the end of the list, there was no problem) and add a unit test to exercise the code path (which successfully crashed when run (with modifications to match the old API) without this patch applied) llvm-svn: 215388
* Simplify MacroInfo lifetime management. We don't need three different functionsRichard Smith2014-07-241-5/+9
| | | | | | to destroy one of these. llvm-svn: 213837
* Remove unused Prev pointer from MacroInfo chain.Richard Smith2014-07-241-2/+2
| | | | | | | | Remove pointless MICache: it only ever contained up to 1 object, and was only non-empty when recovering from an error. There's no performance or memory win from maintaining this cache. llvm-svn: 213825
OpenPOWER on IntegriCloud