[cfe-dev] Warning options table

[Sebastian Redl]

Ted Kremenek wrote:
> Hi Sebastian,
>
> I think this is an excellent start!  On this topic I have a few
> thoughts I wanted to share as part of the discussion, as I also was
> planning on working on this very soon.  I apologize if I am repeating
> material here, as I cannot locate the original thread.
>
>
> We can probably make this a lot more declarative by using the TableGen
> type system and by using inherited values.  In this way warnings
> declare what groups they belong to instead of groups declaring what
> warnings belong in them.  I think this will lead to a far more
> succinct representation that is also less error prone.
>
> My thought on this approach is that groups are completely
> declarative.  There is no risk of not accidentally mentioning a
> warning in a separate group definition as the declaration of a warning
> and the declaration of what groups it belongs to are in the same
> spot.  It is also easier to instantly see if a warning is in a
> specific group.  We then can use the tablegen backend to determine
> what warnings are in a group.
>
> Thoughts?
That sounds very good. My only concern with this approach is that it
makes it difficult to have several overlapping hierarchies. That is,
aside from the main hierarchy (which will probably be used for the
Clang-internal component separation, but is of little interest to the
user), all other groups are basically enumerations of single warnings
(although declared the other way around). In other words, I can't make a
whole group part of another group.

Though I suppose I can do that simply with name equality, i.e.

def Warning1 : SemaWarning<"foo", "bar"> {
  let Group1 = 1;
}

def Group1 : WarningGroup<"group1", "blabla"> {
  let Group2 = 1;
}

where groups only need to be explicitly declared if they are actually
members of another group.

Thanks for the comments. I'll see what I can come up with in the way of
a generator over the weekend.

In the meantime, I have a question about the command line. I can think
of two ways of encoding warning options. Both have interesting problems.

1) One cl::opt option per warning, plus a special one for -Werror.
Pro: Automatically generates documentation for every warning. If I only
support GCC syntax (-Wfoo and -Wno-foo) the existing parser for
boolOrUnspec (or whatever it was called) is sufficient. If I only
support property syntax (-Wfoo=warn and -Wfoo=ignore) it is, too. I
probably need a custom parser if I want to support both.
Contra: May be too verbose in the description. Makes position
information hard to come by. In particular, I can't just walk through
the options in the order specified and enable and disable them as I go,
since I'd first have to query them all and sort them. I could probably
build a z-buffer like map of the position of the option that last
modified a warning, and ignore options that have a lower order. Example:
clang -Wall -Wno-cxx-compat -Wcxx-keyword
Suppose I first look at the All group, then at individual warnings, and
finally at custom sub-groups. Then I'd first find the -Wall option and
enable every warning, setting their z value to 1. While walking through
the individual warnings, I find the -Wcxx-keyword option and enable that
warning again, setting its z value to 3. Then I find the -Wno-cxx-compat
group and disable all warnings in that group, setting their z value to
2, except cxx-keyword, which has a higher z value.
That would work, but I feel that walking over every possible warning
option, instead of just those that were actually specified, may impose a
significant startup penalty.

2) One cl::opt for -W, with values being specially interpreted.
Pro: Tells me exactly which options were specified, and in which order.
This means I only need to look at those warnings that actually matter. I
can easily do custom stuff to the values easily.
Contra: One documentation block for all warnings. This means a very,
very long documentation string, and it has to be tblgenerated. I have to
do all the parsing myself, including special treatment of -Werror. It
conflicts with -Wl,foo and friends (are these ever given to clang?).

Ideas? Chris? Can I specify the options separately and still easily walk
them in order?

Sebastian