llvm-project/clang/test/Modules/Inputs/macros_left.h

@import macros_top;
#define LEFT unsigned long

#undef TOP_LEFT_UNDEF


#define LEFT_RIGHT_IDENTICAL int

#define LEFT_RIGHT_DIFFERENT2 float
#define LEFT_RIGHT_DIFFERENT3 float

#define LEFT_RIGHT_DIFFERENT float

#define FN_ADD(a,b) (a+b)
Use @import rather than @__experimental_modules_import, since the latter is rather a mess to type. llvm-svn: 169919 2012-12-12 06:11:52 +08:00			`@import macros_top;`
Rework the (de-)serialization of macros, as stored in MacroInfo*. Instead of simply dumping an offset into the current file, give each macro definition a proper ID with all of the standard modules-remapping facilities. Additionally, when a macro is modified in a subsequent AST file (e.g., #undef'ing a macro loaded from another module or from a precompiled header), provide a macro update record rather than rewriting the entire macro definition. This gives us greater consistency with the way we handle declarations, and ties together macro definitions much more cleanly. Note that we're still not actually deserializing macro history (we never were), but it's far easy to do properly now. llvm-svn: 165560 2012-10-10 07:05:51 +08:00			`#define LEFT unsigned long`

			`#undef TOP_LEFT_UNDEF`

Deserialize macro history when we deserialize an identifier that has macro history. When deserializing macro history, we arrange history such that the macros that have definitions (that haven't been #undef'd) and are visible come at the beginning of the list, which is what the preprocessor and other clients of Preprocessor::getMacroInfo() expect. If additional macro definitions become visible later, they'll be moved toward the front of the list. Note that it's possible to have ambiguities, but we don't diagnose them yet. There is a partially-implemented design decision here that, if a particular identifier has been defined or #undef'd within the translation unit, that definition (or #undef) hides any macro definitions that come from imported modules. There's still a little work to do to ensure that the right #undef'ing happens. Additionally, we'll need to scope the update records for #undefs, so they only kick in when the submodule containing that update record becomes visible. llvm-svn: 165682 2012-10-11 08:46:49 +08:00


			`#define LEFT_RIGHT_IDENTICAL int`
Diagnose the expansion of ambiguous macro definitions. This can happen only with modules, when two disjoint modules #define the same identifier to different token sequences. llvm-svn: 165746 2012-10-12 05:07:39 +08:00
Deserialize macro history when we deserialize an identifier that has macro history. When deserializing macro history, we arrange history such that the macros that have definitions (that haven't been #undef'd) and are visible come at the beginning of the list, which is what the preprocessor and other clients of Preprocessor::getMacroInfo() expect. If additional macro definitions become visible later, they'll be moved toward the front of the list. Note that it's possible to have ambiguities, but we don't diagnose them yet. There is a partially-implemented design decision here that, if a particular identifier has been defined or #undef'd within the translation unit, that definition (or #undef) hides any macro definitions that come from imported modules. There's still a little work to do to ensure that the right #undef'ing happens. Additionally, we'll need to scope the update records for #undefs, so they only kick in when the submodule containing that update record becomes visible. llvm-svn: 165682 2012-10-11 08:46:49 +08:00			`#define LEFT_RIGHT_DIFFERENT2 float`
			`#define LEFT_RIGHT_DIFFERENT3 float`
Diagnose the expansion of ambiguous macro definitions. This can happen only with modules, when two disjoint modules #define the same identifier to different token sequences. llvm-svn: 165746 2012-10-12 05:07:39 +08:00
			`#define LEFT_RIGHT_DIFFERENT float`
[preprocessor] Allow comparing two macro definitions syntactically instead 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 2013-04-04 01:39:30 +08:00
			`#define FN_ADD(a,b) (a+b)`