Your changes to diagnostic machinery

[Kaveh R. Ghazi]

 > From: Gabriel Dos Reis <gdr@integrable-solutions.net>
 > 
 > Hi Kaveh,
 > 
 >   With your changes to have format-checking of diagnostics, it is no
 > longer possible to say things like
 > 
 >       pedwarn ("%H'%D' is not defined outside of function scope",
 >                &DECL_SOURCE_LOCATION (decl), decl);
 > 
 > in the C front end.  I'm getting:
 > 
 >   /home/gcc/src/egcs/gcc/c-common.c: In function `fname_decl':
 >   /home/gcc/src/egcs/gcc/c-common.c:1135: warning: unknown conversion type character `D' in format
 >   /home/gcc/src/egcs/gcc/c-common.c:1135: warning: too many arguments for format
 > 
 > which of course triggers a warning regression when bootstrapping.
 > 
 > %D is explicitly listed as diagnostic format specifiers. 
 > I'm going to temporary remove those attributes from the error() and
 > like unless you have plans to make the format-checking work... 
 > 
 > Thanks,
 > -- Gaby

Yes that was intentional on my part, as noted by these comments in
c-common.c:

	#include "c-tree.h"
	/* In order to ensure we use a common subset of valid specifiers
	   (between the various C family frontends) in this file, we restrict
	   ourselves to the generic specifier set.  */
	#undef GCC_DIAG_STYLE
	#include "toplev.h"

Since c-common.c is used in both the C and C++ frontends, I wanted to
make sure that only a common subset of both frontend's valid
specifiers are used in that file.  The only was to do that was to
limit outselves to the generic (AKA backend) set in that file.

Currently all of the C frontend specifiers are valid in the C++
frontend.  So in theory you could use the C specifiers in c-common.c,
but there's nothing inherent in the diagnostic framework to ensure the
C++ set remains a complete superset of the C diagnostic set.  That's
why I put in the more restrictive limitation.  E.g. if you allowed the
C set in c-common.c, one could theoretically add a new %K specifier to
the C set, use it in c-common.c (and you wouldn't get a format
warning.)  Then if the C++ frontend calls the code it would crash.

If you don't agree with my reasoning, and want to use C specifiers in
c-common.c, then all you have to do is remove the #undef (and the
comments) and it should work.  But it would be nice if you could
somehow tie together the two sets somehow to ensure they don't get out
of sync.  E.g. if in parsing the specifiers, the C++ frontend called
the C parser first and only checked it's own code for specifiers
unknown to C, then we could be confident that the C++ set is always a
complete superset of the C set.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu