Is is possible to use ParseAST() without adding the clang predefines?

dear cfe-list,

I use clang as general purpose parser, I'd like to be able to set the
predefines of other compilers instead of clang's ones.

But it seems that ParseAST() unconditionally calls DefineBuiltinMacro().
This adds macros that we could undefine (knowing their names), but it also
adds a typedef that is on the way. Is this avoidable?

Thanks,
pb

It isn't inconceivable that we would want clang to be able to mimic
other compilers as a general feature. Have you considered what would
be necessary for DefineBuiltinMacro to directly support compatibility
with whatever other compilers you are interested in?

- Daniel

Daniel Dunbar wrote:

It isn't inconceivable that we would want clang to be able to mimic
other compilers as a general feature. Have you considered what would
be necessary for DefineBuiltinMacro to directly support compatibility
with whatever other compilers you are interested in?

I am not sure I understand the question. What we do now is to undefine
(some of) the macros predefined by clang, and replace (some of) them with
the predefined macros of the other compiler. This works for macros,
but we have a problem because of the __builtin_va_list typedef:
we would want this to go away.

We are wondering if clang could be generalized so as to allow the
client application to decide what should be predefined and what not.
All the best,

   Roberto

Daniel Dunbar wrote:

It isn't inconceivable that we would want clang to be able to mimic
other compilers as a general feature. Have you considered what would
be necessary for DefineBuiltinMacro to directly support compatibility
with whatever other compilers you are interested in?

I am not sure I understand the question. What we do now is to undefine
(some of) the macros predefined by clang, and replace (some of) them with
the predefined macros of the other compiler. This works for macros,
but we have a problem because of the __builtin_va_list typedef:
we would want this to go away.

What I meant by my comment was that instead of finding a way to
refactor things that ParseAST doesn't end up calling
InitializePredefinedMacros, it may make more sense to add support in
DefineBuiltinMacros for other compilers; this could benefit all
clients. For example, pulling out the compiler specific predefines
into separate classes just as we do for targets.

We are wondering if clang could be generalized so as to allow the
client application to decide what should be predefined and what not.

__builtin_va_list poses a problem because other parts of clang are
relying on it to be present, I don't know this code well enough to
comment on how easy it would be to break that dependency (or enough
about how va_list is handled in other compilers).

- Daniel