[C++] Warning Header Proposal

[Ben Longbons <brlongbons@gmail.com>]

Under the assumption that most active gdb maintainers intend that
future gdb releases be written in C++, I am presenting a possible plan
for the conversion, based on my experience with a conversion about
1/5th the size of gdb.

I have found 3.5 areas of discussion, 2.5 of which I have actually written.
- System Requirements
- Attack Plan
-- Warning Header Proposal
- Style Guide (to be written, probably not by me)

A shared editing pad is available at http://piratepad.net/gdb-cxx, it
will contain links to the archived mails so don't be concerned about
editing what I wrote there.

This thread will discuss my proposal to make warning management easier
by using a header file.

This is a somewhat controversial proposal, so I split it from the Attack Plan.

The second step that I propose is to introduce a new mechanism for
managing warnings. This would apply only in development mode, because
for full effectiveness, it requires #pragma GCC diagnostic to apply
inside functions. This requires editing the autoconf file to add to
CPPFLAGS only under gdb/

The specific change I propose is, insteading of adding warnings by an
autoconf test, hard-code them according to compiler version. Despite
sounding like a step backward, this is actually a step forward,
because:
- I have a list of every single warning supported by gcc 4.6, 4.7, and
4.8 in C++ mode (the initial version of the file in C mode will be
limited unless someone wants to fill it, but I don't see the point.
Note that gcc documentation is not always accurate about which
warnings are applicable in which modes).
- Given the warning header, it very easy to flip one between "don't
care", "ignore", "force to warning even with --enable-werror",
"warning or error depending on --enable-werror", and "force error
always"
- Compared to a @file, there may be comments in a header.
- Compared to adding every single warning to the command line, this
keeps the length of the compiler line readable. Currently, gdb enables
very few compiler warnings. Hm, since the autoconf-added ones will be
in the header anyway, is there a way to tell autoconf to *not* add
-Wfoo to CPPFLAGS in gdb/ ? Well, I guess we could just never add them
and pass something like: -DGDB_STRICT_WARNINGS while in gdb/ ... or
just wait for the c++ conversion and check __cplusplus.
- Compared to using autoconf, the header is much more accessible by
ordinary developers. It might not appear so to those of you who are
familiar with it, but autoconf is *insane*. I gave it a sincere
effort, but eventually I just gave up and wrote my own ./configure
script and toolset.
- Compared to autoconf, we can rely on warnings actually *working*
instead of just assuming that the option works just because the
compiler recognizes it. A particularly notorious example is -Wshadow,
which is only useful since gcc 4.8 but has been recognized since
(insert ridiculously ancient event here). Admittedly, it's *possible*
to write a test for exactly the positive and negative cases, but are
you really going to do that?

I intend to do some things differently for gdb, but for reference, the
warning file I currently use is
https://github.com/themanaworld/tmwa/blob/test/src/warnings.hpp
Particularly, I do not think it is worth trying to get meaningful
warnings out of clang.


Thanks for your time,
Ben Longbons (o11c on IRC)