Re: RFC: Named warnings

Re: RFC: Named warnings

[Robert Dewar]

> No, an implementor can add as many warnings as she wants.  The standards
> only dictate what must be diagnosed.
> 
> Regardless, what has that to do with my post?

I was responding to the comment that some warnings should be made into errors.
That is not a transformation that is up to the individual implementor.

Re: RFC: Named warnings

[Neil Booth]

Robert Dewar wrote:-

> I was responding to the comment that some warnings should be made into errors.
> That is not a transformation that is up to the individual implementor.

I didn't say that.  I said more of our warnings should be errors.  The
example I gave was

inline int x;

which is currently a warning, but nonsensical and a constraint
violation.  A good candidate for an error, in other words.

Neil.

Re: RFC: Named warnings

[Oscar Fuentes]

dewar@gnat.com (Robert Dewar) writes:

> > No, an implementor can add as many warnings as she wants.  The
> > standards only dictate what must be diagnosed.
> > 
> > Regardless, what has that to do with my post?
> 
> I was responding to the comment that some warnings should be made
> into errors.  That is not a transformation that is up to the
> individual implementor.

The C++ standard, IIRC, says nothing about "warning" or "error"
messages. It talks about "diagnostics". You can turn everything into
warnings, always generate an object file and you are ok as far as the
standard is concerned. What is a warning or an error is a QoI
issue. OTOH, a good C++ compiler reports far many more diagnostics
(errors and warnings) than the standard requires.

-- 
Oscar

Re: RFC: Named warnings

[Robert Dewar]

> For example, the current trigraph warnings explicitly contain the
> trigraph.  That's unnecessary when a caret is pointing right at it.
> Similarly for all the union/struct/enum separated diagnostics in the
> front end at the moment.

I would not be too hasty in this assessment. GNAT does an excellent job of
placing warnings in exactly the right place, but we still find most people
prefer to work in brief error message mode without the carets, so it is
still useful to have appropriate redundant insertions in the messages.

Re: RFC: Named warnings

[Robert Dewar]

> The C++ standard, IIRC, says nothing about "warning" or "error"
> messages. It talks about "diagnostics". You can turn everything into
> warnings, always generate an object file and you are ok as far as the
> standard is concerned. What is a warning or an error is a QoI
> issue. OTOH, a good C++ compiler reports far many more diagnostics
> (errors and warnings) than the standard requires.

Yes, but you must at least have a mode where you generate diagnostics
only for those things which C++ declares as wrong. I do not agree that
a good C++ compiler generates more errors than the standard requires.
This seems totally wrong to me. A program that is correct by the rules
of the C++ standard should be able to compile diagnostic free in any
decent compiler (typically by turning off warnings).

Re: RFC: Named warnings

[Oscar Fuentes]

dewar@gnat.com (Robert Dewar) writes:

> > The C++ standard, IIRC, says nothing about "warning" or "error"
> > messages. It talks about "diagnostics". You can turn everything into
> > warnings, always generate an object file and you are ok as far as the
> > standard is concerned. What is a warning or an error is a QoI
> > issue. OTOH, a good C++ compiler reports far many more diagnostics
> > (errors and warnings) than the standard requires.
> 
> Yes, but you must at least have a mode where you generate
> diagnostics only for those things which C++ declares as wrong.  I do
> not agree that a good C++ compiler generates more errors than the
> standard requires.  This seems totally wrong to me. A program that
> is correct by the rules of the C++ standard should be able to
> compile diagnostic free in any decent compiler (typically by turning
> off warnings).

I think the best way to address your above comments is to refer to the
standard itself. Do a text search for "no diagnostic required". You
will see why your view (which is quite reasonable) does not apply for
the C++ standard.

[This is off-topic for the gcc mailing list, so I propose that if you
are interested on further discussion we should switch to private mail
or some C++-related group]

-- 
Oscar

Re: RFC: Named warnings

[Robert Dewar]

> I didn't say that.  I said more of our warnings should be errors.  The
> example I gave was


OK, well if you are restricting this to warnings about extensions, we of
course have complete freedom to define them the way we want, though any
change in the implentation should be reflected in the documentation.

The mere fact that code is nonsensical does not mean that you can give
an error, if it is something that the standard does not proscribe.

Re: RFC: Named warnings

[Robert Dewar]

> Huh?

Whether something is a warning or not is dictated by the C and C++ standards,
it is not something that is up to the implementor.

Re: RFC: Named warnings

[Neil Booth]

Robert Dewar wrote:-

> > Huh?
> 
> Whether something is a warning or not is dictated by the C and C++ standards,
> it is not something that is up to the implementor.

No, an implementor can add as many warnings as she wants.  The standards
only dictate what must be diagnosed.

Regardless, what has that to do with my post?

Neil.

Re: RFC: Named warnings

[Bruce Korb]

> > Present code:
> > 
> >           /* Issue a warning if this is an ISO C 99 program or if -Wreturn-type
> >              and this is a function, or if -Wimplicit; prefer the former
> >              warning since it is more explicit.  */
> >           if ((warn_implicit_int || warn_return_type || flag_isoc99)
> >               && funcdef_flag)
> >             warn_about_return_type = 1;
> >           else if (warn_implicit_int || flag_isoc99)
> >             pedwarn_c99 ("type defaults to `int' in declaration of `%s'",
> >                          name);
> 
> I would think something like this:
> 
>         warn ("functions.retval.type-defaults", "...");
> 
> And somewhere *else* we figure out whether this warning should be
> enabled or not based on the c89/c99/pedantic/-W options.

Wouldn't this be simpler?

  /*=warn type-defaults-to-int
   * fmt:   "type defaults to `int' in declaration of `%s'"
   * group: pedantic isoc99 return-type funcdef
   * disabled:
   * doc:   No return type was specified for your procedure.
   *        You should type it explicitly to "int", if it returns an int,
   *        or set it to void if no value is returned.
  =*/
  WARN_TYPE_DEFAULTS_TO_INT( name );

And, elsewhere you have - generated - :

  #define WARN_ID_TYPE_DEFAULTS_TO_INT  <<some-number>>
  #define WARN_TYPE_DEFAULTS_TO_INT( a1 ) \
     if (warn_enabled[ WARN_ID_TYPE_DEFAULTS_TO_INT ]) \
         warning ("type defaults to `int' in declaration of `%s'", \
                   (a1) );

and a bit of initialization code that turns on the warnings related
to "pedantic", "isoc99", "return-type" and "funcdef" -- including
the entry for WARN_ID_TYPE_DEFAULTS_TO_INT

Re: RFC: Named warnings

[Bruce Korb]

Hi Stan,

> That's certainly my #1 implementation consideration - how to get there
> incrementally.  One of the things I'd want to set up would be some
> kind of auditing script that anybody could run to see how far along
> things are.  New warning controls should be made so they're an easy
> bit for newbies to add too.

I would like you to consider my toy for implementation.
Bundled with autogen is a comment extractor much akin to Java Doc
that should facilitate newbie use.  It could work something like this,
in the GCC source code:

  /*=warn mumble
   * fmt: "some sort of format string:  %d"
   * group: pedantic all
   * disabled:
   * doc:  why you got this warning
   *       and what you might do about it.
  =*/
  WARN_MUMBLE( arg );

From that, the following things could be made to happen:

1.  The "mumble" warning is normally disabled.  This would be accomplished
    inside the #define-d code for the WARN_MUMBLE macro.  Note that the
    WARN_MUMBLE takes one argument and that information can be derived by
    scanning the "fmt" string for formatting commands ("%d").

2.  It would be enabled if any of -Wmumble -Wall -Wpedantic were set
    on the command line

3.  An enumeration of all warnings would be emitted
    An array of warning states can be maintained via this enumeration,
    including push/pop/initial state/current state/whatever.

4.  A table to map warning names to the enumeration value would be emitted.

5.  If the "mumble" warning were needed elsewhere, it can be used there,
    just omit the special comment.

6.  For debugging purposes, the emitted WARN_MUMBLE macro could include
    the file and line number where it occurrs, and not for released code. :-)

7.  A "how-to-deal-with-this-warning" document.

8.  Additional attributes can be added, as the need arises.

Basically, you can take those several strings and arrange them into anything
you like.  Very conveniently.  I'll help, if you're interested.  I can't drive
it 'cuz I have a day job....

Re: RFC: Named warnings

[Robert Dewar]

> If a -Wxxx causes a warning to be issued in a particular file, then
> it is far easier and less contrived to edit that file and adds
> 
>    #pragma warning xxx [on|off]
> 
> around the offending code than find out the handbook and lookup the
> corresponding number.  We have to take ease of use into account.

That's exactly the gnat approach, except that the pragma is spelled

      pragma Warnings (On | Off);

Re: RFC: Named warnings

[Paolo Bonzini]

What
about -Werror-missing-prototype, -Wwarn-missing-prototype, -Wmissing-prototy
pe, -Wno-missing-prototype?  The third would base its behavior on
whether -Werror is specified.  This would avoid overloading -E which runs
cpp now.

Paolo

Re: RFC: Named warnings

[Stan Shebs]

Paolo Bonzini wrote:

>What
>about -Werror-missing-prototype, -Wwarn-missing-prototype, -Wmissing-prototy
>pe, -Wno-missing-prototype?  The third would base its behavior on
>whether -Werror is specified.  This would avoid overloading -E which runs
>cpp now.
>
-Efoo seemed most concise, plus it would stand out better when
reading a long compiler line.  Right now only -E by itself is
used, so there's not really an overloading problem.  But
-Werror- is sensible too, if people would prefer to go that way.

Stan

Re: RFC: Named warnings

[Jim Wilson]

>-Efoo seemed most concise, plus it would stand out better when
>reading a long compiler line.  Right now only -E by itself is
>used, so there's not really an overloading problem.

Only -E is used by gcc itself, but there many be some systems that use -Efoo
for assembler/linker options.  You have to check all gcc specs files to be
sure.

I see EB, EL, and Eb are in current use by some targets to specify endianness.
Otherwise, -Efoo seems safe.

Jim

Re: RFC: Named warnings

[Robert Dewar]

I must say my reaction is that the very fine control over warnings seems
a bit of overkill, but perhaps there is more of a problem with "bad" warnings
in g++ and gnu c than in gnat (I don't have the experience to make that
judgment). In GNAT, we group warnings under about 10 different categories
that can be separately controlled by either compile time switches or by
pragmas that can turn on and off these various categories of warnings.
In addition we have a general facility for turning warnings on and off
with pragmas (all warnings). This has proved quite adequate, and in fact
we have not had any requests at all to provide any more specific control.

The trouble with over-specific control is that warning messages are the
sort of thing that change frequently as they are improved and sharpened,
and you don't want to have people chasing after them by dealing with
new warning codes that now appear in the text of the program.

Re: RFC: Named warnings

[Michael S. Zick]

On Friday 24 January 2003 06:15 am, Robert Dewar wrote:
> I must say my reaction is that the very fine control over warnings seems
> a bit of overkill, but perhaps there is more of a problem with "bad"
> warnings in g++ and gnu c than in gnat (I don't have the experience to make
> that judgment). In GNAT, we group warnings under about 10 different
> categories that can be separately controlled by either compile time
> switches or by pragmas that can turn on and off these various categories of
> warnings. In addition we have a general facility for turning warnings on
> and off with pragmas (all warnings). This has proved quite adequate, and in
> fact we have not had any requests at all to provide any more specific
> control.
>
> The trouble with over-specific control is that warning messages are the
> sort of thing that change frequently as they are improved and sharpened,
> and you don't want to have people chasing after them by dealing with
> new warning codes that now appear in the text of the program.
>
The use of warning codes brings to mind a horrid image -

