Another issue with diagnostic format-checker

[Gabriel Dos Reis]

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

|  > From: "Zack Weinberg" <zack@codesourcery.com>
|  > 
|  > Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|  > 
|  > >   (1) format checking  is done when we use GCC (modulo versions).
|  > >   (2) the bootstrapping compiler is told (via attributes) what to check.
|  > >   (3) the attraibutes are hardwired in the files.
|  > >
|  > > the last point is what is causing the trouble.
|  > >
|  > > When the current front-end (which we want to build an executable for)
|  > > invokes the bootstrapping compiler, it is its responsability to tell
|  > > what is the set of format specifiers.  That set is specified
|  > > statically via -DGCC_DIAG_STYLE=__gcc_xxx__, not the way it is
|  > > currently done.  But statically. 
|  > 
|  > Okay, I understand this.  However, this suggests that you intend to
|  > compile files shared between front ends more than once, with different
|  > settings of GCC_DIAG_STYLE.  I think this is a bad idea.  The actual
|  > content of the file does not change - the .o file should be identical -
|  > and, in particular, the format specifiers that are used in that file
|  > do not change.  You are in effect doing an intersection operation on
|  > the diagnostic styles - far better to perform that intersection once,
|  > write the result into c-format.c, and then wire the appropriate
|  > settings into the files themselves.  Then you need not compile files
|  > more than once, and you need not add complexity to the Makefile.
|  > zw
| 
| FWIW, I agree we should only compile c-common.c once.  That means we
| get to choose and apply exactly one single format style.

The mulitple compilation of c-common.c is something Zack just threw in
the dicussion.  I fear that would add one more level of confusion.

| Currently the "C set" is a proper subset (i.e. completely contained
| within) the "C++ set".  Therefore the C-set is also the intersection
| and it is okay to enforce this format style in c-common.c (as of
| today.)

Agreed.

| What I tried to explain to Gaby (and either I failed to explain it
| well enough or he understood me and saw it as unimportant) is that the
| C-set being the intersection is pure happenstance.

It is not that I did see it as unimportant.  What is true and will
remain so (in forseable future) is that the "C set" is a subset of the
"C++ set" for obvious reasons.  So I don't see it as a pure
happenstance. I see it as a necessity of fact. 

What however remains unclear to me is the "Objective-C set".  I'm not
an objc expert and I don't know how objc people want to have their
front end close to C.

| There's nothing
| inherent in the diagnostic framework to enforce this and it could
| cause problems in the future if we add wierd specifiers to the C-set
| without also adding them to the C++ set.

The diagnostic framework does already some check at run-time.  If a front
end does not register a format specifier, it halts compilation if the
execution path uses it.  So we do have some consistency check.

What the format specifiers checker buys us is the ability to tell
whether a given pair  of format specifier and argument are used
consistently.  It does NOT check whether a format specifier is
*effectively* handled -- that check is done at run-time.

Both are complimentary, and NOT mutually exclusive.

|  I find this need for
| manually synchronizing them error-prone, so I asked Gaby in my first
| message to have the C++ format parser call the C format parser to
| slurp those specifiers the C frontend already knows about.  This would
| ensure that the C-set is always the intersection.  I think Gaby agreed
| to put this on his "TODO" list.

Yes, it has been since your suggestion.

| On the issue of where we set GCC_DIAG_STYLE, I lean towards leaving it
| as-is.  I.e. have a default in toplev.h, but override it in c-tree.h
| and cp-tree.h, and live with the file ordering issue.

That requires that every body that includes a file needs to scan them
to see whether it included files in the right order.  Too fragile.
Zack, somewhere in this discussion, expressed his position against
having people to "go look somewhere else"; I think leaving the thing
as-is 

| Gaby's solution provides no clean way to apply the appropriate -D flag
| to exactly the right files without introducing problematic changes to
| the Makefiles.  (I'm willing to be proven wrong by a clean patch.)

I didn't see anyone explaning the *actual* problem with what I
suggested (I'm not saying it was the final solution to go, but a
concrete start of idea).  The only comment I got was:  A blind
reaction with no technically fair reason.

| Zack's solution requires us to set GCC_DIAG_STYLE in each and every
| C-family frontend file.  There are around 50 of these files.

That would be a regression and a nightmarre for maintenance.

-- Gaby