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


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

Re: RFC: Named warnings


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


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