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
