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


> This is an attempt to provide feedback on your summary, w/o introducing
> additional opinions.

Appreciated.

> > 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"?


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