summaryrefslogtreecommitdiffstats
path: root/clang/lib/Lex/PPDirectives.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Lex: Don't let annotation tokens get into macro expansionDavid Majnemer2014-12-281-1/+2
| | | | | | | | | | We'd let annotation tokens from '#pragma pack' and the like get inside a function-like macro. This would lead to terror and mayhem; stop the madness early. This fixes PR22037. llvm-svn: 224896
* Fixed warnings on redefine keywords and reserved ids.Serge Pavlov2014-12-181-14/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | Repared support for warnings -Wkeyword-macro and -Wreserved-id-macro. The warning -Wkeyword-macro now is not issued in patterns that are used in configuration scripts: #define inline also for 'const', 'extern' and 'static'. If macro repalcement is identical to macro name, the warning also is not issued: #define volatile volatile And finally if macro replacement is also a keyword identical to the replaced one but decorated with leading/trailing underscores: #define inline __inline #define inline __inline__ #define inline _inline // in MSVC compatibility mode Warning -Wreserved-id-macro is off by default, it could help catching things like: #undef __cplusplus llvm-svn: 224512
* Move -Wkeyword-macro into -pedantic, remove -Wreserved-id-macro.Nico Weber2014-12-161-50/+5
| | | | | | | | | | | | | | | | | | | As discussed on the post-commit review thread for r224012, -Wkeyword-macro fires mostly on headers trying to set up portable defines and doesn't find much bad stuff in practice. But [macro.names]p2 does disallow defining or undefining keywords, override and final, and alignas, so keep the warning but move it into -pedantic. -Wreserved-id-macro warns on #define __need_size_t which is more or less public api for glibc headers. Since this warning isn't motivated by a standard, remove it. (See also r223114 for a previous follow-up to r224012.) llvm-svn: 224371
* Do not warn on keyword undefSerge Pavlov2014-12-121-11/+6
| | | | | | | #undef a keyword is generally harmless but used often in configuration scripts. Also added tests that I forgot to include to commit in r223114. llvm-svn: 224100
* Emit warning if define or undef reserved identifier or keyword.Serge Pavlov2014-12-111-0/+69
| | | | | | Recommit of r223114, reverted in r223120. llvm-svn: 224012
* Reverted r223114, it caused failure on on clang-native-arm-cortex-a9.Serge Pavlov2014-12-021-69/+0
| | | | llvm-svn: 223120
* Emit warning if define or undef reserved identifier or keyword.Serge Pavlov2014-12-021-0/+69
| | | | | | | | | | | | | | | | | | | | | Summary: This change implements warnings if macro name is identical to a keyword or reserved identifier. The warnings are different depending on the "danger" of the operation. Defining macro that replaces a keyword is on by default. Other cases produce warning that is off by default but can be turned on using option -Wreserved-id-macro. This change fixes PR11488. Reviewers: rnk Reviewed By: rnk Subscribers: rnk, cfe-commits Differential Revision: http://reviews.llvm.org/D6194 llvm-svn: 223114
* [modules] Track how 'header' directives were written in module map files,Richard Smith2014-12-021-7/+15
| | | | | | | | | | | | | 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
* Use enumerators instead of hardcoded integers when processing macro names.Serge Pavlov2014-10-241-13/+14
| | | | llvm-svn: 220572
* [modules] Add support for #include_next.Richard Smith2014-10-201-17/+50
| | | | | | | | | | | | #include_next interacts poorly with modules: it depends on where in the list of include paths the current file was found. Files covered by module maps are not found in include search paths when building the module (and are not found in include search paths when @importing the module either), so this isn't really meaningful. Instead, we fake up the result that #include_next *should* have given: find the first path that would have resulted in the given file being picked, and search from there onwards. llvm-svn: 220177
* Correctly implement -include search logic.Manuel Klimek2014-08-121-8/+11
| | | | | | | | | | | | | | | According to the gcc docs, -include uses the current working directory for the lookup instead of the main source file. This patch gets rid of NormalizeIncludePath (which relied on an implementation detail of FileManager / FileEntry for the include path logic to work), and instead hands the correct lookup information down to LookupFile. This will allow us to change the FileEntry's behavior regarding its Name caching. llvm-svn: 215433
* Fix six tests are failing on Windows after r215241-r215243.Yaron Keren2014-08-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang :: Frontend/iframework.c Clang :: Frontend/system-header-prefix.c Clang :: Index/annotate-comments-objc.m Clang :: Index/annotate-module.m Clang :: Index/index-module.m Clang :: Index/index-pch-with-module.m Clang :: PCH/case-insensitive-include.c Suprisingly the normalize_separators() was no-op when LLVM_ON_WIN32. Its replacement native() does change path separators into \ as expected, breaking these tests. I had fixed the tests by #ifndef LLVM_ON_WIN32 on the native call, to match the previous behaviour. If this logic is not used on Windows host, it might be completely deleted as there should not be windows path seperators on Linux hosts. I can't test on Linux but if someone can run tests on Linux after commenting out the line llvm::sys::path::native(NormalizedPath); and the tests pass, the whole if (LangOpts.MSVCCompat) could be deleted. llvm-svn: 215290
* Use llvm::sys::path::native instead of llvm::sys::fs::normalize_separators.Rafael Espindola2014-08-081-2/+2
| | | | | | | llvm::sys::path::native has a superset of the functionality and this was the only use of llvm::sys::fs::normalize_separators. llvm-svn: 215242
* Don't destroy MacroInfos if we find the macro definition is invalid; it'll getRichard Smith2014-08-031-12/+0
| | | | | | destroyed on shutdown regardless. Fixes a double-delete. llvm-svn: 214675
* [modules] Substantially improve handling of #undef:Richard Smith2014-07-251-11/+16
| | | | | | | | | | * Track override set across module load and save * Track originating module to allow proper re-export of #undef * Make override set properly transitive when it picks up a #undef This fixes nearly all of the remaining macro issues with self-host. llvm-svn: 213922
* Simplify MacroInfo lifetime management. We don't need three different functionsRichard Smith2014-07-241-3/+4
| | | | | | to destroy one of these. llvm-svn: 213837
* Remove unused Prev pointer from MacroInfo chain.Richard Smith2014-07-241-29/+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
* Add stopgap option -fmodule-implementation-of <name>Ben Langmuir2014-07-231-1/+3
| | | | | | | | | | | | | | | | | | This flag specifies that we are building an implementation file of the module <name>, preventing importing <name> as a module. This does not consider this to be the 'current module' for the purposes of doing modular checks like decluse or non-modular-include warnings, unlike -fmodule-name. This is needed as a stopgap until: 1) we can resolve relative includes to a VFS-mapped module (or can safely import a header textually and as part of a module) and ideally 2) we can safely do incremental rebuilding when implementation files import submodules. llvm-svn: 213767
* Convert StringLiteralParser constructor to use ArrayRef instead of a pointer ↵Craig Topper2014-06-261-2/+2
| | | | | | and count. llvm-svn: 211763
* Fixed formatting.Yaron Keren2014-06-191-3/+2
| | | | llvm-svn: 211295
* Hide the concept of diagnostic levels from lex, parse and semaAlp Toker2014-06-151-2/+1
| | | | | | | | | | | | | | | | The compilation pipeline doesn't actually need to know about the high-level concept of diagnostic mappings, and hiding the final computed level presents several simplifications and other potential benefits. The only exceptions are opportunistic checks to see whether expensive code paths can be avoided for diagnostics that are guaranteed to be ignored at a certain SourceLocation. This commit formalizes that invariant by introducing and using DiagnosticsEngine::isIgnored() in place of individual level checks throughout lex, parse and sema. llvm-svn: 211005
* Preprocessor: make C++ operator names as macro identifiers a compatible ↵Alp Toker2014-05-311-5/+6
| | | | | | | | | | | extension With recent changes, this is now a compatible language extension and can be safely enabled with -ms-extensions instead of requiring the full -ms-compatibility MSVC drop-in mode. As such we can now also emit an extension warning under -Wmicrosoft to help users port their code. llvm-svn: 209978
* Preprocessor: recover gracefully when C++ operator names are used as macro ↵Alp Toker2014-05-311-3/+4
| | | | | | | | | | identifiers This failure mode shows up occasionally when users try to include C headers in C++ projects or when porting from Windows. We might as well recover in the way the user expected, thus avoiding confusing diagnostic messages at point of use. llvm-svn: 209963
* Preprocessor: don't exit early in CheckMacroName()Alp Toker2014-05-311-10/+7
| | | | | | | | | | The checks below can hypothetically apply to converted operator name identifiers. In practice there are no builtin macros etc. with those names so there's no behavioural change to test. llvm-svn: 209962
* Provide an aka for the C++ operator name macro diagnosticAlp Toker2014-05-211-1/+1
| | | | llvm-svn: 209322
* Preprocessor: support defined() with operator names for MS compatibilityAlp Toker2014-05-211-40/+48
| | | | | | | | | Also flesh out missing tests, improve diagnostic QOI and fix a couple of corner cases found in the process. Fixes PR10606. llvm-svn: 209276
* [C++11] Use 'nullptr'. Lex edition.Craig Topper2014-05-171-33/+35
| | | | llvm-svn: 209083
* Provide and use a safe Token::getRawIdentifier() accessorAlp Toker2014-05-171-4/+4
| | | | llvm-svn: 209061
* Add -Wnon-modular-include* optionsBen Langmuir2014-05-051-4/+14
| | | | | | | | | | | | Warn on non-modular includes in various contexts. -Wnon-modular-include -Wnon-modular-include-in-module -Wnon-modular-include-in-framework-module Where each group is a subgroup of those above it. llvm-svn: 208004
* Use the expansion location of the file name when finding the module.Manuel Klimek2014-03-191-1/+1
| | | | | | | | The spelling location of stringified strings is not a file location. Optimally, we'll want to solve the problem (as the FIXME states) by handing in the right FileEntry of the #include location. llvm-svn: 204220
* Don't verify module inclusions in assembler files.Daniel Jasper2014-03-141-1/+1
| | | | llvm-svn: 203929
* Lex: reduce buffer size, add a testSaleem Abdulrasool2014-03-121-1/+1
| | | | | | | Reduce the stack usage as hopefully include paths are usually not too long. Add a test case for the path normalisation behaviour. llvm-svn: 203632
* lex: improve include handling on Linux for WindowsSaleem Abdulrasool2014-03-111-10/+22
| | | | | | | | | | Normalise the path separator character on non-windows platforms. Although this would work on Windows as well (most newer versions of Windows support either '/' or '\' as a path separator character), it could potentially cause problems with full UNC paths. This change enables the use of the Windows SDK on Linux which will not accept '\' as a path separator. llvm-svn: 203614
* [C++11] Switch from LLVM_STATIC_ASSERT to static_assert now that weChandler Carruth2014-03-021-2/+2
| | | | | | require host toolchains which support this. llvm-svn: 202640
* Track the currently-being-built submodule inside the preprocessor (rather thanRichard Smith2014-01-311-4/+8
| | | | | | | just storing a flag indicating if there was one), and include it in the 'end of module' annotation. No functionality change. llvm-svn: 200573
* Rename language option MicrosoftMode to MSVCCompatAlp Toker2014-01-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | There's been long-standing confusion over the role of these two options. This commit makes the necessary changes to differentiate them clearly, following up from r198936. MicrosoftExt (aka. fms-extensions): Enable largely unobjectionable Microsoft language extensions to ease portability. This mode, also supported by gcc, is used for building software like FreeBSD and Linux kernel extensions that share code with Windows drivers. MSVCCompat (aka. -fms-compatibility, formerly MicrosoftMode): Turn on a special mode supporting 'heinous' extensions for drop-in compatibility with the Microsoft Visual C++ product. Standards-compilant C and C++ code isn't guaranteed to work in this mode. Implies MicrosoftExt. Note that full -fms-compatibility mode is currently enabled by default on the Windows target, which may need tuning to serve as a reasonable default. See cfe-commits for the full discourse, thread 'r198497 - Move MS predefined type_info out of InitializePredefinedMacros' No change in behaviour. llvm-svn: 199209
* Implement MSVC header search algorithm in MicrosoftMode.Will Wilson2013-12-271-9/+24
| | | | | | Follows algorithm described here: http://msdn.microsoft.com/en-us/library/36k2cdd4.aspx llvm-svn: 198082
* Enable layering check in unavailable modules.Daniel Jasper2013-12-201-68/+2
| | | | | | | | | | | | | | | If a header file belonging to a certain module is not found on the filesystem, that header gets marked as unavailable. Now, the layering warning (-fmodules-decluse) should still warn about headers of this module being wrongfully included. Currently, headers belonging to those modules are just treated as not belonging to modules at all which means they can be included freely from everywhere. To implement this (somewhat) cleanly, I have moved most of the layering checks into the ModuleMap. This will also help with showing FixIts later. llvm-svn: 197805
* Modules: Let -fmodules-decluse ignore headers that aren't in a moduleDaniel Jasper2013-12-111-2/+6
| | | | | | | | | | | Includes might always pull in arbitrary header or data files outside of modules. Among others, this includes builtin includes, which do not have a module (story) yet. Also cleanup implementation of ModuleMap::findModuleForHeader() to be non-recursive. llvm-svn: 197034
* Changed ConditionValue argument to PPCallbacks If and Elif callbacks to be a ↵John Thompson2013-12-071-3/+3
| | | | | | 3-state enum. llvm-svn: 196648
* Allow string literals as module names.Daniel Jasper2013-12-061-1/+1
| | | | | | | | | | | | | | | | | | In order to make the migration to modules easier, it seems to be helpful to allow a 1:1 mapping between target names of a current build system and the corresponding C++ modules. As such targets commonly contain characters like "-". ":" and "/", allowing arbitrary quote-escaped strings seems to be a straightforward option. After several offline discussions, the precise mechanisms for C++ module names especially regarding submodules and import statements has yet to be determined. Thus, this patch only enables string literals as names inside the module map files which can be used by automatic module import (through #include). Also improve the error message on missing use-declarations. llvm-svn: 196573
* Enea Zaffanella's fix for the PPCallbacks Elif callback, with a slight ↵John Thompson2013-12-041-17/+15
| | | | | | re-org, and an update of the new PPCallbacks test (soon to be moved to clang from extra), rather the unittest. llvm-svn: 196407
* Fix corner case in module-based layering warning.Daniel Jasper2013-12-031-1/+2
| | | | | | | | | | | Before, there SourceManager would not return a FileEntry for a SourceLocation of a macro expansion (if the header name itself is defined in a macro). We'd then fallback to assume that the module currently being built is the including module. However, in this case we are actually interested in the spelling location of the filename loc in order to derive the including module. llvm-svn: 196311
* Documentation cleanup: Doxygen-ification, typo fixes, and changing some ofJames Dennett2013-11-271-15/+14
| | | | | | | the duplicated documentation from .cpp files so that it's not processed by Doxygen and hence doesn't generate duplicate output. llvm-svn: 195799
* Generate a marker token when entering or leaving a submodule when building aRichard Smith2013-11-231-10/+33
| | | | | | | | | module. Use the marker to diagnose cases where we try to transition between submodules when not at the top level (most likely because a closing brace was missing at the end of a header file, but is also possible if submodule headers attempt to do something fundamentally non-modular, like our .def files). llvm-svn: 195543
* When we hit a #include directive that maps to a module import, emit a tokenRichard Smith2013-11-151-5/+18
| | | | | | | | | | | | representing the module import rather than making the module immediately visible. This serves two goals: * It avoids making declarations in the module visible prematurely, if we walk past the #include during a tentative parse, for instance, and * It gives a diagnostic (although, admittedly, not a very nice one) if a header with a corresponding module is included anywhere other than at the top level. llvm-svn: 194782
* Lex: Require that '#' be followed by a macro parameter name when preceded by ↵David Majnemer2013-11-051-6/+1
| | | | | | | | | | | | | | | | | | '##' After lexing a '##', we would look ahead and check to see if it was followed by '__VA_ARGS__'. After doing so, we would then go ahead and lex the token. However we would fail in the case where the '##' was followed by a '#' followed by an identifier because we would have lexed the '#' separately from the identifier, bypassing our parameter validation logic. Instead, lex the tokens coming after the '##' later. This fixes PR17804. llvm-svn: 194059
* Allow a header to be part of multiple modules.Daniel Jasper2013-10-221-14/+14
| | | | | | | | | | | | | | | | | | | | This patch changes two things: a) Allow a header to be part of multiple modules. The reasoning is that in existing codebases that have a module-like build system, the same headers might be used in several build targets. Simple reasons might be that they defined different classes that are declared in the same header. Supporting a header as a part of multiple modules will make the transistion easier for those cases. A later step in clang can then determine whether the two modules are actually compatible and can be merged and error out appropriately. The later check is similar to what needs to be done for template specializations anyway. b) Allow modules to be stored in a directory tree separate from the headers they describe. Review: http://llvm-reviews.chandlerc.com/D1951 llvm-svn: 193151
* Per updates to D3781, allow underscore under ' in a pp-number, and allow ' ↵Richard Smith2013-09-261-0/+5
| | | | | | in a #line directive. llvm-svn: 191443
* Module use declarations (II)Daniel Jasper2013-09-241-23/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283
OpenPOWER on IntegriCloud