This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: diagnostic.c cleanup, 2 of 3


Gabriel Dos Reis <gdr@integrable-solutions.net> 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
compilation.

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.

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.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]