Re: [RFC] Cleaning and extening the diagnostics machinery

[Gabriel Dos Reis <Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr>]

Neil Booth <neil@daikokuya.demon.co.uk> writes:

| 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.

Point taken.

| > 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.

OK.

| > 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?

Yes, certainly.

[...]

| Also, please allow for clients to supply column numbers in
| diagnostics.

This is handled by suppling appropriate definition for the
begin_diagnostic field, whose purpose is to print diagnostic
location/context -- the default would be to display `file-name:line:'
but a client can choose to do whatever it thinks is best for it.

-- Gaby