Re: Warnings in the C++ Front-End and GCC in General

[Craig Burley <burley at gnu dot org>]

>I believe this to be an over-statement.  For this particular
>situation, I think `#pragma' is the way to go.  If I do not hear
>violent disagreement in the next few days, I will go ahead and
>implement this.

I don't think offering a `#pragma' interface is a bad idea, but
at least one other interface should be considered.

Specifically, a means to enable/disable, and perhaps even push/pop,
a particular kind of warning would be useful if it could work
within macro expansion.  E.g. a macro that expands in such a way
that it amounts to an inline function, or that expands to a
statement expression (a gcc extension), might want to also expand
to include the specific enabling/disabling of a warning.

Speaking of which, being able to push/pop the status of a warning
is fairly important, I would think.  I didn't notice if it was
in your proposal.


My other concerns about this are more general and over-arching:

  -  Without a class heirarchy and facility to enable/disable/push/pop
     warnings of an entire class, there are likely to be practical
     cases that require long, unwieldy lists of warnings to disable,
     especially once the attitude that "adding new warnings is always
     okay now that people can individually disable them in a chunk of
     code" has had time to establish itself.  (Look at all the
     discussions about adding arbitrary new attributes, or properties,
     to gcc/g++.)

  -  As a result of adding this feature, source code will have a greater
     tendency to be changed with each new release of the compiler to
     accommodate the different warning "contour" of that release.  (A
     warning "contour" is the relationship of warnings to the source
     language, so whether a given warning occurs given a particular
     input contributes to a conceptual contour of all the warnings.)

  -  As a result of adding this feature, there will be less pressure
     to get the warnings "right" from the perspective of the compiler.

     E.g. compiling g77 produces spurious warnings on Alphas -- in the
     future, the temptation might be to modify g77 instead of fixing
     the compiler to no longer produce the spurious warnings.  (These
     are the uninitialized-variable warnings Jeff and others have
     said need to be fixed -- in gcc.)

These general concerns are not, IMO, sufficient for me to even wish
I could veto this proposal.  (I think they're worth raising so
others can consider for themselves to what extent they might be
valid.)

However, they are an illustration of an even more general (unfortunately
rather informal and undocumented) framework that I use to consider
whether any linguistic/dialectal change is worthwhile.

In particular, the elements of my framework these proposals violate
include:

  -  No new, readable, linguistic information is added to the dialect --
     a bunch of numbers, or magic keywords, etc., added to source code
     does not make the source code more readable.  In fact, it'll tend
     to do the opposite, distracting readers from the important elements
     of the algorithm and its implementation with verbeage that plays
     with warning status.

  -  The facility is inherently non-portable.  The new constructs will
     mean nothing to any other compilers, very little to any other
     major versions of the *same* compilers, and various things on
     various host/target combinations of even the same version of the
     same compiler.

Note that I can easily envision new language constructs that would
have the same effect, but not violate the above elements of my
framework.  Designing and adding such constructs would not be easy,
certainly much more difficult and time-consuming than the one-fell-
swoop solution that's being proposed.


Also, I think it's worth pointing out that the source code for the
compiler will become somewhat less readable, at least to people
like myself who can quickly scan code for diagnostic messages
displayed by it to get an idea of what it is doing.  Having architected
g77 in somewhat the same way, I've learned how to mitigate this
somewhat by using readable keywords to denote the messages, but
still find the need to cross-reference a common file to be
bothersome, even though I wrote all the original code.

The other maintenance headache will result from the tendency of
people to want to re-use warning numbers when "slightly" changing
the contour of that warning, or to introduce a new warning number
for a warning that has a contour (and should have verbeage) identical
to some existing warning that the maintainer doesn't know (or forgets)
about.  Subsequent pressure to "fix" such problems will meet with
pressure to not fix them to maintain compatibility with source code
that was changed shortly after the "mistakes" were made to accommodate
them, perhaps without it being clear at the time that they were,
indeed, mistakes.


However, some of the things your patch accomplishes, ignoring the
facility that allows individual enabling/disabling of warnings,
are probably worthwhile.

So I'd suggest people consider the individual issues at least somewhat
in thinking about this.  I.e. consider whether each element is
worth having/doing on its own, assuming the others weren't done.

For example, if there are advantages to internationalizing gcc
by doing this work, that seems worthwhile.  Maybe there's a better
way to do it, though.  As another example, collecting the
diagnostic-support code into a single place (toplev.c, for example)
might be worthwhile.  Maybe a better approach is to look into
GNU-wide rules and support code for diagnostics that accommodates
some or all of the design and implementation goals of this effort.

IMO, though, some of this is just working around significant
deficiencies in C, C++, Fortran, et al as programming languages
(which we could try and solve, somewhat at least, in ways that
address my larger concerns) and in using C as our compiler language
(since it doesn't directly support setting up class heirarchies of
things like diagnostics, nor does C++ for that matter, AFAIK).
But this is what we're stuck with for now, so I don't really mind
some accommodating of these larger problems, even if doing so
introduces a few really small ones.

        tq vm, (burley)