09c9e811de
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 |
||
|---|---|---|
| .. | ||
| arcmt-test | ||
| c-arcmt-test | ||
| c-index-test | ||
| clang-check | ||
| diag-build | ||
| diagtool | ||
| driver | ||
| libclang | ||
| scan-build | ||
| scan-view | ||
| CMakeLists.txt | ||
| Makefile | ||