This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
[RFC] Cleaning and extening the diagnostics machinery
- To: gcc at gcc dot gnu dot org
- Subject: [RFC] Cleaning and extening the diagnostics machinery
- From: Gabriel Dos Reis <Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr>
- Date: 31 May 2001 14:08:48 +0200
- Cc: "Zack Weinberg" <zackw at Stanford dot EDU>
- Organization: CMLA, ENS Cachan -- CNRS UMR 8536 (France)
"Zack Weinberg" <zackw@Stanford.EDU> writes:
| On Tue, May 22, 2001 at 09:49:45PM +0200, Gabriel Dos Reis wrote:
| > Yes, diagnostic.c is a mess and plans are to clean it.
|
| Can you share some of these plans (better in a fresh thread)? One of
| my near-future things to do is try to wire cpplib into diagnostic.c
| for C front ends, so that we can get column numbers.
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;
The patch below (made against mainline a month ago) puts in the
preliminaries for implementing diagnostics which are not errors nor
warnings. Obviously, it needs to be updated -- at the time it passes
bootstrapping.
In the short term, I would like to make diagnotics.c useable by
independent components of GCC (cppplib, genattrb, language front-ends,
middle-ends). That means getting rid of some redundant functions and
sequestering some functions into separate modules (I'm thinking of RTL
related functions).
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.
For the mid-term, I would like to make the C++ tree printing machinery
available to the C front-end, and provide a better implementation in
place of cp/error.c
In the long term, for C++ at least, I'd like highlighting support and
better formatting logic.
Comments?
-- Gaby
diag.diff.gz