Re: GCC XML diagnostics

[David Malcolm <dmalcolm at redhat dot com>]

On Thu, 2015-11-05 at 05:34 +0300, Mikhail Maltsev wrote:
> Hi all!
> 
> I'm pleased to say that two students of Lomonosov Moscow State University, Yuri
> Kemaev and Pavel Adamenko decided to work on a project related to GCC and
> hopefully will become new contributors.

Excellent.

> I'll be assisting them with this project. We have chosen to work on PR19165:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165 (machine-readable diagnostics
> output). Could any of maintainers please confirm that it is still a desired
> feature (the PR is marked as NEW, but just in case...)?
> 
> We are aware of GCC development schedule and thus aiming at GCC 7. Also we have
> seen David's series of patches related to diagnostics and will probably work on
> top of them, i.e. with those patches applied (because most of them are already
> approved).

(nods)

This is the version of the patch kit that's been approved (albeit with
some nits that need addressing):
  "[PATCH 00/10] Overhaul of diagnostics (v5)"
    https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02536.html

FWIW among other followup things I'm attempting for gcc6 on top of this
is to finish a revised version of the fix-it hints idea from an earlier
iteration:
  https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00732.html
  https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00747.html
which I'd want us to eventually offer in machine-readable format to an
IDE (I'm only working on the human-readable version of the output, but
am trying to keep the data model sane enough to allow for
machine-readable output later).

> I created several test cases which exhibit various entities (such as locations
> in files, includes, macro expansions, notes, etc.), which can occur in GCC
> diagnostics (which are worth keeping in mind when designing the XML diagnostics
> format):
> 
> https://github.com/miyuki-chan/gcc-xml-diagn/tree/master/examples

This looks useful to me also, thanks.

> Any advices about other test cases which are worth taking into account and the
> format itself?

FWIW, I had a go at creating an interchange format for static analysis
results (which includes compiler diagnostics).  The aim was to run lots
of static analyzers on lots of code, and capture the results in a
consistent format in a browseable database, hence the need for an
interchange format. [1] I created a format I call "Firehose":
  https://github.com/fedora-static-analysis/firehose
as a set of Python classes that can be roundtripped through XML and
JSON.  It currently provides parsers for the output of gcc,
clang-analyzer, cppcheck, and findbugs, and my gcc-python-plugin has a
branch that can emit firehose reports directly.

It can store more than just location+message: clang-analyzer can emit a
series of messages describing a trace of events leading to a bug, and
firehose can capture that (by reading the plist file).  We don't provide
that yet from gcc, but it might be worth thinking about.


Hope this is helpful
Dave

[1] for a talk on static analysis I gave at PyCon 2013; see
https://www.youtube.com/watch?v=bblvGKzZfFI&feature=youtu.be&t=898
https://speakerdeck.com/pyconslides/death-by-a-thousand-leaks-by-david-malcolm