This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

named warnings & individual warning control


Ok, I've been given a chunk of time with which to work on this
project.  I've read through the mail archives and, although there
isn't 100% agreement on some aspects of this, there does seem to be a
general concensus on most of it, and I'd like to actually DO something
about it this time around, instead of letting it fall by the wayside
again.  I would at least like to centralize the data identifying which
messages are warnings, errors, or ignored, for those messages which
can be classified as such.

So, this is an attempt to summarize my opinion on the group consensus
with respect to named warnings (and/or errors) and program control of
such.

Some folks argue that the warning text should be in the source, others
note the benefits of having a machine-parsable warning catalog
(documentation, for example).  Both sides agree that gettext() is the
i18n solution of choice.

Warnings should be referenced by mnemonic, not number.  The mnemonic
should match the command line option.

Warning control should be documented as something that WILL change
from release to release of the compiler; users should expect such
controls to be a "last chance" option, and any attempt to make the
system easier for long-term use should be discouraged.  I.e.
complaints that the #pragma to silence warning "foo" changed in this
gcc release will be ignored.

It should be easy to audit warnings to ensure that they're properly
emitted in accordance with the selected standard.

Changes in warning state should be both nestable and restorable.
Simply "revert to initial state" is unacceptable.  In addition,
historical state needs to be remembered such that it can be attached
to a statement to see if a warning was enabled at that point in the
program.

The internal API should allow for both "emit warning if needed" and
"is this warning enabled?" functionality, in case the source needs
custom logic to select warnings.

Whatever we do must support language and target specific extensions,
both in format specifiers and message catalogs.

We should be able to specify, for each itemized message, whether it is
ignored, emitted as a warning, or emitted as an error.

If supported, the pragma shall be "#pragma GCC warning ..."

Features people have suggested:

For each message, both long and short versions should be available,
with a way for the user to choose which is printed.  Links to the
documentation are helpful too.  Mention which command-line options
control each warning when it's first printed.

Allow the user to specify warning groups somehow (with good design, we
may get this for "free").

Issues which have come up (and some ideas for solving them):

Some warnings have a few varieties of text, so we can't have one -W
option to control them via a standard message catalog.  I suggest the
-W option refer to a warning group, with a message for each variant
with a unique suffix.  Fictitious example: -Wundefined has function
and variable versions, "undefined" is a group referring to
undefined-function and undefined-variable.  Another:
-Wunused-var-tree-foo maps to -Wunused-var-tree-foo-1 and
-Wunused-var-tree-foo-2 for two similar (but unique) messages.

Suggested API quickie:

	void message (int warning_id, ...)
	void message_x (void *warn_state, int warning_id, ...)
	int message_p (int warning_id);

	void *message_get_state ();
	void *message_push_state ();
	void message_restore_state (void *old_state);

Example:

	...
	if (!TREE_FOO(x))
	  message (W_TREE_UNDECL_BAR, x);

	if (message_p (W_UNDEFINED_DECLS))
	  /* custom stuff */

	foo->ws = get_message_state ();
	...
	if (...)
	  message_x (foo->ws, W_USED_UNSET, foo->decl);


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]