[cfe-dev] clang-cc option change

[Daniel Dunbar]

An extra point I forgot to make, this also implies that clang-cc no
longer accepts llvm::cl options. I will add -mllvm if there proves to
be a need, but I also plan to fight against it. :)

 - Daniel

On Wed, Dec 2, 2009 at 8:10 PM, Daniel Dunbar <daniel at zuster.org> wrote:
> Hi all,
>
> As part of clang / clang-cc integration, I am about to switch clang-cc
> to using the new option parsing functionality, and drop the use of
> llvm::cl.
>
> This has a few implication you might want to be aware of:
>  1. The exact syntax accepted by clang-cc is becoming much stricter,
> and follows the clang (slash gcc driver) argument format. The most
> noticeable differences:
>    a. '-a' cannot automatically be spelled '--a'; if this is desired
> it must be explicit in the CC1Options.td file (using an alias).
>    b. Options which take arguments don't automatically accept the
> '-foo=bar', and this form is never allowed for boolean options. Some
> options are still allowed to be spelled as either '-foo bar' or
> '-foo=bar', but only because explicit aliases have been defined for
> them.
>
> If this fundamentally upsets you, we could change it by making the
> option parser more flexible. However, given that this matches how the
> driver works, it makes sense to me to have clang and clang -cc1 behave
> similarly.
>
>  2. Adding options is now totally different, and unfortunately a bit
> more cumbersome. I hope to make it less cumbersome over time, but
> until then feel free to swear at me under your breath when you go to
> add an option. The reason it is more cumbersome is because we have
> more functionality, namely the ability to serialize and deserialize a
> CompilerInvocation object to an argument vector.
>
> Previously, adding an option to clang-cc generally meant:
>  a. Add an entry in LangOptions or CodeGenOptions or whatever to
> persist the value.
>  b. Add an llvm::cl option definition.
>  c. Add some code in clang-cc.cpp (that code is now in Options.cpp) to
> take the llvm::cl value and stuff it into the field from (a).
>
> Now, adding an option to clang-cc (soon to be clang -cc1) looks like:
>  a. (same as above)
>  b. Add the option in include/clang/Driver/CC1Options.td
>  c. Add code to serialize the option in CompilerInvocation.cpp in the
> appropriate ParseFooArgs routine. That is, given a LangOptions
> structure, create the necessary command line arguments to regenerate
> the field. Generally this forces options to be simpler and more
> consistent -- if you require some logic be associated with your option
> then that logic should be in the Driver, not in clang-cc.
>  d. Add code to parse/deserialize the field from an argument vector,
> in the appropriate FooToArgs routine. Note that the OptParser library
> currently has less support for, say, interpreting enums, than llvm::cl
> which is one of the reasons this can be cumbersome.
>
> My eventual hope is to leverage the CC1Options.td file more so that
> the serialization / deserialization code is more automatic (and
> validated). The idea would be to keep the option definitions separate,
> but provide additional information on how they should be mapped onto a
> C++ structure. This might also be useful for defining parts of how the
> Driver maps command line arguments to Tools.
>
>  - Daniel
>