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

@import macros_top;
#define RIGHT unsigned short


#define LEFT_RIGHT_IDENTICAL int
#define LEFT_RIGHT_DIFFERENT int
#define LEFT_RIGHT_DIFFERENT2 int
#define LEFT_RIGHT_DIFFERENT3 int

#undef TOP_RIGHT_REDEF
#define TOP_RIGHT_REDEF float

#define FN_ADD(x, y) (x+y)

#undef TOP_OTHER_DEF_RIGHT_UNDEF
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 RIGHT unsigned short`

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

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
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`
			`#define LEFT_RIGHT_DIFFERENT int`
			`#define LEFT_RIGHT_DIFFERENT2 int`
			`#define LEFT_RIGHT_DIFFERENT3 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			`#undef TOP_RIGHT_REDEF`
			`#define TOP_RIGHT_REDEF 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(x, y) (x+y)`
If a module A exports a macro M, and a module B imports that macro and #undef's it, importers of B should not see the macro. This is complicated by the fact that A's macro could also be visible through a different path. The rules (as hashed out on cfe-commits) are included as a documentation update in this change. With this, the number of regressions in libc++'s testsuite when modules are enabled drops from 47 to 7. Those remaining 7 are also macro-related, and are due to remaining bugs in this change (in particular, the handling of submodules is imperfect). llvm-svn: 202560 2014-03-01 08:08:04 +08:00
			`#undef TOP_OTHER_DEF_RIGHT_UNDEF`