[cfe-dev] Driver support for AST features (UI Proposal)

[Daniel Dunbar]

On Tue, Sep 1, 2009 at 8:36 AM, Douglas Gregor<dgregor at apple.com> wrote:
> On Aug 31, 2009, at 10:51 PM, Daniel Dunbar wrote:
>> Eventually we will probably also want a feature '-write-ast' (or so)
>> which will output an AST while doing other things (like compiling),
>> but that is not part of this proposal.
>>
>> One salient design point is that the default suffix for AST files is
>> '.ast', which does not indicate the source language. This means the
>> driver won't be able to make decisions about things like code
>> generator options based on its language.
>
> If nothing else, we need to know when the AST file is a C++ file, so that we
> can link in the C++ standard library.

Actually, thats just based on the driver entry point (clang vs
clang++), not the language! Although one could argue that should
change...

>> I'm not sure yet if this
>> matters. If it did we would either (a) have to poke the .ast to figure
>> out its language, or (b) use -x with new options like c++-ast etc
>> (like for preprocessed inputs) and optionally use suffixes like
>> '.c-ast', '.cpp-ast', etc.
>
> We should poke the AST file for this information.

I agree, but its worth noting the downside of this is that the driver
would have to link in substantially more code (or use a custom method
to get the language, for example we could arrange the language to be
part of the file header).

>> A patch following this design is attached. The compile-ast option is
>> not implemented in clang, and I don't know exactly what model we want
>> for compile options passed to an ast -> .s compile step (most of them
>> are backed in the .ast, but not all of them).
>
> If we do nothing, we'll end up checking the AST-backed options (complaining
> when there are differences) and just passing the other compilation options
> through to CodeGen for generation of the .s file. That seems fine to me.

It's "fine", but its not ultimately what we want, I think. Consider
trying to build a Makefile system which would cache AST files, for
example. Or a 'ccache' mode which caches .ast files. It's much more
likely to want to pass 0 options to the compile-ast step, than have to
duplicate the options. That would require us to tuck some extra things
in the PCH.

Similarly, having the driver figure out just which options it should
pass for a compile-ast step and which have been subsumed is ugly and
error prone. My inclination is that we should just suck all the
options into the PCH, so that the driver can pass no options to a
compile-ast step. Then if there is a user request for some particular
option to be overrideable at the compile-ast stage, we can add that as
needed.

 - Daniel