tree f6b547c4fcc33ff4bae563473287cddfeff4e21c
parent 206f49966f66ad7cbfe3d37c14fa7e6e7410f3be
author Argyrios Kyrtzidis <akyrtzi@gmail.com> 1361321697 +0000
committer Argyrios Kyrtzidis <akyrtzi@gmail.com> 1361321697 +0000

[preprocessor] Split the MacroInfo class into two separate concepts, 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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175585 91177308-0d34-0410-b5e6-96231b3b80d8