summaryrefslogtreecommitdiffstats
path: root/clang/lib/Lex
Commit message (Collapse)AuthorAgeFilesLines
...
* [modules] When building a module, make sure we don't serialize out ↵Argyrios Kyrtzidis2013-05-082-4/+12
| | | | | | | | | | | HeaderFileInfo for headers not belonging to the module. After r180934 we may initiate module map parsing for modules not related to the module what we are building, make sure we ignore the header file info of headers from such modules. First part of rdar://13840148 llvm-svn: 181489
* C++1y: Update __cplusplus to temporary value 201305L to allow detection of ↵Richard Smith2013-05-071-1/+13
| | | | | | | | | provisional C++1y support. Add __has_feature and __has_extension checks for C++1y features (based on the provisional names from the C++ features study group), and update documentation to match. llvm-svn: 181342
* Move PragmaCommentHandler to lib/Parse in preparation for calling SemaReid Kleckner2013-05-061-74/+1
| | | | | | | | | | | | | | Summary: No functionality change. The existing tests for this pragma only verify that we can preprocess it. Reviewers: rsmith CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D751 llvm-svn: 181246
* Lex: Fix quadratic behavior when unescaping _Pragma strings.Benjamin Kramer2013-05-041-5/+6
| | | | | | No functionality change. llvm-svn: 181114
* When building a module, forward diagnostics to the outer diagnostic consumer.Douglas Gregor2013-05-031-2/+3
| | | | | | | | | | | | | | | Previously, we would clone the current diagnostic consumer to produce a new diagnostic consumer to use when building a module. The problem here is that we end up losing diagnostics for important diagnostic consumers, such as serialized diagnostics (where we'd end up with two diagnostic consumers writing the same output file). With forwarding, the diagnostics from all of the different modules being built get forwarded to the one serialized-diagnostic consumer and are emitted in a sane way. Fixes <rdar://problem/13663996>. llvm-svn: 181067
* [Preprocessor] For the MacroExpands preprocessor callback, also pass the ↵Argyrios Kyrtzidis2013-05-036-133/+10
| | | | | | | | MacroArgs object that provides information about the argument tokens for a function macro. llvm-svn: 181065
* When looking for the module associated with one of our magical builtin ↵Douglas Gregor2013-05-021-18/+37
| | | | | | | | | | | | | | | headers, speculatively load module maps. The "magical" builtin headers are the headers we provide as part of the C standard library, which typically comes from /usr/include. We essentially merge our headers into that location (due to cyclic dependencies). This change makes sure that, when header search finds one of our builtin headers, we figure out which module it actually lives in. This case is fairly rare; one ends up having to include one of the few built-in C headers we provide before including anything from /usr/include to trigger it. Fixes <rdar://problem/13787184>. llvm-svn: 180934
* Only evaluate __has_feature(c_thread_local) and ↵Douglas Gregor2013-05-021-2/+4
| | | | | | __has_feature(cxx_thread_local) true when the target supports thread-local storage. llvm-svn: 180909
* [PCH] Fix memory leak related to deserialized MacroInfo objects.Argyrios Kyrtzidis2013-04-302-4/+11
| | | | | | | | | Deserialized MacroInfos were not destroyed and if their SmallVector did heap allocation, it was leaked. rdar://13768967 llvm-svn: 180771
* [libclang] Make sure the preable does not truncate comments.Argyrios Kyrtzidis2013-04-191-2/+15
| | | | | | rdar://13647445 llvm-svn: 179907
* Note that we support (and in fact have supported since the dawn of time itself)Richard Smith2013-04-191-2/+7
| | | | | | C++1y binary literals. llvm-svn: 179883
* C++11 support is now feature-complete.Richard Smith2013-04-191-1/+3
| | | | llvm-svn: 179861
* Fix off-by-one error in #pragma clang system_header.Jordan Rose2013-04-171-2/+3
| | | | | | | | | | | The system_header pragma (from GCC) is implemented using line notes in the source manager. However, a line note's line number specifies the number not for the current line, but for the next line. This was making all line numbers appear off by one after the pragma. Reported by Andy Gibbs, uncovered during r179677. llvm-svn: 179709
* Implemented #pragma GCC warning/error in the same mould as #pragma message.Andy Gibbs2013-04-171-61/+85
| | | | llvm-svn: 179687
* Parser support for #pragma clang __debug capturedTareq A. Siraj2013-04-161-0/+30
| | | | | | | | | | | | | | | This patch implements parsing ‘#pragma clang __debug’ as a first step for implementing captured statements. Captured statements are a mechanism for doing outlining in the AST. see http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-January/027540.html. Currently returns StmtEmpty Author: Andy Zhang <andy.zhang@intel.com> Differential Revision: http://llvm-reviews.chandlerc.com/D369 llvm-svn: 179614
* Improve the diagnostics of the number-reading preprocessor directives.Michael Ilseman2013-04-101-4/+6
| | | | | | | | | | | | | | The GNU line marker directive was sharing code with the #line directive, but some of the warnings/errors were reporting as #line directive diagnostics in both cases. Previously: #line 11foo1 ==> "#line directive requires a simple digit sequence" # 11foo1 ==> "#line directive requires a simple digit sequence" Now, we get: #line 11foo1 ==> "#line directive requires a simple digit sequence" # 11foo1 ==> "GNU line marker directive requires a simple digit sequence" llvm-svn: 179139
* [preprocessor] Minor optimization following r178671.Argyrios Kyrtzidis2013-04-031-2/+3
| | | | | | Don't bother looking for parameter index of 'B' token if 'A' is not a parameter. llvm-svn: 178699
* [preprocessor] Allow comparing two macro definitions syntactically instead ↵Argyrios Kyrtzidis2013-04-032-12/+28
| | | | | | | | | | | | | | of only lexically. Syntactically means the function macro parameter names do not need to use the same identifiers in order for the definitions to be considered identical. Syntactic equivalence is a microsoft extension for macro redefinitions and we'll also use this kind of comparison to check for ambiguous macros coming from modules. rdar://13562254 llvm-svn: 178671
* [Preprocessor] Remove PPMutationListener.Argyrios Kyrtzidis2013-03-271-3/+1
| | | | | | It's not used anymore. llvm-svn: 178106
* [modules] Re-enable the "ambiguous expansion of macro" warning.Argyrios Kyrtzidis2013-03-271-11/+10
| | | | | | | | | | Also update "test/Modules/macros.c" to test modified semantics: -When there is an ambiguous macro, expand using the latest introduced version, not the first one. -#undefs in submodules cause the macro to not be exported by that submodule, it doesn't cause undefining of macros in the translation unit that imported that submodule. This reduces macro namespace interference across modules. llvm-svn: 178105
* [Preprocessor/Modules] Separate the macro directives kinds into their own ↵Argyrios Kyrtzidis2013-03-267-180/+94
| | | | | | | | | | | | | | | | MacroDirective's subclasses. For each macro directive (define, undefine, visibility) have a separate object that gets chained to the macro directive history. This has several benefits: -No need to mutate a MacroDirective when there is a undefine/visibility directive. Stuff like PPMutationListener become unnecessary. -No need to keep extra source locations for the undef/visibility locations for the define directive object (which is the majority of the directives) -Much easier to hide/unhide a section in the macro directive history. -Easier to track the effects of the directives across different submodules. llvm-svn: 178037
* [PCH/Modules] De/Serialize MacroInfos separately than MacroDirectives.Argyrios Kyrtzidis2013-03-222-19/+33
| | | | | | | | | -Serialize the macro directives history into its own section -Get rid of the macro updates section -When de/serializing an identifier from a module, associate only one macro per submodule that defined+exported it. llvm-svn: 177761
* [modules] When a MacroInfo object is deserialized, allocate and store its ↵Argyrios Kyrtzidis2013-03-222-1/+15
| | | | | | submodule ID. llvm-svn: 177760
* <rdar://problem/13037793> Allow the names of modules to differ from the name ↵Douglas Gregor2013-03-211-8/+31
| | | | | | of their subdirectory in the include path. llvm-svn: 177621
* Documentation cleanup for MacroInfo.James Dennett2013-03-201-4/+4
| | | | | | | | | | | | | | * Clarify what MacroInfo::isBuiltinMacro means, as it really means something more like "isMagicalMacro" or "requiresProcessingBeforeExpansion" -- the macros defined in "<built-in>" are not considered built-in by this function; * Escape __LINE__ as \__LINE__ in Doxygen comments so that the underscores don't get replaced by *bold* output; * Turn comments in MacroInfo.cpp into non-Doxygen comments, so that they don't result in duplicated/badly formatted Doxygen output; * Clean up a bunch of \brief formatting, and add a \file comment for MacroInfo.h. llvm-svn: 177581
* <rdar://problem/12368093> Extend module maps with a 'conflict' declaration, ↵Douglas Gregor2013-03-201-18/+102
| | | | | | and warn when a newly-imported module conflicts with an already-imported module. llvm-svn: 177577
* <rdar://problem/10796651> Introduce configuration macros into module maps.Douglas Gregor2013-03-201-4/+75
| | | | | | | | | | | | | | | | | | | | | | Configuration macros are macros that are intended to alter how a module works, such that we need to build different module variants for different values of these macros. A module can declare its configuration macros, in which case we will complain if the definition of a configation macro on the command line (or lack thereof) differs from the current preprocessor state at the point where the module is imported. This should eliminate some surprises when enabling modules, because "#define CONFIG_MACRO ..." followed by "#include <module/header.h>" would silently ignore the CONFIG_MACRO setting. At least it will no longer be silent about it. Configuration macros are eventually intended to help reduce the number of module variants that need to be built. When the list of configuration macros for a module is exhaustive, we only need to consider the settings for those macros when building/finding the module, which can help isolate modules for various project-specific -D flags that should never affect how modules are build (but currently do). llvm-svn: 177466
* PR15539: Record "evaluating if/elif condition" flag in the right placeDavid Blaikie2013-03-182-2/+2
| | | | | | | The previous implementation missed the case where the elif condition was evaluated from the context of an #ifdef that was false causing PR15539. llvm-svn: 177345
* [Modules] Don't eagerly load and associate all the module header files.Argyrios Kyrtzidis2013-03-132-6/+25
| | | | | | | | | | | | | | In a module-enabled Cocoa PCH file, we spend a lot of time stat'ing the headers in order to associate the FileEntries with their modules and support implicit module import. Use a more lazy scheme by enhancing HeaderInfoTable to store extra info about the module that a header belongs to, and associate it with its module only when there is a request for loading the header info for a particular file. Part of rdar://13391765 llvm-svn: 176976
* [Modules] Resolve top-headers of modules lazily.Argyrios Kyrtzidis2013-03-131-1/+1
| | | | | | | | | | | This allows resolving top-header filenames of modules to FileEntries when we need them, not eagerly. Note that that this breaks ABI for libclang functions clang_Module_getTopLevelHeader / clang_Module_getNumTopLevelHeaders but this is fine because they are experimental and not widely used yet. llvm-svn: 176975
* Add -Wc99-compat warning for C11 unicode string and character literals.Richard Smith2013-03-111-6/+8
| | | | llvm-svn: 176817
* When lexing in C11 mode, accept unicode character and string literals, per C11Richard Smith2013-03-091-9/+13
| | | | | | 6.4.4.4/1 and 6.4.5/1. llvm-svn: 176780
* Handle _Pragma on a u8, u, or U string literal per the C11 specification. AlsoRichard Smith2013-03-092-25/+46
| | | | | | | | handle raw string literals here. C++11 doesn't yet specify how they will behave, but discussion on core suggests that we should just strip off everything but the r-char-sequence. llvm-svn: 176779
* After issuing a diagnostic for undefining or redefining a builtin macro,Richard Smith2013-03-061-9/+12
| | | | | | | | | continue parsing the directive rather than silently discarding it. Allowing undef or redef of __TIME__ and __DATE__ is important to folks who want stable, reproducible builds. llvm-svn: 176540
* Remove unused static variable.Douglas Gregor2013-03-051-4/+0
| | | | llvm-svn: 176535
* Preprocessor: don't consider // to be a line comment in -E -std=c89 mode.Jordan Rose2013-03-051-4/+7
| | | | | | | | | | | | | | | | | | | It's beneficial when compiling to treat // as the start of a line comment even in -std=c89 mode, since it's not valid C code (with a few rare exceptions) and is usually intended as such. We emit a pedantic warning and then continue on as if line comments were enabled. This has been our behavior for quite some time. However, people use the preprocessor for things besides C source files. In today's prompting example, the input contains (unquoted) URLs, which contain // but should still be preserved. This change instructs the lexer to treat // as a plain token if Clang is in C90 mode and generating preprocessed output rather than actually compiling. <rdar://problem/13338743> llvm-svn: 176526
* [preprocessor] Use MacroDirective in the preprocessor callbacks to make ↵Argyrios Kyrtzidis2013-02-246-41/+48
| | | | | | | | available the full information about the macro (e.g if it was imported and where). llvm-svn: 175978
* [libclang] Fix assertion hit when code-completing inside a function macro ↵Argyrios Kyrtzidis2013-02-221-2/+4
| | | | | | | | with more arguments than it should accept. llvm-svn: 175925
* [preprocessing record] Have the MacroDefinitions map point to the ↵Argyrios Kyrtzidis2013-02-221-9/+7
| | | | | | | | | | MacroDefinition object instead its index in the preprocessed entities vector. This is because the order of the entities in the vector can change in some (uncommon) cases. llvm-svn: 175907
* Preproceessor: fix #if skipping under -traditional-cpp.Jordan Rose2013-02-221-1/+1
| | | | | | | | | | | | When parsing directives within skipped #if blocks, we don't want to retain any whitespace. Previously we were just skipping comments, but it's not possible to skip comments and retain other whitespace. This change matches the usual behavior for parsing directives (i.e. the behavior outside of skipped #if blocks). <rdar://problem/13267695> llvm-svn: 175840
* Preprocessor: preserve whitespace in -traditional-cpp mode.Jordan Rose2013-02-212-26/+33
| | | | | | | | | Note that unlike GNU cpp we currently do not preserve whitespace in macros (even in -traditional-cpp mode). <rdar://problem/12897179> llvm-svn: 175778
* Include llvm::Optional in clang/Basic/LLVM.hDavid Blaikie2013-02-201-2/+2
| | | | | | Post-commit CR feedback from Jordan Rose regarding r175594. llvm-svn: 175679
* [preprocessor] Split the MacroInfo class into two separate concepts, ↵Argyrios Kyrtzidis2013-02-205-133/+102
| | | | | | | | | | | | | | | | | | | | | | | | | MacroInfo class for the data specific to a macro definition (e.g. what the tokens are), and MacroDirective class which encapsulates the changes to the "macro namespace" (e.g. the location where the macro name became active, the location where it was undefined, etc.) (A MacroDirective always points to a MacroInfo object.) Usually a macro definition (MacroInfo) is where a macro name becomes active (MacroDirective) but splitting the concepts allows us to better model the effect of modules to the macro namespace (also as a bonus it allows better modeling of push_macro/pop_macro #pragmas). Modules can have their own macro history, separate from the local (current translation unit) macro history; MacroDirectives will be used to model the macro history (changes to macro namespace). For example, if "@import A;" imports macro FOO, there will be a new local MacroDirective created to indicate that "FOO" became active at the import location. Module "A" itself will contain another MacroDirective in its macro history (at the point of the definition of FOO) and both MacroDirectives will point to the same MacroInfo object. Introducing the separation of macro concepts is the first part towards better modeling of module macros. llvm-svn: 175585
* [modules] Const'ify some functions of ModuleMap.Argyrios Kyrtzidis2013-02-191-12/+13
| | | | llvm-svn: 175552
* [preprocessing record] Add some sanity checks for the preprocessed entity indexArgyrios Kyrtzidis2013-02-121-4/+8
| | | | | | | | to make sure we don't crash on release if the index is not valid. rdar://13089714 llvm-svn: 175010
* Remove some stray uses of <ctype.h> functions.Jordan Rose2013-02-091-1/+2
| | | | | | These are causing assertions on some MSVC builds. llvm-svn: 174805
* Properly validate UCNs for C99 and C++03 (both more restrictive than C(++)11).Jordan Rose2013-02-092-89/+582
| | | | | | | | Add warnings under -Wc++11-compat, -Wc++98-compat, and -Wc99-compat when a particular UCN is incompatible with a different standard, and -Wunicode when a UCN refers to a surrogate character in C++03. llvm-svn: 174788
* Excise <cctype> from Clang (except clang-tblgen) in favor of CharInfo.h.Jordan Rose2013-02-084-26/+15
| | | | | | | Nearly all of these changes are one-to-one replacements; the few that aren't have to do with custom identifier validation. llvm-svn: 174768
* Simplify logic for avoiding concatenation after numeric constants.Jordan Rose2013-02-081-6/+5
| | | | | | | I threw in a couple of test cases for UD-suffixes -- already working, but it wasn't immediately obvious to me. llvm-svn: 174767
* Pull Lexer's CharInfo table out for general use throughout Clang.Jordan Rose2013-02-081-170/+5
| | | | | | | | | | | Rewriting the same predicates over and over again is bad for code size and code maintainence. Using the functions in <ctype.h> is generally unsafe unless they are specified to be locale-independent (i.e. only isdigit and isxdigit). The next commit will try to clean up uses of <ctype.h> functions within Clang. llvm-svn: 174765
OpenPOWER on IntegriCloud