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

[Chandler Carruth]

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.

None of this should obviate the need to do some special marking of options
with a flag, but my hope is that it greatly reduces the number of them, and
lessens the maintenance burden of keeping things in sync.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130725/d5046315/attachment.html>