On top of what Jonathan already said, I would suggest the following:
On 11/10/18 13:20, David Gilbert wrote:
I am working on a project in which I need to parse the gcc compiler
diagnostics in order to automate the correction of the source code being
compiled.
Any tool that wishes to automate code corrections based on diagnostics should
be built on top of -fdiagnostics-parseable-fixits and
-fdiagnostics-generate-patch options. That is what they are designed for.
If you are building a GUI, you can show humans the human-readable diagnostic
while parsing the output given by those options.
If the above is not enough, you can create a GCC plugin
https://gcc.gnu.org/wiki/plugins to dump diagnostics in some specific format
(JSON?). A good example of a plugin is the GCC Python Plugin:
https://gcc-python-plugin.readthedocs.io/en/latest/working-with-c.html#spell-checking-string-constants-within-source-code
Note that diagnostics have much more internal info (types, declarations, file
locations) than what is shown in a human-readable form, and you could add to
GCC the ability to print diagnostics in a machine-readable format that also
included all that extra info. A first attempt is here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165#c10
but nowadays, using JSON instead of XML is probably best.
Modifying GCC is easier than you may think:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps
. In some cases, the 'mark' line that follows an 'invalid
conversion' diagnostic description identifies the object that generated the
diagnostic with a '^' and a string of '~'s but in some cases the mark line
only contains a caret that identifies the closing parenthesis of a function
call or declaration and the column value in the diagnostic also points to
this location. Why are there two behaviors?
In all cases where an automatic fix is possible, GCC should already produce a
correct location and a correct output of -fdiagnostics-parseable-fixits and
-fdiagnostics-generate-patch. Otherwise, it is either a bug or a pending
enhancement. Please report it: https://gcc.gnu.org/bugs/
. In the case described in the first question above, I have found
that the error:/warning: diagnostic is followed by a note: diagnostic that
DOES identify the argument that provoked the diagnostic. Is this entirely
consistent - i.e. will this 'note:' always be present?
If it is useful to have a note and the note is not there, please report a bug.
However, for your purposes, it will be even more useful to dump diagnostics in
a machine-readable format that can contain extra information about types,
declarations, file locations, etc.
. What I am really trying to find is a comprehensive description of
the gcc diagnostic message syntax. This is not in the documentation and
does not appear to be on the web either. Can you point me at a source?
As Jonathan said, the default output is designed for humans, not machines. But
it does strive to be consistent and it does follow some guidelines:
https://gcc.gnu.org/wiki/DiagnosticsGuidelines
If you find inconsistencies, please report them as bugs.
Or maybe even better, go ahead, and fix them :)
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps
Cheers,
Manuel.
