This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: named warnings & individual warning control


> That's why I think that you need to get consensus on this issue before 
> you get too committed here.

That's what I'm trying to do, although I'd like to think we don't have
to do it all at once - we can agree on a design that provides some
advantages now and allows for whatever we agree on later.

> Actually, no.  Even worse is to have code that is hard to maintain in 
> the compiler, or to make promises to our users that we can't keep.

I meant worst for the user.  Of all the solutions where the user is
able to fix their problem, the one that causes the user the most grief
is where they edit gcc's sources to change the message reporting.

At least if a warning message changes, they can ask gcc what to do to
disable it.  For a source change, they have to find the new spot in
the source each time.

> In fact, I've done this exact same thing before on the exact same issue 
> in another compiler, and had precisely this problem: lots of unhappy 
> customers when the ids changed, even when we explicitly told them that 
> they would.

It sounds like you've defined the problem in such a way that it can't
possibly be solved.  I'm trying to find a compromise that gives us as
much of what the user needs with the least of the maintenance
problems, or at least lets the user hack it with a minimal effort.

> >* The user can still control warning groups from within the code
> >  (i.e. #pragma GCC message ignore format, #pragma GCC message error
> >  writable-strings, etc), even if such groupings are no more flexible
> >  than the set of -W options we currently offer.
>
> Yes, agreed; that, I think is non-controversial functionality.  Note 
> that you could do this without a central warning catalog.

I didn't say it was a *big* benefit ;-)

This particular feature is a freebie if you assume source control over
specific warnings, since groups are a generalization of those.

> >* Grouping of messages into command line options is centralized
> >  (leading to easier auditing, machine-generated documentation,
> >  reverse indexes, {user,target,language}-definable groups, etc).
>
> This is probably good -- although it was also true of my patch, and
> some people were very much opposed to not being able to just tweak
> the source code.

The message catalog is still part of the source code, no different
than (say) tree.def or target.md.

A catalog also allows for grouping to be defined in both directions -
a group can specify its messages, and a message can define the groups
it's in.  This allows either policy to be implemented without a code
change.

Also consider the question "what messages are controlled by -Wfoo?"

> >* Logic for deciding if a standard cares about a message, for example,
> >  can be moved out of the code (reducing code complexity there).  This
> >  may or may not be easier on the developer, but it allows for some
> >  standards auditing reports to be automatically generated.
>
> This is desirable -- but may not be easy; sometimes the same message 
> might result from undefined behavior in some cases but just a warning in 
> others.  I'm not sure.

All the more reason to separate "what happened" from "do we care".  If
the situations leading to that message are different, it's a different
message (probably in a group with the other message, of course) that
just happens to have the same text.  This is an argument *for* precise
control of messages.

> >* Deferring the categorization of a message as an error, warning, or
> >  whatnot - and thus treating them the same whenever possible - makes
> >  us (gcc developers) think about what MUST be an error and what only
> >  DEFAULTS to being an error.
> >  
> >
> Yes -- although given our current codebase it's very dangerous to relax 
> errors to warnings.

The dangerous ones shouldn't be relaxable, then.  And again, it makes
the developer think about it - and explicitly indicate if a condition
is dangerous or not.

> It's also a problem for backwards compatibility; sometimes what you
> could tolerate in one release is not the same as what you can
> tolerate in the next.

If there is a different API for the two cases, then such a change
would be more explicit, and more obvious to reviewers.  I think this
is a good thing.  Nothing I've proposed says that GCC can't (or
shouldn't) change, only that the mechanism for dealing with such
changes is more obvious, rather than being mixed in with user and std
preferences.

> In general, I agree with your benefits list -- but I think you need
> to get buy-in on the idea that centralizing the message database is
> a good thing.  For example, I think you need to get Jason to agree
> that he no longer objects to this -- or decide explicitly to ignore
> his objections. :-)

I did note that there wasn't a consensus about that ;-)

The obvious drawback to a central catalog is that adding a message
involves touching more files.  Grokking a single message is a bit more
complex, too.

The advantages of a central catalog is that we are no longer limited
to a single text offering for a message, certain automated tasks
become easier and/or possible , and it's easier to refer to a specific
message (should we decide to allow that).

> Note that you could get some of the same benefits by just adding the 
> #pragmas for the current warning groups, and by having calls to 
> "warning" take an optional group flag word, which you would then insert 
> at the call sites.  When warnings for that group were disabled, the 
> calls would return immediately.   I don't think there are any major user 
> interface impliciations of that; it's a clear win.  And, it doesn't have 
> the same maintenance or methodology implications for the rest of the 
> compiler.
> 
> I understand why that's not as atttractive from some other perspectives, 
> but I think it should be on the table as well.

With either design, we either (1) change the existing API and
mechanically edit the world, or (2) add a new function and migrate
calls as time permits.  I suggested a new message() function which
could call the exiting warn() or error(), but that's a tiny detail.

Either design allows for source-level control of warning groups, but
if we also want user-defined groups and the option of being more
specific in the future, let's plan for it now.  Neither plan is that
much work that the raw effort of coding is much of an argument for one
over the other.

And we could certainly use the message catalog design to only manage
the message groups and their supporting documentation, with the API
you suggest.  I like to design in flexibility for future changes
wherever practical.

Perhaps there would be more incentive to agree to future policy
changes if they could be implemented easily too ;-)

A compromise is to pass an ID and the text, allowing for specific
message IDs but initially passing group IDs.  The catalog would
initially contain only the grouping logic, tags, and possibly
alternate texts, although migrating the texts out to the catalog would
become more automatable with time as the IDs become more specific.  It
would also be easier to generate a report of which IDs are used in
more than one place (i.e. which are groups and which are specific
messages).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]