Your changes to diagnostic machinery

[Kaveh R. Ghazi]

 > From: Gabriel Dos Reis <gdr@integrable-solutions.net>
 > 
 > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
 > 
 > | 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. 

That's not the issue.

My point is that we have to choose at compile-time on a compilation
unit (per-file) basis which specifier set is valid for each particular
file.  You can't have more than one valid set in any particular file,
because each file is compiled exactly once.  Given that, which set do
we choose for files linked into more than one language like
c-common.c?

Choosing anything beyond the generic set involves implicit assumptions
about that set being valid across all language frontends which use
that file.  I.e. the set you choose must be the intersection of all
language specifier sets for languages which use that file.  Currently
I admit the "C set" fits this bill for c-common.c, it understands %D.
No argument there, I got that.

But there is nothing in the design of the diagnostic system which
enforces this requirement.  We just got lucky, and I wasn't
comfortable relying on that.


 > 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

No I strongly disagree with you here.  If you use a specifier only
valid in the C++ frontend in c-common.c, what's to stop the C frontend
from calling that same code and crashing because it doesn't understand
that specifier?

If you find yourself needing to use a C++ frontend specifier in
c-common.c, then I suspect that code should really live in the cp/
directory.


 > 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.
 > [...]
 > Thanks,
 > -- Gaby

Sorry that makes no sense to me, "registered at start-up" of what
exactly, the compiler being built?  That's too late, how can cc1plus
at runtime tell the compiler that built it what specifiers are valid
without time travel? :-)

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