Re: [RFC] Cleaning and extening the diagnostics machinery

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Gabriel Dos Reis wrote:-

> As said earlier, I would like to turn the coarse grained diagnostics
> machinery into a finer grained one. In the short term I would like GCC
> to categorize diagnostics into at least seven kinds:
> 
>    - "Fatal error: " (unrecoverable), maybe caused by environmental host;
>    - "Internal compiler error: ", caused by bugs in the compiler;
>    - "Sorry, unimplemented: " for unimplemented fonctionalities;
>    - "Error: ", ill-formed constructs;
>    - "Warnings: ", well-formed constructs but possibly unintended;
>    - "Anachronism: " anachronistic constructs;
>    - "Note: ", informative notes requested by user;

Cool.  I'm not sure what you mean by "Anachronism", but if it's
different I'd like a "Deprecated: " too.

> In the short term, I would like to make diagnotics.c useable by
> independent components of GCC (cppplib, genattrb, language front-ends,
> middle-ends).

In the spirit of recent rewrites of some portions of GCC (hashtable.c,
cpplib), please make the diagnostic machinery re-entrant.  This will
be necessary to work properly with cpplib anyway.

[Aside: I'm kind-of working on a re-entrant command line grokker,
which I hope to put in gcc.c, cppinit.c, toplev.c and eventually each
front end too.  It'll simplify a lot of stuff, and hopefully allow
good new things to be possible.]

> Each client could use the diagnostic machinery by defining appropriate
> lang_printer and setting begin_diagnotic/end_diagnostic fields of
> `struct diagnostic_context'.  Other aspects need to be made
> parameterizable. 

Can we try to get away from this global function lang_* stuff?  I
already removed about 6 such functions when working on integrated CPP
+ front-ends about 6 months ago, but many remain (I'd like to get rid
of all such functions and most global variables too, but that's for
the future).  It also makes it hard for integrated CPP: you might get
duplicate definition issues with cpplib and the front-end.

I'd suggest putting all configuration in a structure, with callbacks
for client-supplied functionality.  That allows clients to not have to
define dummy functions that do nothing, and the callbacks to be static
rather than global.  It would give you re-entrancy too, I think.

Also, please allow for clients to supply column numbers in
diagnostics.  cpplib has and uses this information; it'd be nice for
the C front ends to use it too.

> In the long term, for C++ at least, I'd like highlighting support and
> better formatting logic.

What do you mean here?  Just curious.

Neil.