[Bug other/44210] Extended warning control: like -Wevery -show-warnings

["eric dot estievenart at free dot fr" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #5 from eric dot estievenart at free dot fr  2010-05-21 18:00 -------
44209
> The manual documents...
> We will accept patches fixing any missing/mistaken entries.
That's not the point !
This manual section could (and should) be generated from the output of
-show-warnings or similar

> You could also propose some warnings to be moved to Wextra/Wall
Neither !

> See also the option -fdiagnostics-show-option.
I know it well, it is always in my cflags.
This is because a specific warning had no diagnostic that I logged
#44209 and consequently this ER.

> It would be extremely useful to go through the manual and...

> perhaps provide a "Wparanoid" setting that includes all those warnings.
That's a better name than Wevery. Wmaniac would be smart too ;-)
But it's not time for voting !

> Instead of -show-warnings, I would propose to extend the current
> --help=warnings --verbose.

--help=warnings has its own purpose, and it is indeed useful,
but it does not show the effects of a given commandline on the whole
set of available warnings (which also depends on the language)

> However, that would mean documenting within GCC the
> relations between the warnings options. That by itself (even without the
> output) would be EXTREMELY useful if done properly, that is, by adding the
> information to the *.opt files that define the flags.

> I can provide pointers on how this could be implemented.
Thank you, I'll certainly need some help on the following points:
- which branch I should start working on (4.4, 4.5, ...) so that
  it has good chances to be accepted, and could be integrated into
  released subversions without too many hassle
- which front-ends I should target beside C/C++
- which files to look at first considering the problem.
- if there are things in the developper docs (or rather
  which are not in the developper docs) which could help me.

For the dev itself, I should be able to handle it.
Honestly I have not yet had a look at the code neither
at the architecture, but I guess I will find a common
module shared by the front-ends, compiler, etc.
I'll see if I can first spot / force compile-time warnings
for the calls to a function like log_warning(...)
if the warning is not linked to a diagnostic,
extend the api, ...

> A follow-up patch could even fill the details of
> the manual from that information automatically!
That's indeed my intent !

> So, I think yes, we are interested in any of the above, so if you are
> interested in providing patches, choose something small to start with (some
> small documentation patch to the manual), and ask whatever you want. You may
> ask here or write to me directly.

Thank you again, but if I start on that, I expect to go to the end,
so patching the manual would be a loss of time since all would be generated
after. I don't have so much time to spend on it, I just expect to do it in
a clean and efficient way.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44210