Numbered warnings could lead to the same sort of problems that are
present with changing ABI's -

The source might have to be preceeded by:
-Wversion=Oct-1802
or
-Wversion=Jan-2003

Just to get an old source (with an old warning scheme) through
a compiler with a new(?) warning scheme.

Mike

Re: RFC: Named warnings

[Andrea 'fwyzard' Bocci]

>The source might have to be preceeded by:
>-Wversion=Oct-1802

Wow ! This refers to a REALLY old source...
Didn't know we had GCC 201 years ago !

>or
>-Wversion=Jan-2003
>
>Just to get an old source (with an old warning scheme) through
>a compiler with a new(?) warning scheme.
>
>Mike

Re: RFC: Named warnings

[Robert Dewar]

> o I think consideration should be made to turning many current warnings
>   into errors.  This will reduce the number of warnings we need to
>   control.  My experience writing my C parser is that I've made many
>   things that were warnings into errors.  Sure, you can warn and do
>   the obvious thing to accept the translation unit, but I tend to
>   lean towards making errors of things that are easily avoided
>   and not stylistic.  e.g. "inline int x;" is currently a warning,
>   and IMO should be an error.  Existing warnings like the struct cpp_reader
>   one in prototypes should of course remain a warning, as there is
>   nothing actually syntactically or semantically incorrect about the usage.

This seems like something that should only be done with a switch, since it
is clearly non-standard. I suppose you could put this under -pedantic, but
in that case you had better be sure that your new "incorrect" errors do not
discombobulate too many correct programs.

Re: RFC: Named warnings

[Neil Booth]

Robert Dewar wrote:-

> > o I think consideration should be made to turning many current warnings
> >   into errors.  This will reduce the number of warnings we need to
> >   control.  My experience writing my C parser is that I've made many
> >   things that were warnings into errors.  Sure, you can warn and do
> >   the obvious thing to accept the translation unit, but I tend to
> >   lean towards making errors of things that are easily avoided
> >   and not stylistic.  e.g. "inline int x;" is currently a warning,
> >   and IMO should be an error.  Existing warnings like the struct cpp_reader
> >   one in prototypes should of course remain a warning, as there is
> >   nothing actually syntactically or semantically incorrect about the usage.
> 
> This seems like something that should only be done with a switch, since it
> is clearly non-standard. I suppose you could put this under -pedantic, but
> in that case you had better be sure that your new "incorrect" errors do not
> discombobulate too many correct programs.

Huh?

Neil.

RFC: Named warnings

[Stan Shebs]

This RFC proposes a uniform system for handling GCC's warnings, based
on the use of names to distinguish every type of warning.  A uniform
system would make every one of GCC's warnings individually
controllable, and enable the use of pragmas and/or attributes to
control warnings within a translation unit.  The following paragraphs
focus on requirements for user-visible behavior - once there is
agreement on the desired behavior, we can then consider how best to
implement.

One of GCC's strengths is the number and variety of its warnings,
which help users by alerting them to possible mistakes in their code,
even for code that is technically correct.  However, GCC's system of
warnings has evolved in a somewhat haphazard fashion.  While most
warnings can be enabled and disabled with a -Wfoo flag, others are
unconditional (such as most warnings relating to attributes), while
others are tied to generic options such as -pedantic, which have other
consequences and can thus be a problem to use.

So as a first step I propose that all of GCC's warnings be made
individually controllable, and that all future warnings always get a
control when they are added to the compiler.

As part of this individual control, each warning will get a unique
name, which consists of an alphanumeric string plus hyphens.  For
existing warnings with controls in the form of -W flags, the names
will correspond to the flag names, so -Wfoo-bar controls the warning
named "foo-bar".  There are no limits on the lengths of warning names,
but "no-" at the beginning of a name is reserved to indicate the
negation of the warning.  ("no-" would not be part of any warning's
name, irrespective of the warning's default value.)

It may still be that some warnings are composites, as with -Wunused,
which controls several other warnings that each have an individual
control, but this is up to the implementation.

It may also be that a single kind of warning will be displayed using
several different messages depending on context; if there is no
plausible reason for enabling one message but not the others, then
they can be combined into a single named warning.  (Since this sort of
merging defeats the purpose of individual control, it should be
uncommon.)

Another frequent request for warnings is that they be changeable
within a translation unit.  Sometimes this is because a warning has
been analyzed and is known to be uninteresting in a particular
context.  Another reason is that additional optimizations are possible
within a translation unit, as is visibility control for private
symbols, so it's undesirable to break one into several units just so
that a -Wno-foo can be applied to a part of the original translation
unit.  Last and perhaps least :-), this feature is provided by
competing compilers, and is expected by users bringing code over from
other platforms.

The obvious way to add fine-grained control is with attributes.  For
instance,

int fn() __attribute__ ((warning ("no-sign-compare", "switch")))
{
  ...
}

would say to warn about any missing cases in switch statements but not
any signed/unsigned conversions within the scope of fn.  The
attributes act as temporary overrides to the global values as
prescribed by compiler defaults and -W flags.  So that warnings' names
need not be constrained by language syntax, they should be expressed
as strings.

Attributes are useful for limiting effect to single functions or
variables, but are unduly repetitive for long files with many
functions and variables.  Pragmas would work better then, as in

#pragma GCC "no-sign-compare" "switch"
...
#pragma GCC "sign-compare" "switch" "missing-prototypes"

which disables signed/unsigned warnings and enables switch case
warnings, then later re-enables the sign warning and also the missing
prototype warning, but with no further effect on switch case warnings.

The effect of each pragma is a one-way change to the warnings listed.
(It would be possible to have warning control pragmas with a push/pop
behavior, but this seems excessive complicated, both to implement and
to use correctly.)

Finally, while -Werror is a useful option, it's difficult to use
reliably in portable software (as witness GCC's own recent travails)
because it affects all enabled warnings.  It just so happens that
-Efoo is not used for anything now, so I propose that -Efoo be defined
to work equivalently to -Wfoo -Werror for warning "foo" only.  There
are complexities with random combos like -Wfoo -Eno-foo -Wno-foo
-Efoo, and these need more thought before implementing.

For all of these extensions, not much additional documentation will be
needed, since it should suffice to document -Wfoo as always, and then
to direct users to remove the "-W" in order to know what names are
available for warning attributes and pragmas.

Stan

Re: RFC: Named warnings

[Zack Weinberg]

Stan Shebs <shebs@apple.com> writes:

> This RFC proposes a uniform system for handling GCC's warnings, based
> on the use of names to distinguish every type of warning.  A uniform
> system would make every one of GCC's warnings individually
> controllable, and enable the use of pragmas and/or attributes to
> control warnings within a translation unit.  

I support this initiative.  A couple of specific comments:

> Attributes are useful for limiting effect to single functions or
> variables, but are unduly repetitive for long files with many
> functions and variables.  Pragmas would work better then, as in
>
> #pragma GCC "no-sign-compare" "switch"
> ...
> #pragma GCC "sign-compare" "switch" "missing-prototypes"
...
> The effect of each pragma is a one-way change to the warnings listed.
> (It would be possible to have warning control pragmas with a push/pop
> behavior, but this seems excessive complicated, both to implement and
> to use correctly.)

First: that should be

#pragma GCC warning "name"...

as the convention is that pragmas are named.  Second, I think a spot
of syntactic sugar would be nice:

#pragma GCC warning [on|off] "name"...

This notation is compatible with the C99 standard pragmas, all of
which are of the form #pragma STDC foo (ON|OFF).  Your "no-foo"
convention can work too.

I agree we don't need a complete stack, but I think there should be a
way of saying 'go back to whatever was set by command line switches':
perhaps

#pragma GCC warning revert "name"...

Also to consider: if this pragma is used at block scope its effects
are reverted at the end of the block, just like the C99 standard
pragmas.

> Finally, while -Werror is a useful option, it's difficult to use
> reliably in portable software (as witness GCC's own recent travails)
> because it affects all enabled warnings.  It just so happens that
> -Efoo is not used for anything now, so I propose that -Efoo be defined
> to work equivalently to -Wfoo -Werror for warning "foo" only.  There
> are complexities with random combos like -Wfoo -Eno-foo -Wno-foo
> -Efoo, and these need more thought before implementing.

No objection in principle, but we do need to thrash out all the
complexities first.

Oh, we should get Phil's -Wextra patch in first (or did it finally get
approved?)

zw

Re: RFC: Named warnings

[Stan Shebs]

Zack Weinberg wrote:

>Stan Shebs <shebs@apple.com> writes:
>
>>Attributes are useful for limiting effect to single functions or
>>variables, but are unduly repetitive for long files with many
>>functions and variables.  Pragmas would work better then, as in
>>
>>#pragma GCC "no-sign-compare" "switch"
>>...
>>#pragma GCC "sign-compare" "switch" "missing-prototypes"
>>
>...
>
>>The effect of each pragma is a one-way change to the warnings listed.
>>(It would be possible to have warning control pragmas with a push/pop
>>behavior, but this seems excessive complicated, both to implement and
>>to use correctly.)
>>
>
>First: that should be
>
>#pragma GCC warning "name"...
>
Whoops, you're right!  So much for proofreading... :-)

>
>as the convention is that pragmas are named.  Second, I think a spot
>of syntactic sugar would be nice:
>
>#pragma GCC warning [on|off] "name"...
>
>This notation is compatible with the C99 standard pragmas, all of
>which are of the form #pragma STDC foo (ON|OFF).  Your "no-foo"
>convention can work too.
>
I thought about adding on/off, but it wasn't clear who it was supposed
to benefit.  I suppose a total IDE user might come in using checkboxes
for warnings, and never see the -Wfoo/-Wno-foo convention, so sure.

>
>I agree we don't need a complete stack, but I think there should be a
>way of saying 'go back to whatever was set by command line switches':
>perhaps
>
>#pragma GCC warning revert "name"...
>
That's a good idea!

>
>Also to consider: if this pragma is used at block scope its effects
>are reverted at the end of the block, just like the C99 standard
>pragmas.
>
>
That makes sense too.  You could end up with funny-looking repetition
though:

fn() {
#pragma GCC warning "no-missing-prototypes"
  ugly_system_code;
#pragma GCC warning "missing-prototypes"
  my_good_code;
}
#pragma GCC warning "missing-prototypes"

>>Finally, while -Werror is a useful option, it's difficult to use
>>reliably in portable software (as witness GCC's own recent travails)
>>because it affects all enabled warnings.  It just so happens that
>>-Efoo is not used for anything now, so I propose that -Efoo be defined
>>to work equivalently to -Wfoo -Werror for warning "foo" only.  There
>>are complexities with random combos like -Wfoo -Eno-foo -Wno-foo
>>-Efoo, and these need more thought before implementing.
>>
>
>No objection in principle, but we do need to thrash out all the
>complexities first.
>
Yup, just wanted to get all the chest-clutching out of the way
(hundreds of new options all at once!  Omigod, everything is spinning
and growing dark :-) )

Stan

Re: RFC: Named warnings

[Phil Edwards]

On Thu, Jan 23, 2003 at 05:27:00PM -0800, Zack Weinberg wrote:
> Stan Shebs <shebs@apple.com> writes:
> 
> > This RFC proposes a uniform system for handling GCC's warnings, based
> > on the use of names to distinguish every type of warning.  A uniform
> > system would make every one of GCC's warnings individually
> > controllable, and enable the use of pragmas and/or attributes to
> > control warnings within a translation unit.  
> 
> I support this initiative.

Ditto.

> Oh, we should get Phil's -Wextra patch in first (or did it finally get
> approved?)

