This is the mail archive of the
mailing list for the GCC project.
Re: diagnostic.c cleanup, 2 of 3
Zack Weinberg <email@example.com> writes:
| Gabriel Dos Reis <firstname.lastname@example.org> writes:
| > I don't know exactly where you would like to go and it would be
| > helfpul to say exactly the final goal you'll like to achieve, that
| > helps me to have some picture of what is going on.
| > At any rate you should not count on having diagnostic_for_decl around
| > for a long time.
| My immediate goal is to send diagnostics reported by cpplib through
| diagnostic.c. This will allow me to get rid of a whole bunch of code
| (almost all of cpperror.c, plus some loose ends elsewhere). More
| importantly, it'll mean that errorcount is always accurate, instead of
| being updated from cpplib's internal error count at the end of
That is most wlecome since it has been a project repeatedly mentioned
to od sometime in the future.
| The minimal change I needed was in the patch you're responding to: I
| needed diagnostic_set_info (&d, ..., DK_ICE); report_diagnostic (&d);
| to print the bug-report request and terminate compilation. I thought
| it would be a good idea to clean up other inconsistencies in
| diagnostic.c while I was at it, hence the somewhat larger patch.
I now understand where you're going. I don't know if that is something
you were considering, but it would be practical if we don't pass
location information separately as file and line as arguments to
| The other changes to diagnostic.c I am contemplating are: (1) Add
| support for %m to the formatter. This would eliminate the need for
| fatal_io_error, and cpplib's cpp_errno. (2) Figure out some way to
| share diagnostic.def with cpplib. This is tricky only because I want
| to move cpplib into its own top-level directory at some point, and I
| don't want to make that harder. But having DK_* codes used by
| everything but cpplib, and DL_* codes with the same meanings used by
| cpplib, is silly.
Agreed. At some point, I will split the output_buffer logic from
diagnostic.c so that the logic can be used by other parts of the
compiler. Also, one would need to get rid of tree specific thingies
in diagnostic.c (which partly is why I would like to get rid of
xxx_with_decl). You will need that non dependency if you want to link
cpplib against diagnostic.c and also make it standalone.