Re: Your changes to diagnostic machinery

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

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

Currently, what are the C family front ends that use the machinery?  I
can see C, C++ and Objective C.  All of them recognize %D and
variants. 

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

Yes but here, %D is a C front-end specifiers, used by Objective-C and C++.  

Furthermore, because C++ codes can call codes in c-common.c, it is
important that C++ front end specifiers be allowed to pass through.
That is true for C++, but it is also true for any front-end that
happens to  use c-common.c

That is why I said (when you first brought the issue) that the format
specifiers should be registered at start-up by front-end and not
something syntactically hardwired in the code.

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

OK, I'll do that in order to get the projet at hand done.

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

I'll put that on my TODO list.

Thanks,

-- Gaby