This is the mail archive of the
mailing list for the GCC project.
Re: [warnings] tagging warnings about options themselves
> I don't object to an internal-only OPT_ value.
A thought occurs to me: we could make warning() a macro that passes
__FILE__ and __LINE__ to the diagnostic machinery, and if there's no
OPT_ value it can make one up from the file/line (like
-Wc_common_c_456). The only time the user would *ever* see this is if
they used -fdiagnostics-show-option, and we could emit a note the
first time they see one of these that says it's version-specific. It
would be useful to developers too, especially when we've got lots of
same-wording diagnostics all over the place.
It would probably mess up the "unknown -W option" logic though.
> What I'm less keen on is a new command-line -Wno-options switch. I've
> never seen that in any other compiler. We'd have to decide whether
> -Wno-options applies to warnings that would be issued based on options
> preceding -Wno-options. It just seems needless to me...
Oh, right. Yeah, I can't see how we can accurately define what it
would do then. Nevermind.
> I guess I'm just unsympathetic to people who need to adjust their build
> systems for different compilers.
The usual case I've seen is a customer is migrating to a newer version
of gcc, and wants the new warnings to remain *warnings* until they get
a chance to deal with them. This almost always happens with -Werror,
so as long as the user can get something in before the -Werror that
keeps the new warnings from killing their builds, I'm happy.
Or, if/when we get the -Werror-foo system working, we can just tell
them to stop using -Werror in the first place and use the new option.
I expect some of them will want -Werror in order to catch warnings
they didn't expect, and would want to use -Wno-error-foo to explicitly
mark the ones they know are intentional.
It's kinda like the way we use dejagnu. We tag all the warnings we
expect, and any new ones are fatal.