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

["manu at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #6 from manu at gcc dot gnu dot org  2010-05-22 00:32 -------
(In reply to comment #5)
> > 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

You should work on current trunk. This is a new feature, so not suitable for
release branches.

> - which front-ends I should target beside C/C++
> - which files to look at first considering the problem.

I think you'll need to start modifying the awk scripts that read the *.opt
files: gcc/opt*.awk

You'll probably need to add a new flag Enables, like:

Wextra
Common Var(extra_warnings) Warning  Enables(Wsomething-else,Wother-one)
Print extra (possibly unwanted) warnings

and make the awk scripts handle it by generating code that can print the
relations.

Other interesting files may be opts.* c-opts.*.

> - if there are things in the developper docs (or rather
>   which are not in the developper docs) which could help me.

It depends what you need to know. I cannot read your mind :-)

> 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, ...

I don't understand what you mean by this. 

> 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.

As you wish. I tend to think that when approaching something unknown and
complex, it is better to start small, but if you think you are capable, just go
ahead. I cannot promise that the result will be accepted (because I don't fully
understand what you want to implement), but the experience may be helpful
anyway for someone else to implement something similar.

Flags like this should be named -fsomething. I don't think that -fshow-warnings
will be accepted because it is ambigous. I still believe that letting -Wall
--help=warnings return the flags enabled by Wall would be more clear (and
easier to implement). There could be also -O3 --help,  it will display the
flags enabled by -O3.


-- 


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