This is the mail archive of the
mailing list for the GCC project.
Re: named warnings & individual warning control
> This is an attempt to provide feedback on your summary, w/o introducing
> additional opinions.
> > Some folks argue that the warning text should be in the source, others
> > note the benefits of having a machine-parsable warning catalog
> > (documentation, for example). Both sides agree that gettext() is the
> > i18n solution of choice.
> I thought the Hivemind had finally decided on the catalog approach.
> But possibly no consensus was reached.
It did seem that the bias was towards a catalog, at least in terms of
technical merit. There were arguments against, but it seemed like
they weren't backed with reasons as strong as the catalog approach.
What I didn't see what the catalog side convincing the in-source side
that a catalog was at least acceptable.
> I believe that was the consensus. It should be emphasized, in the
> user release notes, that "warning control" here refers to in-source
> control, not (necessarily?) command-line options.
Yes, how we document it will be key to setting user expectations
properly. However, I suspect a good design will give us both goals
simultaneously. It would certainly be bad to have TWO internal
message management schemes.
> I believe that was the consensus. There should also, if memory
> serves, be a tie-in to the other levels of diagnostics. Possibly
> also an in-source control on the warning threshold.
You mean "consider N warnings to itself be an error"?