Never did.  I'll post an updated version shortly.


-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: RFC: Named warnings

[Gabriel Dos Reis]

Phil Edwards <phil@jaj.com> writes:

| > Oh, we should get Phil's -Wextra patch in first (or did it finally get
| > approved?)
| 
| Never did.

How would that be different from -W ?

-- Gaby

Re: RFC: Named warnings

[Phil Edwards]

On Fri, Jan 24, 2003 at 08:39:19AM +0100, Gabriel Dos Reis wrote:
> Phil Edwards <phil@jaj.com> writes:
> 
> | > Oh, we should get Phil's -Wextra patch in first (or did it finally get
> | > approved?)
> | 
> | Never did.
> 
> How would that be different from -W ?

It isn't; that's the point.  One of the "beginner's projects" is to
rename -W (which doesn't communicate anything) to -Wextra (which does).
I had some free time one day and decided to knock that one off.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: RFC: Named warnings

[Gabriel Dos Reis]

Phil Edwards <phil@jaj.com> writes:

| On Fri, Jan 24, 2003 at 08:39:19AM +0100, Gabriel Dos Reis wrote:
| > Phil Edwards <phil@jaj.com> writes:
| > 
| > | > Oh, we should get Phil's -Wextra patch in first (or did it finally get
| > | > approved?)
| > | 
| > | Never did.
| > 
| > How would that be different from -W ?
| 
| It isn't; that's the point.  One of the "beginner's projects" is to
| rename -W (which doesn't communicate anything) to -Wextra (which does).

Aha, thanks! (I missed that project).  I vote for it.

-- Gaby

Re: RFC: Named warnings

[Joseph S. Myers]

On Thu, 23 Jan 2003, Stan Shebs wrote:

> It may also be that a single kind of warning will be displayed using
> several different messages depending on context; if there is no
> plausible reason for enabling one message but not the others, then
> they can be combined into a single named warning.  (Since this sort of
> merging defeats the purpose of individual control, it should be
> uncommon.)

This needs a better definition of what counts as the same or different
warnings.  (And some users will want finer control over certain instances
of a particular warning only - for example, removing pedantic format
warnings for %m only but not for other non-ISO-C formats.  So does the
warning for a format feature not in ISO C count as one warning with one
name, or many?)

> For all of these extensions, not much additional documentation will be
> needed, since it should suffice to document -Wfoo as always, and then

That's lots of additional documentation - detailing all of the hundreds
(maybe thousands - gcc.pot contains 4500 messages though many are hard
errors) of separate warning options.  (And testcases for all of them
should ideally be added in the process, I'm sure there are many warnings
that aren't exercised by the testsuite at all at present.)

If warnings get reorganised so that the available warning options change,
and warning options formerly available no longer have a meaningful
equivalent, what happens to users specifying those options?  (E.g., big
changes such as the new C++ parser are likely to change things enough that
various old warnings have only vague equivalents after the change.)

Do warnings for target attributes, built-in functions, etc., get 
target-specific warning-control options?

One thing not mentioned: a -W option to output warnings with their
individual names, so someone can use -Wall -Wwarning-names to see the name
of the one specific -Wall warning they want to disable.  (I don't think we
want warning codes cluttering output by default.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: RFC: Named warnings

[Stan Shebs]

Joseph S. Myers wrote:

>On Thu, 23 Jan 2003, Stan Shebs wrote:
>
>
>>It may also be that a single kind of warning will be displayed using
>>several different messages depending on context; if there is no
>>plausible reason for enabling one message but not the others, then
>>they can be combined into a single named warning.  (Since this sort of
>>merging defeats the purpose of individual control, it should be
>>uncommon.)
>>
>
>This needs a better definition of what counts as the same or different
>warnings.  (And some users will want finer control over certain instances
>of a particular warning only - for example, removing pedantic format
>warnings for %m only but not for other non-ISO-C formats.  So does the
>warning for a format feature not in ISO C count as one warning with one
>name, or many?)
>
I think those details still have to be up to the judgment of the GCC
developer.  Thinking ahead to implementation, it might be a good approach
to do this with a sort of on-demand recursive subdivision - lump all
non-ISO-format warnings together initially, then break them out if the
need arises.  You could even start with a -Wmisc that enables all
warnings that do not currently have a separate warning flag, start
subdividing from there. :-)

>
>>For all of these extensions, not much additional documentation will be
>>needed, since it should suffice to document -Wfoo as always, and then
>>
>
>That's lots of additional documentation - detailing all of the hundreds
>(maybe thousands - gcc.pot contains 4500 messages though many are hard
>errors) of separate warning options.  (And testcases for all of them
>should ideally be added in the process, I'm sure there are many warnings
>that aren't exercised by the testsuite at all at present.)
>
That's certainly my #1 implementation consideration - how to get there
incrementally.  One of the things I'd want to set up would be some
kind of auditing script that anybody could run to see how far along
things are.  New warning controls should be made so they're an easy
bit for newbies to add too.

>
>If warnings get reorganised so that the available warning options change,
>and warning options formerly available no longer have a meaningful
>equivalent, what happens to users specifying those options?  (E.g., big
>changes such as the new C++ parser are likely to change things enough that
>various old warnings have only vague equivalents after the change.)
>
I would hope that these are rare.  After all, you're talking about a
user-advertised feature that went away because the compiler internals
changed, which is kind of a poor practice.  Sociologically, I expect
that this will make implementors think a little harder about whether
a particular warning ought to be dumped out in the first place.

>
>Do warnings for target attributes, built-in functions, etc., get 
>target-specific warning-control options?
>
Yep.  They could written as -mWfoo or -Wmfoo. :-)  But seriously, the
implementation will need to be sufficiently declarative that a target
can drop in a set of target-specific warnings, check that they don't
conflict with generic warnings, etc.

>
>One thing not mentioned: a -W option to output warnings with their
>individual names, so someone can use -Wall -Wwarning-names to see the name
>of the one specific -Wall warning they want to disable.  (I don't think we
>want warning codes cluttering output by default.)
>
That's a really good idea, thanks!  That will save users from a round of
hunt-through-the-manual because they can't remember which messages
go with which warning flags.

Stan

Re: RFC: Named warnings

[Kai Henningsen]

shebs@apple.com (Stan Shebs)  wrote on 23.01.03 in <3E30CDBB.4000300@apple.com>:

> Joseph S. Myers wrote:

> >One thing not mentioned: a -W option to output warnings with their
> >individual names, so someone can use -Wall -Wwarning-names to see the name
> >of the one specific -Wall warning they want to disable.  (I don't think we
> >want warning codes cluttering output by default.)
> >
> That's a really good idea, thanks!  That will save users from a round of
> hunt-through-the-manual because they can't remember which messages
> go with which warning flags.

Ugh.

Strike -Wwarning-names. Do the effect always. Anything else leads to  
insanity. (And in fact that's how everybody else does it.)

MfG Kai

Re: RFC: Named warnings

[Matt Austern]

On Thursday, January 23, 2003, at 05:06  PM, Stan Shebs wrote:

> This RFC proposes a uniform system for handling GCC's warnings, based
> on the use of names to distinguish every type of warning.  A uniform
> system would make every one of GCC's warnings individually
> controllable, and enable the use of pragmas and/or attributes to
> control warnings within a translation unit.

Good idea!  It's also a necessary step if we ever want to do
more in the way of i18n.

> (It would be possible to have warning control pragmas with a push/pop
> behavior, but this seems excessive complicated, both to implement and
> to use correctly.)

Actually, my experience with other compilers is that this sort of thing
is very important.  EDG has a pragma to turn warnings on and off with
a push and pop mechanism, and I used it heavily in STL headers.  There
were a lot of times when I wanted to turn off a warning in a function
template, but, of course, turning it off for user code, just because a
user happened to include that header, would have been antisocial.  C++
headers have a lot of code in them, and it's important to be able to
control warnings for that code without interfering with warnings in the
headers' clients.

			--Matt

Re: RFC: Named warnings

[Gabriel Dos Reis]

Matt Austern <austern@apple.com> writes:

|                                                                    C++
| headers have a lot of code in them, and it's important to be able to
| control warnings for that code without interfering with warnings in the
| headers' clients.

GCC's -Wsystem-headers turns off warnings in "system headers"
(i.e. any file wih #pragam GCC system in it).

-- Gaby

Re: RFC: Named warnings

[Matt Austern]

On Thursday, January 23, 2003, at 11:43 PM, Gabriel Dos Reis wrote:

> Matt Austern <austern@apple.com> writes:
>
> |                                                                    
> C++
> | headers have a lot of code in them, and it's important to be able to
> | control warnings for that code without interfering with warnings in 
> the
> | headers' clients.
>
> GCC's -Wsystem-headers turns off warnings in "system headers"
> (i.e. any file wih #pragam GCC system in it).

That's a very important start, but don't forget that users who write
generic libraries have many of the same needs.  This isn't just for
libstdc++ implementers.  It's a more general concern: if I write a
C++ library I need to be able to control warning behavior for my
code without interfering with users of my library.

			--Matt

Re: RFC: Named warnings

[Neil Booth]

Hi Stan,

Stan Shebs wrote:-

> So as a first step I propose that all of GCC's warnings be made
> individually controllable, and that all future warnings always get a
> control when they are added to the compiler.

I support this in principle, but I think making each warning
controllable is too fine-grained.  For example, the C parser work I'm
doing emits many quite different warnings to the current parser.

o What do we do when a warning moves, disappears or becomes different?
o I agree with Matt that push / pop is necessary
o I think consideration should be made to turning many current warnings
  into errors.  This will reduce the number of warnings we need to
  control.  My experience writing my C parser is that I've made many
  things that were warnings into errors.  Sure, you can warn and do
  the obvious thing to accept the translation unit, but I tend to
  lean towards making errors of things that are easily avoided
  and not stylistic.  e.g. "inline int x;" is currently a warning,
  and IMO should be an error.  Existing warnings like the struct cpp_reader
  one in prototypes should of course remain a warning, as there is
  nothing actually syntactically or semantically incorrect about the usage.
o I'm a little concerned about how we do switch parsing.

FWIW I intend to create a lang-specific file "opts.def", a top-level
opts.def and a target-specific opts.def that are line-oriented awk-parsable
files containing the switches, help text and other relevant details
details about each switch (as is currently done in a big table in
c-opts.c, but with no help text).  Each line would be a field, and
each option a record, separated by a blank line.

cat-ting all these together at build time into an awk script that sorts
them and generates a header containing an enumeration, and a file with a
data table should be straight forward.  In this way, we can finally have
unified option handling outside the driver, with all options handled in
one place (and passed down to front-ends or back-ends via hooks).
The option handling code currently in c-opts.c is already generic enough
to do everything we need I think.

The only reason I've not started on this is I'm still trying to get
a copyright disclaimer out of my employer.  The changes should be fairly
straight-forward to do, just quite a lot of work.

> The obvious way to add fine-grained control is with attributes.  For
> instance,
> 
> int fn() __attribute__ ((warning ("no-sign-compare", "switch")))
> {
>  ...
> }

What I worry about here is are the attributes part of the function
type?  Or just something invisible to normal C rules on the decalarator?

> Finally, while -Werror is a useful option, it's difficult to use
> reliably in portable software (as witness GCC's own recent travails)
> because it affects all enabled warnings.  It just so happens that
> -Efoo is not used for anything now, so I propose that -Efoo be defined
> to work equivalently to -Wfoo -Werror for warning "foo" only.  There
> are complexities with random combos like -Wfoo -Eno-foo -Wno-foo
> -Efoo, and these need more thought before implementing.

If we do this, the option handling code could special-case the 'E' and
share the rest of the code, like it currently special-cases the "no-"
without doubling the number of switches.

Neil.

Re: RFC: Named warnings

[Kai Henningsen]

neil@daikokuya.co.uk (Neil Booth)  wrote on 24.01.03 in <20030124071454.GB19069@daikokuya.co.uk>:

> Stan Shebs wrote:-
>
> > So as a first step I propose that all of GCC's warnings be made
> > individually controllable, and that all future warnings always get a
> > control when they are added to the compiler.
>
> I support this in principle, but I think making each warning
> controllable is too fine-grained.

Getting that fine-grained control is one of the reasons - possibly *the*  
main reason - people are pushing for this feature!

> o I agree with Matt that push / pop is necessary

Yes, though it could at least partly be "hidden" by automatically doing it  
with the block structure.

> o I think consideration should be made to turning many current warnings
>   into errors.  This will reduce the number of warnings we need to
>   control.

I agree with whoever it was who said that warnings and errors shoiuld be  
handled as essentially the same thing in this.

MfG Kai

Re: RFC: Named warnings

[Phil Edwards]

On Fri, Jan 24, 2003 at 07:14:54AM +0000, Neil Booth wrote:
> FWIW I intend to create a lang-specific file "opts.def", a top-level
> opts.def and a target-specific opts.def that are line-oriented awk-parsable
> files containing the switches, help text and other relevant details
> details about each switch (as is currently done in a big table in
> c-opts.c, but with no help text).  Each line would be a field, and
> each option a record, separated by a blank line.

Yes, /please/.  The split between *-opts.c and */lang-options.h is just
annoying, and unnecessary.

Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: RFC: Named warnings

[Geert Bosch]

On Friday, Jan 24, 2003, at 02:14 America/New_York, Neil Booth wrote:

> Stan Shebs wrote:-
>
>> So as a first step I propose that all of GCC's warnings be made
>> individually controllable, and that all future warnings always get a
>> control when they are added to the compiler.
>
> I support this in principle, but I think making each warning
> controllable is too fine-grained.  For example, the C parser work I'm
> doing emits many quite different warnings to the current parser.

One important argument against controlling individual warnings is
readability of source code. Exact warning messages tend to change
a lot: one overly generic warning may be split in two more specific
ones, for example.

Having very specific pragmas to control each individual warning
will lead to a lot of clutter in sources that needs to be updated
when switching compiler versions.

   -Geert

Re: RFC: Named warnings

[Mark Mitchell]

--On Thursday, January 23, 2003 05:06:16 PM -0800 Stan Shebs 
<shebs@apple.com> wrote:

> As part of this individual control, each warning will get a unique
> name, which consists of an alphanumeric string plus hyphens.

Overall, I think your proposal is fine, and I like the ideas about
attributes.

I think the one sentence quoted above is a mistake.  I know people
don't like numbers, but I think numbers are actually better here.

Some of the objections have been:

- The numbers will change.

  But, actually, they won't.  It's not hard to keep from changing
  them, and I've worked on multiple compilers that had no trouble
  keeping the numbers the same.

- The numbers aren't mnemonic.

  True, but how mnemonic are the literally hundreds of warnings in
  the C++ front end going to be as foo-bar-baz strings?

  The way people actually use this feature in other compilers is like
  this:

  (1) Run the compiler.
  (2) Look at the warnings.
  (3) Note that a particular warning isn't making sense for their
      code.
  (4) Insert a #pragma/attribute/comment to turn it off.

  Since steps 3/4 come together, something like:

    warning [123]: You're a moron, Mark.

  is easily dealt with; you copy the "123" into your code.

  I'm not sure that:

    warning [moron-mark]: You're a moron, Mark.

  is going to be very friendly if that foo-bar-baz string gets long,
  and if it's not present then it's a pain in the neck to find the
  supposedly mnemonic string.

So, in favor of numbers:

- They're shorter.

- They're language-independent.

  GCC could have a manual section, like many other compilers, listing
  all the warnings in numberical order with a description of what each
  warning (and error) is about.

In any case, it would be a good idea to include errors in your scheme.

Also, some errors should have the ability to be turned into warnings
(that's what -fpermissive does in C++, for example), and all warnings
should have the ability to be turned into errors.  It makes sense
to name/number *all* diagnostics, if for no other reason than
easier documentation in the manual.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: RFC: Named warnings

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

| So, in favor of numbers:

[...]

| - They're language-independent.

I disagree.  *Some* warnings are language-independent -- thery are
usually triggered by middle- or back-end.  Others are highly
language-dependent.   Trying to make a number means different warnings
depending on the selected language is very confusing.

Named warnins has the advantages to be more self-descriptive than
numbers.   Computers are very good at that.  I fear only a very
limited number of humans are equally good at that. 

-- Gaby

Re: RFC: Named warnings

[Kai Henningsen]

gdr@integrable-solutions.net (Gabriel Dos Reis)  wrote on 24.01.03 in <m3d6mm52g3.fsf@uniton.integrable-solutions.net>:

> Mark Mitchell <mark@codesourcery.com> writes:
>
> [...]
>
> | So, in favor of numbers:
>
> [...]
>
> | - They're language-independent.
>
> I disagree.  *Some* warnings are language-independent -- thery are
> usually triggered by middle- or back-end.  Others are highly
> language-dependent.   Trying to make a number means different warnings
> depending on the selected language is very confusing.

I read Mark as meaning human-language independent, not computer-language  
independent.

> Named warnins has the advantages to be more self-descriptive than
> numbers.   Computers are very good at that.  I fear only a very
> limited number of humans are equally good at that.

Well, all the programs I remember using that had named messages with  
(relatively) short alphanumeric labels - *all* of them - used only or  
mainly numbers (often with a short letter pre- and/or postfix to indicate  
product and severity). Of course, there was still the usual text in those  
messages, too.

And if there *is* a master message list in the docs, I have trouble  
imagining a situation where the lack of self-description in those  
identifiers would be any kind of trouble - if I need to use a number,  
either it's in a compiler message I'm already staring at, or it's in a  
Makefile or source file (and I can look up the message in the docs) ... or  
if I'm looking for the number without any of these, I'd need that master  
list in any case because however mnemonic, I'll not know all of them by  
heart.

Remember, this is the way errno works (except the master list is usually  
in an inconvenient place, like something included by errno.h or the source  
to strerror). People are *used* to this kind of interface.

Oh, and when you put something like the usual warning option names in the  
warnings, those already long lines can get significantly longer. That's  
bad UI design.

MfG Kai

Re: RFC: Named warnings

[Gabriel Dos Reis]

kaih@khms.westfalen.de (Kai Henningsen) writes:

[...]

| > Named warnins has the advantages to be more self-descriptive than
| > numbers.   Computers are very good at that.  I fear only a very
| > limited number of humans are equally good at that.
| 
| Well, all the programs I remember using that had named messages with  
| (relatively) short alphanumeric labels - *all* of them - used only or  
| mainly numbers (often with a short letter pre- and/or postfix to indicate  
| product and severity). Of course, there was still the usual text in those  
| messages, too.

Well, I just go take the first program someone sent me (constructing
surfaces with varoous geometrical properties) and got all sorts fo
#pragma xxxx springled all over th files with things like 

   #if defined(__sgi) && !defined(__GNUG__)
   #pragma set woff 1209
   #endif

the pragma number varies from one point to the other.  That does not
tell anything about the supposed effect.  On the contrary, a named
warning might be more descriptive.  The above isn't a "feature" I would
like GCC to replicate.

And if the numbers would have to be accompanied with text, then it is
far better to put the next in the pragma in the first place.

[...]


| Remember, this is the way errno works (except the master list is usually  

But, I didn't say I find the way errno works really an examplar
that should be replicated.

-- Gaby

Re: RFC: Named warnings

[Fergus Henderson]

On 24-Jan-2003, Kai Henningsen <kaih@khms.westfalen.de> wrote:
> And if there *is* a master message list in the docs, I have trouble  
> imagining a situation where the lack of self-description in those  
> identifiers would be any kind of trouble - if I need to use a number,  
> either it's in a compiler message I'm already staring at, or it's in a  
> Makefile or source file (and I can look up the message in the docs) ...

The point is that in order to understand the Makefile or source file,
you may often need to look up the message in the docs, rather than the
meaning being just obvious from the name.

For example, what do you think the pragma in the following code does?
This is from win32_threads.c in the Boehm GC:

	# ifdef _MSC_VER
	#   pragma warning(disable:4715)
	# endif
	ptr_t GC_current_stackbottom()
	{
	  DWORD thread_id = GetCurrentThreadId();
	  int i;
	  for (i = 0; i < MAX_THREADS; i++)
	    if (thread_table[i].stack && thread_table[i].id == thread_id)
	      return thread_table[i].stack;
	  ABORT("no thread table entry for current thread");
	}
	# ifdef _MSC_VER
	#   pragma warning(default:4715)
	# endif

Well, looking at the code it's actually pretty easy to guess this one.
But suppose I change the code so that rather than aborting, it returns
a null pointer value.  Should I delete or modify the pragmas?

> Remember, this is the way errno works (except the master list is usually  
> in an inconvenient place, like something included by errno.h or the source  
> to strerror). People are *used* to this kind of interface.

No, for errno values people use codes like ENOMEDIUM rather than
numbers like 123.  ENOMEDIUM is a a lot more mnemonic.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: RFC: Named warnings

[Joseph S. Myers]

On 24 Jan 2003, Gabriel Dos Reis wrote:

> I disagree.  *Some* warnings are language-independent -- thery are
> usually triggered by middle- or back-end.  Others are highly
> language-dependent.   Trying to make a number means different warnings
> depending on the selected language is very confusing.

But, whatever scheme is used, some effort should be made to use the same 
code for warnings in the C and C++ front ends that are in some sense the 
same warning (possibly differently worded).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: RFC: Named warnings

[Gabriel Dos Reis]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

| On 24 Jan 2003, Gabriel Dos Reis wrote:
| 
| > I disagree.  *Some* warnings are language-independent -- thery are
| > usually triggered by middle- or back-end.  Others are highly
| > language-dependent.   Trying to make a number means different warnings
| > depending on the selected language is very confusing.
| 
| But, whatever scheme is used, some effort should be made to use the same 
| code for warnings in the C and C++ front ends that are in some sense the 
| same warning (possibly differently worded).

Surely, just like the current -Wxxx scheme works.  However having
12367 means "don't  derive from this class" in C++ whereas it means
"don't accept COMMON" in FORTRAN is really confusing.

-- Gaby

Re: RFC: Named warnings

[Mark Mitchell]

--On Friday, January 24, 2003 10:20:28 AM +0100 Gabriel Dos Reis 
<gdr@integrable-solutions.net> wrote:

> | - They're language-independent.
>
> I disagree.  *Some* warnings are language-independent -- thery are

Sorry; I was unclear.  I meant that *numbers* are natural-language
independent; "743" is the same number in French and German, but
"mark-moron" might only be sensible in English.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: RFC: Named warnings

[Stan Shebs]

Mark Mitchell wrote:

>
> --On Friday, January 24, 2003 10:20:28 AM +0100 Gabriel Dos Reis 
> <gdr@integrable-solutions.net> wrote:
>
>> | - They're language-independent.
>>
>> I disagree.  *Some* warnings are language-independent -- thery are
>
>
> Sorry; I was unclear.  I meant that *numbers* are natural-language
> independent; "743" is the same number in French and German, but
> "mark-moron" might only be sensible in English.
>
Last week in a related thread I made a joke about having a -W flag
using a German version of the warning, and got mail from two
different German speakers saying "please don't do that".

I spent a long time thinking about numbers vs names.  In a sense,
they're not really that different - both are bit strings that we
want to use as shorthand for the full description of a problem.
Numbers tend to be shorter, which is good for conciseness, although
if we have to carve out ranges for different languages, release
branches, etc, then they're not that much shorter.

Being shorter also means being denser, which means more chance of
mistakes - -W4536 could easily be mis-typed as -W4356, while there's
little chance that -Wmissing-prototypes and -Wconversion will be
mixed up.  That to me was one of GCC's innovations - back in the
mid-80s it was kind of radical for a Unix tool to use more than one
character for an option, and option names like -fomit-frame-pointer
seemed positively extravagant when -F was still available. :-)

My strongest reason for preferring names is that they can carry more
information and thus include some self-documentation.

However, it should not be a difficult enhancement to allow synonyms
for diagnostics, and thus make it possible to have a table of short
all-digit names alongside longer alphabetic names.  Then we can see
which users prefer in real life.

Stan

Re: RFC: Named warnings

[DJ Delorie]

Why not adopt what CSS and Xt do?  Have a mnemonic but heirarchical
system of naming and categorizing warnings, and let the user specify
any part of the warning to select it?  That automatically segregates
the language front ends, standards, and targets; and gives us grouping
functionality.  It also allows us to isolate the logic for selecting
warnings if we treat them as "just strings" (i.e. allows for future
creation of a ".gccrc").  Example:

Warnings:

	std.c99.proto.missing
	std.c99.proto.cast
	std.c99.proto.implicit
	std.c99.enum.foo
	lang.c++.proto.class
	lang.c.proto.implicit

Command line options (or pragmas):

	-Wproto
	-Wno-class  (no pun intended)
	-Wstd.c99
	-Wno-c.proto

GCC's code would go from this:

	if (warn_missing_protos)
	  warn ("missing prototype: %s", foo);

to this:

	warn ("std.c99.proto.missing", "missing prototype: %s", foo);

Or potentially (although I don't like this idea):

	warn (".proto.missing", "missing prototype: %s", foo);

(so one could say "this warning is independent of standards, langs,
 etc" but let the user use -Wstd.c99 to enable/disable it, if the
 warning is as listed above).

As for telling the user what the warnings are, perhaps a gcc option
"-fverbose-warnings" would add the warning spec to the warning
message?

	foo.c:45: Warning: missing prototype: foo
	foo.c:45: Warning[std.c99.proto.missing]: missing prototype: foo

Also, by specifying the warnings as a string in the warn() call, we
could write software to scan the sources and summarize all the
available warnings.  We could even specify a comment format, to
preceed the first (or main) occurrence of a warn() call, to document
them:

	/* warning[std.c99.proto.missing]
	   ...fill in docs...
	*/

We could also handle the "warning classes" (like -Wextra) in the
isolated logic for managing the warnings, perhaps
with some table like this (ignore the syntax):

	std.extra = {
	  std.c99.enum.foo
	  lang.c.proto.implicit
	}

So then -Wstd.extra (or just -Wextra) would enable those warnings as
if they user had listed them all.

Re: RFC: Named warnings

[Joseph S. Myers]

On Fri, 24 Jan 2003, DJ Delorie wrote:

> Why not adopt what CSS and Xt do?  Have a mnemonic but heirarchical
> system of naming and categorizing warnings, and let the user specify

Warnings aren't so simple and hierarchical.

> warnings if we treat them as "just strings" (i.e. allows for future
> creation of a ".gccrc").  Example:

I'm sure we do not want a .gccrc, for the sake of avoiding yet _more_ but
reports lacking vital information about how the compiler was used.  
Anyone who thinks they want a .gccrc probably wants "make", a wrapper
script or an IDE instead.

> 	warn ("std.c99.proto.missing", "missing prototype: %s", foo);

I will, however, discuss implementation possibilities for some of the less
straightforward cases in the C front end.

Present code:

          /* Issue a warning if this is an ISO C 99 program or if -Wreturn-type
             and this is a function, or if -Wimplicit; prefer the former
             warning since it is more explicit.  */
          if ((warn_implicit_int || warn_return_type || flag_isoc99)
              && funcdef_flag)
            warn_about_return_type = 1;
          else if (warn_implicit_int || flag_isoc99)
            pedwarn_c99 ("type defaults to `int' in declaration of `%s'",
                         name);

[separate function]

  if (warn_about_return_type)
    pedwarn_c99 ("return type defaults to `int'");

I don't know why this warning is delayed that way, but clean control 
probably requires that it isn't.  pedwarn_c99 gives a pedwarn in C99 mode 
(which becomes an error with -pedantic-errors) but just a warning in C90 
mode.  The code might become

  if (funcdef_flag)
    maybe_warning ("implicit-int-return-type;implicit-int,return-type,c99-constraint",
                   "return type defaults to `int'");
  else
    maybe_warning ("implicit-int-not-return-type;implicit-int,c99-constraint",
                   "type defaults to `int' in declaration of `%s'",
                   name);

Here, implicit-int-return-type and implicit-int-not-return-type identify 
the individual warning.  implicit-int, return-type and c99-constraint are 
warning classes.  c99-constraint means the warning is enabled if 
flag_isoc99 (no need for pedantic) and in that case becomes an error if 
-pedantic-errors.  There would be corresponding c99-constraint-pedantic 
(similar, but only if -pedantic), and c90-constraint, c-constraint (for 
all C versions), ..., and also such oddities as c90-warning-pedantic (for 
those cases that are warning(), not pedwarn(), because the code can appear 
in a valid program if it never gets executed.

If implicit-int-return-type has been specified, that overrides what the
classes of warnings determine about whether it is enabled or disabled.  
If the condition for c99-constraint is satisfied (i.e., C99 mode and that
class not being disabled), the warning becomes an error with 
-pedantic-errors (which has the effect of turning warnings in certain 
classes into errors).

Any good implementation system should avoid the need for special functions 
such as pedwarn_c99.

As another example,

                      if (pedantic && !flag_isoc99 && ! in_system_header
                          && warn_long_long)
                        pedwarn ("ISO C90 does not support `long long'");

might become

  maybe_warning ("long-long-decl;long-long", "ISO C90 does not support `long long'");

where long-long is the class of warnings presently controlled by 
-Wno-long-long, and is a subclass of c90-constraint-pedantic.  (I'm 
supposing that simple subclass relations are specified somewhere 
centrally.  This also means that -Wall doesn't need mentioning at 
individual warning sites; it only serves to enable other classes of 
warnings or individual warnings.)

-Wc89 / -Wc90 would enable the warnings in classes c90-constraint and
c90-constraint-pedantic irrespective of standard mode.  Properly, it would
do so without turning them into errors with -pedantic-errors; that is,
each class, as well as each individual warning, could be enabled in or out
of -Werror mode, and an enabled warning becomes an error if -Werror is
enabled for that warning, or for any class containing it (and not disabled
by a subclass).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: RFC: Named warnings

[DJ Delorie]

> Warnings aren't so simple and hierarchical.

I think perhaps the types of warnings are, but the reason for enabling
them aren't.

> I'm sure we do not want a .gccrc, ...

Perhaps what we should support is that people have a "warnings.h"
that's chock full of pragmas for the project's warnings, then.  But
then you get into the issue of which takes precedence: the command
line or the pragma.

> Present code:
> 
>           /* Issue a warning if this is an ISO C 99 program or if -Wreturn-type
>              and this is a function, or if -Wimplicit; prefer the former
>              warning since it is more explicit.  */
>           if ((warn_implicit_int || warn_return_type || flag_isoc99)
>               && funcdef_flag)
>             warn_about_return_type = 1;
>           else if (warn_implicit_int || flag_isoc99)
>             pedwarn_c99 ("type defaults to `int' in declaration of `%s'",
>                          name);

I would think something like this:

	warn ("functions.retval.type-defaults", "...");

And somewhere *else* we figure out whether this warning should be
enabled or not based on the c89/c99/pedantic/-W options.

The "somewhere else" would have a table like this:

std.c99.pedantic = {
  functions.retval.type-defaults
}
std.c90 = {
  functions.retval.type-defaults
}

Or maybe allow attributes based on context:

std.c99 = {
  foo.bar
  functions.retval.type-defaults (pedantic)
  keywords.inline (error)
}

Re: RFC: Named warnings

[Joseph S. Myers]

On Fri, 24 Jan 2003, DJ Delorie wrote:

> 	warn ("functions.retval.type-defaults", "...");
> 
> And somewhere *else* we figure out whether this warning should be
> enabled or not based on the c89/c99/pedantic/-W options.

That's what I want to avoid - I want it to be clear from reading the code
whether it is correct in terms of giving the appropriate warnings for the
standard version (and errors with -pedantic-errors), not depend on a huge
list elsewhere of which warnings are constraints in which standards being
correct.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: RFC: Named warnings

[Stan Shebs]

DJ Delorie wrote:

>Why not adopt what CSS and Xt do?  Have a mnemonic but heirarchical
>system of naming and categorizing warnings, and let the user specify
>any part of the warning to select it?  That automatically segregates
>the language front ends, standards, and targets; and gives us grouping
>functionality.  It also allows us to isolate the logic for selecting
>warnings if we treat them as "just strings" (i.e. allows for future
>creation of a ".gccrc").  Example:
>
I like this idea as a way of organizing things.  It's more complicated,
but I think it could be a sort of layer superimposed on basic machinery;
in other words, names can be arbitrary, but if you use the hierarchical
scheme for a name, you get to ask for groups of warnings "for free".

>
>GCC's code would go from this:
>
>	if (warn_missing_protos)
>	  warn ("missing prototype: %s", foo);
>
>to this:
>
>	warn ("std.c99.proto.missing", "missing prototype: %s", foo);
>
Implementationwise, I haven't yet figured out whether enums or strings
would be better here - one can make compelling arguments for either.
I also want to be performance-aware, which encourages making flag tests
before function calls, although I hope there are few warning tests in
critical code paths.

Stan

Re: RFC: Named warnings

[DJ Delorie]

> Implementationwise, I haven't yet figured out whether enums or strings
> would be better here - one can make compelling arguments for either.
> I also want to be performance-aware, which encourages making flag tests
> before function calls, although I hope there are few warning tests in
> critical code paths.

In theory, it should be no worse than -Wall (er, one that really
enabled all warnings, of course).

Re: RFC: Named warnings

[Mark Mitchell]

--On Friday, January 24, 2003 02:11:31 PM -0800 Stan Shebs 
<shebs@apple.com> wrote:

> I like this idea as a way of organizing things.  It's more complicated,
> but I think it could be a sort of layer superimposed on basic machinery;
> in other words, names can be arbitrary, but if you use the hierarchical
> scheme for a name, you get to ask for groups of warnings "for free".

It's also worth thinking about what you're going to do when the (English)
message changes.  -Wunused-class is a mnemonic for:

  warning: class `T' is unused

but if it later becomes apparent that a better way to word the error is:

  warning: class `T' is defined but never referenced

then it's pretty confusing.  I know that as we tweak the new parser,
both warning error messages will probably change substantially.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: RFC: Named warnings

[Matt Austern]

On Friday, January 24, 2003, at 02:35  PM, Mark Mitchell wrote:

> --On Friday, January 24, 2003 02:11:31 PM -0800 Stan Shebs 
> <shebs@apple.com> wrote:
>
>> I like this idea as a way of organizing things.  It's more 
>> complicated,
>> but I think it could be a sort of layer superimposed on basic 
>> machinery;
>> in other words, names can be arbitrary, but if you use the 
>> hierarchical
>> scheme for a name, you get to ask for groups of warnings "for free".
>
> It's also worth thinking about what you're going to do when the 
> (English)
> message changes.  -Wunused-class is a mnemonic for:
>
>  warning: class `T' is unused
>
> but if it later becomes apparent that a better way to word the error 
> is:
>
>  warning: class `T' is defined but never referenced

That's a good argument for numeric codes instead of mnemonics.

What do we know about prior art for other compilers?  At the
risk of stating the obvious, providing pragmas and command
line options to get fine-grain control over warnings is not
a new idea.  We may as well try to learn from other people's
mistakes.

			--Matt

Re: RFC: Named warnings

[Mark Mitchell]

--On Friday, January 24, 2003 03:16:56 PM -0800 Matt Austern 
<austern@apple.com> wrote:

> What do we know about prior art for other compilers?  At the

That's a large part of why I'm advocating numbers.

All the prior art I know of (which includes at least EDG, Borland,
Microsoft, several versions of Lint, and CenterLine error-checking
products) used numbers.

Starting with numbers, and then adding equivalent mnemonics if we want
to do that, seems like a sensible way to go.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: RFC: Named warnings

[Andrea 'fwyzard' Bocci]

At 15.21 24/01/2003 -0800, Mark Mitchell wrote:

>>What do we know about prior art for other compilers?  At the
>
>That's a large part of why I'm advocating numbers.
>
>All the prior art I know of (which includes at least EDG, Borland,
>Microsoft, several versions of Lint, and CenterLine error-checking
>products) used numbers.

Does anyone knows of a compiler which at least *tried* to use mnemonics 
instead of numbers ?
Or does everyone just started with numbers, which are simpler to implement 
but less user firendly ?

Just curious...
fwyzard 

Re: RFC: Named warnings

[Gabriel Dos Reis]

"Andrea 'fwyzard' Bocci" <fwyzard@inwind.it> writes:

| At 15.21 24/01/2003 -0800, Mark Mitchell wrote:
| 
| >>What do we know about prior art for other compilers?  At the
| >
| >That's a large part of why I'm advocating numbers.
| >
| >All the prior art I know of (which includes at least EDG, Borland,
| >Microsoft, several versions of Lint, and CenterLine error-checking
| >products) used numbers.
| 
| Does anyone knows of a compiler which at least *tried* to use
| mnemonics instead of numbers ?

CodeWarrior has been mentioned.

| Or does everyone just started with numbers, which are simpler to
| implement but less user firendly ?

I would tend to believe that; if you think about it, short options were
the way to go some ages ago, now we have long options :-)

-- Gaby

Re: RFC: Named warnings

[Stan Shebs]

Matt Austern wrote:

> On Friday, January 24, 2003, at 02:35  PM, Mark Mitchell wrote:
>
>> --On Friday, January 24, 2003 02:11:31 PM -0800 Stan Shebs 
>> <shebs@apple.com> wrote:
>>
>>> I like this idea as a way of organizing things.  It's more complicated,
>>> but I think it could be a sort of layer superimposed on basic machinery;
>>> in other words, names can be arbitrary, but if you use the hierarchical
>>> scheme for a name, you get to ask for groups of warnings "for free".
>>
>>
>> It's also worth thinking about what you're going to do when the (English)
>> message changes.  -Wunused-class is a mnemonic for:
>>
>>  warning: class `T' is unused
>>
>> but if it later becomes apparent that a better way to word the error is:
>>
>>  warning: class `T' is defined but never referenced
>
>
> That's a good argument for numeric codes instead of mnemonics.

I look at it as more of an argument for choosing eternally-meaningful
warning names.  To me anyway, -Wunused-class is still preferable to
-Wclass-defined-but-never-referenced... :-)

Choosing good warning names is a little like writing headlines;
they should be short and to the point, but you can leave the full
explanation for the message itself.

>
> What do we know about prior art for other compilers?  At the
> risk of stating the obvious, providing pragmas and command
> line options to get fine-grain control over warnings is not
> a new idea.  We may as well try to learn from other people's
> mistakes.

CodeWarrior has about 20-30 types of warnings, all controlled
by pragmas like "#pragma warn_unusedvar on|off|reset" for unused
variables.

Interestingly, only about half of the warnings have checkboxes in
the IDE, and the manual has to mention which warnings correspond to
IDE settings, and which can only be controlled from the source
code.

CW also tends to issue errors where GCC might try to come up
with an interpretation.  So for instance it unconditionally
errors on Neil's example of "inline int x;".

Stan

Re: RFC: Named warnings

[Falk Hueffner]

Matt Austern <austern@apple.com> writes:

> What do we know about prior art for other compilers?  At the risk of
> stating the obvious, providing pragmas and command line options to
> get fine-grain control over warnings is not a new idea.

The Compaq compiler, which is EDG based IIRC, has named warnings; a
warning looks like this:

cc: Info: test.c, line 1: The declaration of the function f has an empty parameter list.  If the function has parameters, they should be declared here; if it has no parameters, "void" should be specified in the parameter list. (noparmlist)
int f() { int x[10]; return  x[10];  }
----^
cc: Info: test.c, line 1: In this statement, an array is being accessed outside the bounds specified for the array type. (subscrbounds)
int f() { int x[10]; return  x[10];  }
-------------------------------^
cc: Warning: test.c, line 1: The storage at byte offset 40 from variable "x" is fetched but not initialized.  Also the variable itself is not initialized.  And there may be other fetches of this variable that have not been reported in this compilation. (uninit5)
int f() { int x[10]; return  x[10];  }
-----------------------------^

You can set the level of each warning on the command line, or turn it
off.  "Info" level warnings are usually not shown.

Warnings are also in groups, like "64bit", or "noc89", which can be
enabled or disabled separately.

It's a reasonable system, IMHO.

-- 
	Falk

Re: RFC: Named warnings

[Neil Booth]

Mark Mitchell wrote:-

> then it's pretty confusing.  I know that as we tweak the new parser,
> both warning error messages will probably change substantially.

Indeed.  And the C front end is still bison based.  When it converts
to recursive descent (one way or the other!) they will inevitably change
dramatically.

In my opinion many of GCC's current diagnostics are not well-worded,
or could be improved in various ways.  This is particularly so when
combined with caret diagnostics: what required separate diagnostics
before for clarity can now be done with a single message.

For example, the current trigraph warnings explicitly contain the
trigraph.  That's unnecessary when a caret is pointing right at it.
Similarly for all the union/struct/enum separated diagnostics in the
front end at the moment.

I hope we don't move to this new regime too quickly, because I fear
many / most warnings will still change.  Putting a lump of inertia
that encourages the status quo, and makes improving the diagnostics
substantially more painful would be a real shame.

Neil.

Re: RFC: Named warnings

[Ben Elliston]

>>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:

  Stan> My strongest reason for preferring names is that they can
  Stan> carry more information and thus include some
  Stan> self-documentation.

Names are also likely to form more uniquely identifiable strings to
locate them in the GCC source code.

Ben

Re: RFC: Named warnings

[Joseph S. Myers]

On Fri, 24 Jan 2003, Mark Mitchell wrote:

> So, in favor of numbers:
> 
> - They're shorter.

Either they're longer (md5sums of the message, or from /dev/random) or
else you likely get clashes when two patches adding new warnings are
reviewed in parallel, and both allocate the same number (if developers are
expected to take them sequentially).  It should be possible for multiple
patches adding warnings to be reviewed and applied out of order (and for
people to distribute patches not intended to be included in GCC CVS, and
users to apply multiple such patches without conflicts).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: RFC: Named warnings

[Gabriel Dos Reis]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

| On Fri, 24 Jan 2003, Mark Mitchell wrote:
| 
| > So, in favor of numbers:
| > 
| > - They're shorter.
| 
| Either they're longer (md5sums of the message, or from /dev/random) or
| else you likely get clashes when two patches adding new warnings are
| reviewed in parallel, and both allocate the same number (if developers are
| expected to take them sequentially).  It should be possible for multiple
| patches adding warnings to be reviewed and applied out of order (and for
| people to distribute patches not intended to be included in GCC CVS, and
| users to apply multiple such patches without conflicts).

Really, I believe this road is going to cause more trouble than with
named warning.  Numbers may be short but they are also undescriptive
and if each time one reads a #pragma one has to consult a handbook,
then I don't believe thgat is a feature.

And really errno is not an example to replicate.

-- Gaby

Re: RFC: Named warnings

[Mark Mitchell]

--On Friday, January 24, 2003 11:33:49 AM +0000 "Joseph S. Myers" 
<jsm28@cam.ac.uk> wrote:

> On Fri, 24 Jan 2003, Mark Mitchell wrote:
>
>> So, in favor of numbers:
>>
>> - They're shorter.
>
> Either they're longer (md5sums of the message, or from /dev/random) or
> else you likely get clashes when two patches adding new warnings are

It's really not very hard.  You add to the end of an enum.  Every
now and then there's a conflict, and someone has to go first; that's
an easier merge than most and it will happen rarely.

Been there, done that.

--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: RFC: Named warnings

[Falk Hueffner]

Mark Mitchell <mark@codesourcery.com> writes:

> --On Friday, January 24, 2003 11:33:49 AM +0000 "Joseph S. Myers"
> <jsm28@cam.ac.uk> wrote:
> 
> > On Fri, 24 Jan 2003, Mark Mitchell wrote:
> >
> >> So, in favor of numbers:
> >>
> >> - They're shorter.
> >
> > Either they're longer (md5sums of the message, or from /dev/random) or
> > else you likely get clashes when two patches adding new warnings are
> 
> It's really not very hard.  You add to the end of an enum.  Every
> now and then there's a conflict, and someone has to go first; that's
> an easier merge than most and it will happen rarely.

I'm not really sure this will work so well. There might be gcc
branches with new warnings that are kicked along parallel to the
"main" gcc for years, and in that time, people either couldn't use the
warning numbers, or they'd have to change them at merge time.

-- 
	Falk

Re: RFC: Named warnings

[Richard Earnshaw]

> Mark Mitchell <mark@codesourcery.com> writes:
> 
> > --On Friday, January 24, 2003 11:33:49 AM +0000 "Joseph S. Myers"
> > <jsm28@cam.ac.uk> wrote:
> > 
> > > On Fri, 24 Jan 2003, Mark Mitchell wrote:
> > >
> > >> So, in favor of numbers:
> > >>
> > >> - They're shorter.
> > >
> > > Either they're longer (md5sums of the message, or from /dev/random) or
> > > else you likely get clashes when two patches adding new warnings are
> > 
> > It's really not very hard.  You add to the end of an enum.  Every
> > now and then there's a conflict, and someone has to go first; that's
> > an easier merge than most and it will happen rarely.
> 
> I'm not really sure this will work so well. There might be gcc
> branches with new warnings that are kicked along parallel to the
> "main" gcc for years, and in that time, people either couldn't use the
> warning numbers, or they'd have to change them at merge time.

That's easily solved.  Just declare the master file to be the mainline.  A 
warning number is never added on a branch without first adding it to the 
mainline (note: it's only the number that's added on the trunk).  If the 
branch dies without being merged, then the number can be recycled, but I 
doubt even that is really necessary.

R.

Re: RFC: Named warnings

[Gabriel Dos Reis]

Richard Earnshaw <rearnsha@arm.com> writes:

| That's easily solved.  Just declare the master file to be the mainline.  A 
| warning number is never added on a branch without first adding it to the 
| mainline (note: it's only the number that's added on the trunk).

This means that when mainline is frozen, no warning number can be
added to branches.  

-- Gaby

Re: RFC: Named warnings

[Richard Earnshaw]

> Richard Earnshaw <rearnsha@arm.com> writes:
> 
> | That's easily solved.  Just declare the master file to be the mainline.  A 
> | warning number is never added on a branch without first adding it to the 
> | mainline (note: it's only the number that's added on the trunk).
> 
> This means that when mainline is frozen, no warning number can be
> added to branches.  

There's no real reason why that file should be frozen for that purpose.

Anyway, most freezes that exceed a few hours occur only on branches.

R.

Re: RFC: Named warnings

[Gabriel Dos Reis]

Richard Earnshaw <rearnsha@arm.com> writes:

| > Richard Earnshaw <rearnsha@arm.com> writes:
| > 
| > | That's easily solved.  Just declare the master file to be the mainline.  A 
| > | warning number is never added on a branch without first adding it to the 
| > | mainline (note: it's only the number that's added on the trunk).
| > 
| > This means that when mainline is frozen, no warning number can be
| > added to branches.  
| 
| There's no real reason why that file should be frozen for that purpose.
| 
| Anyway, most freezes that exceed a few hours occur only on branches.

Well, last time mainline was frozen for a week (at least) -- there
were various (good) reasons.

-- Gaby

Re: RFC: Named warnings

[Neil Booth]

Falk Hueffner wrote:-

> > It's really not very hard.  You add to the end of an enum.  Every
> > now and then there's a conflict, and someone has to go first; that's
> > an easier merge than most and it will happen rarely.
> 
> I'm not really sure this will work so well. There might be gcc
> branches with new warnings that are kicked along parallel to the
> "main" gcc for years, and in that time, people either couldn't use the
> warning numbers, or they'd have to change them at merge time.

How is that different from any other merge conflict?

You're not complaining that someone might have to change their #pragma's
from what worked on a experimental branch off an experimental
development compiler, surely?

Neil.

Re: RFC: Named warnings

[Tom Tromey]

>>>>> "Neil" == Neil Booth <neil@daikokuya.co.uk> writes:

Neil> You're not complaining that someone might have to change their
Neil> #pragma's from what worked on a experimental branch off an
Neil> experimental development compiler, surely?

Not all branches are experimental -- at least one vendor ships a
compiler off a gcc branch.  While GCC could officially ignore the
various forks out there, I think it would be preferable to recognize
that they happen, and plan for it accordingly.

Tom

Re: RFC: Named warnings

[Joseph S. Myers]

On Fri, 24 Jan 2003, Mark Mitchell wrote:

> It's really not very hard.  You add to the end of an enum.  Every

So you have a mnemonic name internally in the enum, but hide it from the
users and the readers of their source code, and still require the
corresponding number to be entered manually in the documentation?

I favour having the mnemonic names visible to users (with -Wwarning-names
to show them only when required), along with a carefully designed
implementation practice that avoids the need to centralise the definitions
of exactly which warnings go in collections such as -pedantic.  (That is,
it should be visible at a call to a warning function both what the
individual warning code is and what classes it is in, rather than having
-pedantic cause a huge number of flag variables to be individually
changed.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: RFC: Named warnings

[Alexandre Oliva]

On Jan 24, 2003, Mark Mitchell <mark@codesourcery.com> wrote:

> It's really not very hard.  You add to the end of an enum.  Every
> now and then there's a conflict, and someone has to go first; that's
> an easier merge than most and it will happen rarely.

But it's not that easy for users to cope with.  If GCC version is
3.1415, use -Wno-1234, else use -Wno-1273.  Eeek.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: RFC: Named warnings

[Fergus Henderson]

On 24-Jan-2003, Mark Mitchell <mark@codesourcery.com> wrote:
> 
> 
> --On Thursday, January 23, 2003 05:06:16 PM -0800 Stan Shebs 
> <shebs@apple.com> wrote:
> 
> >As part of this individual control, each warning will get a unique
> >name, which consists of an alphanumeric string plus hyphens.
> 
> Overall, I think your proposal is fine, and I like the ideas about
> attributes.
> 
> I think the one sentence quoted above is a mistake.  I know people
> don't like numbers, but I think numbers are actually better here.

Why?

Below you say "They're shorter." and "They're language-independent.".
Are those your only reasons?

If so, I find them quite unconvincing.

> Some of the objections have been:
> 
> - The numbers will change.
> 
>  But, actually, they won't.  It's not hard to keep from changing
>  them, and I've worked on multiple compilers that had no trouble
>  keeping the numbers the same.

What did you do about warnings added on different development branches?

Was your experience with free software, developed by a wide variety of
different individuals and organizations, using multiple development
branches and with many organizations and individuals maintaining
patches or trees outside the main source code repository?

Using numbers poses far more problems if development is done by a large
number of separate organizations who do not merge there changes into
a single repository on a timely basis, as is the case with GCC, than
if development is done by a single organization with a single central
repository.

You can allocate chunks of the number space to different organizations,
different branches, etc., but then you need to use a sparse error number
space, which reduces the conciseness of the error codes, and also you
end up with very odd error message numbers that reflect the development
history rather than having anything to do with the nature of the warning.

> - The numbers aren't mnemonic.
> 
>  True, but how mnemonic are the literally hundreds of warnings in
>  the C++ front end going to be as foo-bar-baz strings?

Much, much, MUCH, *MUCH* more mnemonic than numbers would be.

Consider even the very worst names that Unix and C have given us,
such as mbstowcs(), strcspn() -- think how much more mnemonic
these are than numbers would be!  

Quick, what's the meaning of Linux signal number 30?

Well, maybe you remember that one off by heart, but I'll bet a lot of
readers don't.  On the other hand, mnemonics such as SIGPWR are a lot
easier to remember.

>  The way people actually use this feature in other compilers is like
>  this:
> 
>  (1) Run the compiler.
>  (2) Look at the warnings.
>  (3) Note that a particular warning isn't making sense for their
>      code.
>  (4) Insert a #pragma/attribute/comment to turn it off.

Right.  That's what they do when *writing* the code (or the Makefile,
etc.).  But that is *not* the only thing to optimize.  The other thing
to optimize -- and arguably it is more important -- is the ease of
*reading* the code.

>  Since steps 3/4 come together, something like:
> 
>    warning [123]: You're a moron, Mark.
> 
>  is easily dealt with; you copy the "123" into your code.

And then stop there?  Arrgh.

Good programmers copy the "123" into their code, and then *add a comment*
explaining what "123" stands for.

Unfortunately, however, good programmers are rare (and usually expensive).

Quick, what does a Linux errno value of 123 mean, as a return
value from the mount() system call?

You don't remember?  How about ENOMEDIUM?  Is that any easier?

> So, in favor of numbers:
> 
> - They're shorter.
> 
> - They're language-independent.

Language-independence is good, but not if it comes at the expense
of useful functionality and without any significant redeeming benefit.
IMHO the slightly shorter nature of numbers rather than mnemonic
error names is not nearly enough to justify the major loss of readability
for compiler options and pragmas.

>  GCC could have a manual section, like many other compilers, listing
>  all the warnings in numberical order with a description of what each
>  warning (and error) is about.

Sure, but the same could be done for non-numerical error codes just as
easily (in alphabetical order, of course).

Anyway, how is this going to help the poor Debian users who don't happen
to have a copy of the GCC manual handy?

> In any case, it would be a good idea to include errors in your scheme.
> 
> Also, some errors should have the ability to be turned into warnings
> (that's what -fpermissive does in C++, for example), and all warnings
> should have the ability to be turned into errors.  It makes sense
> to name/number *all* diagnostics, if for no other reason than
> easier documentation in the manual.

That would be OK with me, but if so, then IMHO there should be a
separate option which says whether or not to include message codes in
error messages, and furthermore IMHO that option should default to off.

If we do have such numbers, then it might be nice to have an option
which causes the compiler to output not just the name of the message,
but also a URL which would point to the relevant section of (the locally
installed copy of) the manual.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: RFC: Named warnings

[Michael S. Zick]

On Friday 24 January 2003 08:37 am, Fergus Henderson wrote:
>
> If we do have such numbers, then it might be nice to have an option
> which causes the compiler to output not just the name of the message,
> but also a URL which would point to the relevant section of (the locally
> installed copy of) the manual.
>
That could be a good feature for any scheme that is devised.
In fact, it could point to the proper "native-language (people)"
translation of the manual.

If you do decide to go with number codes, then some similar
dotted syntax (Dewey Decimal?) might be used -
Classification.Group.Declaration.Misuse....

Mike

Re: RFC: Named warnings

[Mark Mitchell]

> What did you do about warnings added on different development branches?

This, and your other arguments, are good ones.

But they don't persuade me.

It's not that I disagree with your logic; just that I weight things
differently.  For example, you could map mnemonics to the numbers
in a (natural)-language dependent way; in English "mark-moron" could
be a synonym for "123", but in French you could use something else.

That would let you have both ways, perhaps.

My claim is very simple: this is a bigger can of worms than it looks
like, and numbers are a relatively simple, time-tested solution; one
that we know from experience can be made to work, both for users and
for implementors.

I'll not stand in the way of the mnemonic approach, but I'd suggest
we leave ourselves maximum wiggle room.  The approach I suggest above
would let us try out both ways of doing things.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: RFC: Named warnings

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

| My claim is very simple: this is a bigger can of worms than it looks
| like, and numbers are a relatively simple, time-tested solution; one
| that we know from experience can be made to work, both for users and
| for implementors.

I'm having hard time to figure out how it can be argued that enumerations
are better than magic constants in source codes and not apply the same
very reasons for this particular case, given that there is no vendor-neutral
numbers agreed on.  As I said earlier, I find codes will numbered
#pragmas very difficult to read.  Named warnings can be made flexible
and we can leave ourselves maximum wiggle room as you're suggesting.

-- Gaby

Re: RFC: Named warnings

[Tom Tromey]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

Mark> It's not that I disagree with your logic; just that I weight things
Mark> differently.  For example, you could map mnemonics to the numbers
Mark> in a (natural)-language dependent way; in English "mark-moron" could
Mark> be a synonym for "123", but in French you could use something else.

One facet of Stan's proposal that I liked was the idea that the
command-line switches and #pragmas would use the same names.  That
means that any effort I put into learning one can be immediately
applied to the other.

For me this consideration is a strike against using numbers.  Also, it
seems to me that all the pro-number arguments also apply to changing
the switches to be numbers... but I really wouldn't like to write
`gcc -W3251 -W37 -W129'.

I do sympathize with the non-English-centric aspect of using numbers.
However, it seems to me that all the gcc long options are already in
English, and that almost all the warning options fall into this
category.  Anybody using gcc already has to deal with this.

Tom

Re: RFC: Named warnings

[Joe Buck]

On Fri, Jan 24, 2003 at 12:15:22AM -0800, Mark Mitchell wrote:
>   Since steps 3/4 come together, something like:
> 
>     warning [123]: You're a moron, Mark.
> 
>   is easily dealt with; you copy the "123" into your code.
> 
>   I'm not sure that:
> 
>     warning [moron-mark]: You're a moron, Mark.
> 
>   is going to be very friendly if that foo-bar-baz string gets long,
>   and if it's not present then it's a pain in the neck to find the
>   supposedly mnemonic string.

I think that the strongest argument is the language issue:

Warnung [123]: Du bist Dummkopf, Mark.

versus

Warnung [moron-mark]: Du bist Dummkopf, Mark.

versus

Warnung [dummkopf-mark]: Du bist Dummkopf, Mark.

And if a warning goes away, we just reserve the number, and document
it as obsolete.

There is, though, an issue coming from the fact that we support multiple
languages: if warnings are added over time, a linear sequence would mean
that the C, C++, Java, etc. warnings all get mixed up.  One possibility
is to use some kind of prefix to indicate the component (language front
end, "middle end", backend) where the warning comes from, so we have

warning [C++-123]: You're a fool, Joe.

That way, the different teams can maintain their own sequences and the
documentation will wind up more organized.

Re: RFC: Named warnings

[Gabriel Dos Reis]

Joe Buck <jbuck@synopsys.com> writes:

[...]

| There is, though, an issue coming from the fact that we support multiple
| languages: if warnings are added over time, a linear sequence would mean
| that the C, C++, Java, etc. warnings all get mixed up.  One possibility
| is to use some kind of prefix to indicate the component (language front
| end, "middle end", backend) where the warning comes from, so we have
| 
| warning [C++-123]: You're a fool, Joe.
| 
| That way, the different teams can maintain their own sequences and the
| documentation will wind up more organized.

However, during developement, warnings get merged or splitted.  

Furthermore, GCC has concrete experience with -Wxxx scheme.  It is much
natural to extend that scheme at the #pragma level that use bunch of
new numbers. 

If a -Wxxx causes a warning to be issued in a particular file, then
it is far easier and less contrived to edit that file and adds

   #pragma warning xxx [on|off]

around the offending code than find out the handbook and lookup the
corresponding number.  We have to take ease of use into account.

Since we don't translate #pragma nor the keywords nor the various
switches GCC understands, I find the natural-language issue very weak.  

-- Gaby

Re: RFC: Named warnings

[Kevin Handy]

Joe Buck wrote:

>I think that the strongest argument is the language issue:
>
>Warnung [123]: Du bist Dummkopf, Mark.
>
>versus
>
>Warnung [moron-mark]: Du bist Dummkopf, Mark.
>
>versus
>
>Warnung [dummkopf-mark]: Du bist Dummkopf, Mark.
>
>And if a warning goes away, we just reserve the number, and document
>it as obsolete.
>
>There is, though, an issue coming from the fact that we support multiple
>languages: if warnings are added over time, a linear sequence would mean
>that the C, C++, Java, etc. warnings all get mixed up.  One possibility
>is to use some kind of prefix to indicate the component (language front
>end, "middle end", backend) where the warning comes from, so we have
>
>warning [C++-123]: You're a fool, Joe.
>
Wouldn't you really need to do something like this anyway?

There are several front ends that are not yet integrated into the
main gcc structure (like pascal and cobal), and it would probably
be much easier to manage the errors for a new/unmerged front end
than trying to stuff in hundreds of new error codees into
a single "enum" when a new front end is developed.

I think a single error message space would become unweildly
quite fast. People will try to conserve the "error number" space,
but the errors generated for a front end like 'C' are
going to mean something different than other front ends,
like fortran, even though the error text might be the same.

If someone wanted to write detailed documentation for the
common causes/fixes of each error message, it will necessarly
be  dependent on which front end is used.

>That way, the different teams can maintain their own sequences and the
>documentation will wind up more organized.
>

Re: RFC: Named warnings

[Theodore Papadopoulo]

shebs@apple.com said:
> It may still be that some warnings are composites, as with -Wunused,
> which controls several other warnings that each have an individual
> control, but this is up to the implementation. 

Instead of thinking composite, may I propose a slight generalization 
of the concept, in that every warning has to belong to a composite.

The idea is to create a hierarchy of warnings (and errors by the way)
a la object oriented language, ie each warning (with a granularity to be
defined more precisely as already mentionned) has:

	1) a name [number or string, both have advantages and it might
        be easy to propose both but just at user interface level with a
        variant of the flag showing the warning names (after all a number
        is nothing else than a index into an array of strings)].

	2) a parent which describes basically the class of warnings 
        to which it belongs.

The root warning is obviously something like "all-warnings" and the 
only one that is its own parent or has no parent at all (at choice).

This way there will be a real taxonomy of warnings within the 
compiler. The immediate descendants of "all-warnings" could be eg
target-independant-warnings and target-dependant-warnings.

I believe that simple inheritance schemes should be sufficient, but I 
may be wrong (actually the composite view is slightly more powerful 
than the inheritance view in this respect since I suppose that a 
warning can belong to multiple composites) in which case the scheme
would be slightly more complicated as there would be multiple parents.

The main question, can we categorize all the current warnings into 
such a hierarchy ???

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: RFC: Named warnings

[Joseph S. Myers]

On Fri, 24 Jan 2003, Theodore Papadopoulo wrote:

> 	2) a parent which describes basically the class of warnings 
>         to which it belongs.

Warnings don't belong to a simple single class.  Some warnings may be
enabled by more than one present composite option.  Some are controlled by
C standard mode (mandatory for C99, controlled by some -W option for C90;
or mandatory for C90, always off for C99).  A good implementation scheme
should have a -Wc89 option (which warns for all the cases presently warned
for if (pedantic && !flag_isoc99), but makes those warnings be warning()
rather than pedwarn() - needed (as well as a complete C99 implementation)
before C99 mode can become default) fall out naturally from the
implementation.

What's intended to be done about selective _enabling_ of format warnings,
where the relevant code is only executed at all if -Wformat is used?  (At
present selective options such as -Wformat-extra-args give a warning that
they have no effect.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: RFC: Named warnings

[Alexandre Oliva]

On Jan 23, 2003, Stan Shebs <shebs@apple.com> wrote:

> int fn() __attribute__ ((warning ("no-sign-compare", "switch")))
> {
>   ...
> }

We can use _Pragma for that as well, I suppose.  It's not clear to me
that using attributes and pragmas isn't redundant.  One thing that
would definitely be nice is to be able to limit warnings to
expressions, so that preprocessor macros that might trigger unwanted
warnings may have means to disable them.  Something like we currently
use __extension__ for, maybe an extended version of that, such as
__extension__ __attribute__ ((warning ("..."))) (expression).

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: RFC: Named warnings

[Segher Boessenkool]

Hi,

A few ideas:

Output the warning on the first line, and the description on the
second line, like this:

	bla.c:14:3: warning: conversion-signed-unsigned
	bla.c:14:3:    Implicit conversion from signed to unsigned

Or, with the new flags -Wexplanation and -Wwhy:

	bla.c:6:1: warning: comment-multi-line
	bla.c:6:1:    (-Wcomment-multi-line was enabled by -Wall)
	bla.c:6:1:    ==================================================
	bla.c:6:1:    Multi-line comment:
	bla.c:6:1:    
	bla.c:6:1:    A `//' comment line ends in a `\', which causes
	bla.c:6:1:    the next line to be part of that comment as well.
	bla.c:6:1:    This is probably not what you want.
	bla.c:6:1:    ==================================================

Put the warnings and explanations in separate files, maybe one per
C source file or per warning group; probably combined on install.
This eases translation as well, and allows for easy inclusion in the
manual, without lots of duplication or much synchronization effort.


Segher

Re: RFC: Named warnings

[Fergus Henderson]

On 25-Jan-2003, Segher Boessenkool <segher@koffie.nl> wrote:
> A few ideas:
> 
> Output the warning on the first line, and the description on the
> second line, like this:
> 
> 	bla.c:14:3: warning: conversion-signed-unsigned
> 	bla.c:14:3:    Implicit conversion from signed to unsigned
> 
> Or, with the new flags -Wexplanation and -Wwhy:
> 
> 	bla.c:6:1: warning: comment-multi-line
> 	bla.c:6:1:    (-Wcomment-multi-line was enabled by -Wall)
> 	bla.c:6:1:    ==================================================
> 	bla.c:6:1:    Multi-line comment:
> 	bla.c:6:1:    
> 	bla.c:6:1:    A `//' comment line ends in a `\', which causes
> 	bla.c:6:1:    the next line to be part of that comment as well.
> 	bla.c:6:1:    This is probably not what you want.
> 	bla.c:6:1:    ==================================================

The Mercury compiler uses an approach similar to this.
Most users seem to be happy with it.  But a few
have requested that we provide a mode in which the file
name and line/column number is only printed once, at
the start of the error, rather than once per line:

 	bla.c:14:3: warning: conversion-signed-unsigned
 	               Implicit conversion from signed to unsigned
 	bla.c:6:1: warning: comment-multi-line
 	              (-Wcomment-multi-line was enabled by -Wall)
 	              ==================================================
 	              Multi-line comment:
 	              
 	              A `//' comment line ends in a `\', which causes
 	              the next line to be part of that comment as well.
 	              This is probably not what you want.
 	              ==================================================

This apparently works better in some environments (I forget which --
maybe Emacs?).

Another useful refinement is that if the compiler issues a warning
for which more information is available, it should set
a flag, and if at the end of compilation this flag is set,
it should output an additional final message:

	Recompile with `-Wexplanation' for more information.


-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: RFC: Named warnings

[Segher Boessenkool]

Fergus Henderson wrote:

> The Mercury compiler uses an approach similar to this.
> Most users seem to be happy with it.  But a few
> have requested that we provide a mode in which the file
> name and line/column number is only printed once, at
> the start of the error, rather than once per line:

That's fine with me, too -- but this seems to be more difficult
to 'parse' by automated tools (read: grep).

> This apparently works better in some environments (I forget which --
> maybe Emacs?).
> 
> Another useful refinement is that if the compiler issues a warning
> for which more information is available, it should set
> a flag, and if at the end of compilation this flag is set,
> it should output an additional final message:
> 
>         Recompile with `-Wexplanation' for more information.

That should trigger on _any_ warning, then ;)


Segher

Re: RFC: Named warnings

[Nix]

On Sat, 25 Jan 2003, Fergus Henderson uttered the following:
> The Mercury compiler uses an approach similar to this.
> Most users seem to be happy with it.  But a few
> have requested that we provide a mode in which the file
> name and line/column number is only printed once, at
> the start of the error, rather than once per line:
> 
>  	bla.c:14:3: warning: conversion-signed-unsigned
>  	               Implicit conversion from signed to unsigned
>  	bla.c:6:1: warning: comment-multi-line
>  	              (-Wcomment-multi-line was enabled by -Wall)
>  	              ==================================================
>  	              Multi-line comment:
>  	              
>  	              A `//' comment line ends in a `\', which causes
>  	              the next line to be part of that comment as well.
>  	              This is probably not what you want.
>  	              ==================================================

As long as splitting a single warning over multiple lines can be
disabled.

(Often `grep' will serve to replace a complex -Wno-warning-here switch,
 but that doesn't work so well if the warning is multi-line.
 The existing cases where GCC splits warnings over multiple lines are
 annoying enough!)

-- 
`I knew that there had to be aliens somewhere in the universe.  What I
 did not know until now was that they read USENET.' --- Mark Hughes,
      on those who unaccountably fail to like _A Fire Upon The Deep_