[cfe-dev] clang-cc option change

[Daniel Dunbar]

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