[PATCH] clang-cl: add support for /? and /help

[Hans Wennborg]

On Thu, Jul 25, 2013 at 10:07 AM, Chandler Carruth <chandlerc at gmail.com> wrote:
>
> On Thu, Jul 25, 2013 at 9:46 AM, Hans Wennborg <hans at chromium.org> wrote:
>>
>>   > Second, a lot of my comments below are along the lines of "fix the
>> grouping of options we have to be rational, and then use that to do the
>> CL-opt-in". I think this is really important to make sure we get it right. I
>> suggest doing it now because I think it'll be fairly easy to do. If
>> something explodes into a lot of work, push back! =] I'm happy to convert
>> really hard stuff here to FIXMEs as long as you eventually fix them.
>>
>>   I think this is the big ticket item here. I'm not sure if by grouping
>> you mean changing the Group (f_Group, etc.) on the options, or you mean how
>> they are actually ordered in the file, or both.
>
>
> I'm not talking about how they are ordered in the file -- although feel free
> to re-order things in a way that helps make the file more readable.
>
>>
>>   I think the Group classes might be orthogonal to what we're trying to do
>> here. They're good for categorizing whether something is a debug or a
>> warning related option, etc., so that such options can be handled in one
>> place, but I don't think they would work for excluding or including options
>> in cl-mode vs gcc-mode. An option can only be in one Group (which can, I
>> think, be part of a larger Group), so we couldn't have options be part of
>> both a group_Debug and group_CL.
>>
>>   Flags are good for that, because they can cut across groups.
>>
>>
>>   I think reordering the options into "clang options, gcc compat options,
>> cl compat options, cc1 internal options" like you suggest in the comment
>> below sounds great. We should then be able to put flags on the options in a
>> straight-forward way (CLCompat, GCCComap, CC1Option) based on that ordering.
>
>
> I completely agree that flags are the way to organize what set the options
> go into. =] We're on the same page there.
>
> What I'm trying to say about groups is that currently, the hierarchical
> structure of the groups is both coarse and not thought out very well. I'm
> suggesting that there are specific, hierarchy forming (and thus compatible
> with the 1-group-only requirement), changes to the group which would
> subsequently allow us to quickly automated the application of flags to many
> of the options. For example, if we have a specific group for the diagnostic
> message controlling 'f' flags, we could immediately opt those into the clang
> options flag.

Thanks for clarifying. These are the issues I'm struggling with here:

I don't think there's a way to apply Flags to a Group in the .td. But
maybe there's TableGen magic to do accomplish this that I don't know
about.

I'm still worried about the group-to-flags mapping. Let's say we have
this f_diagnostics_Group with all the diagnostic message controlling
'f' flags, and we make all options in that group to have the CLOption
flag. Should both -fcolor-diagnostics and -fdiagnostics-color be in
the group? We don't want to expose the latter in clang-cl. Or should
we split the group into subgroups, f_diagnostics_core_Group and
f_diagnostics_compatibility_Group, and just put the flag on one of
them? Now the groups start to become messy because we're trying to
group both by function and by which compiler mode they should be in.
Or should we keep them in one group and try to selectively opt-out
some options in the group from the CLOption flag?

 - Hans