[cfe-dev] PList output for clang Tidy

[Manuel Klimek]

 On Mon, Jan 5, 2015, 18:49 Anna Zaks <ganna at apple.com> wrote:

+ Ted

On Jan 5, 2015, at 2:02 AM, Manuel Klimek <klimek at google.com> wrote:


 +chandler and daniel; I think that are all the chefs we need for this
particular porridge


 On Mon Jan 05 2015 at 10:05:02 AM Gábor Horváth <xazax.hun@
<xazax.hun at gmail.com>gmail.com <xazax.hun at gmail.com>> wrote:

 Hello everyone,

The Clang Static analyzer can output the diagnostics in plist format. It is
a useful feature, because it is easy to parse that format with 3rd party
tools, hence integrating clang tools with others.

Unfortunately the plist reporting format is not supported by Clang Tidy. We
would like to add plist support to it. This involves a lot of changes both
to the format and the public API, so I want your opinion, how to do it.

In my opinion we need to extend the plist format to:

* Support notes that are not events

* Support fixits

What do you think, what would be the bast way to extend the format with
those informations?

The plist reporting related functionality is not part of the Clang public
API at the moment. The best would be, if the Static Analyzer and regular
diagnostics could be reported to the same plist output file. To achieve
this, the diagnostic consumer that outputs to the plist should support both
PathDiagnostics and regular Diagnostics. It would be redundant to
reimplement the whole functionality in Clang Tidy. To reduce the
redundancy, we would like to refactor several plist related helper
functions out from PlistDiagnostics and make it available in public
headers. We would also like to make PlistDiagnostics class available so we
can inherit from it. What do you think, what would be the best way to
organize these changes?

  If I remember correctly, Chandler has long ago proposed to merge the
different diagnostic types we have into one central clang diagnostic type
that supports all our use cases.

I personally would need to see a CL to judge whether it makes sense, but
generally, I think what you say sounds like it's the right direction (if
you agree with the sentence above: make clang's basic diagnostic system
powerful enough to support the analyzer's use cases, and then switch the
analyzer and clang-tidy to use it).


 I'd vote for renaming Plist to something non-horrible in the process, (I
still have no idea what the "P" stands for), but that's bikeshedding.

 http://en.wikipedia.org/wiki/Property_list

(plist is the specific format widely used at Apple)

 Showing my ignorance - thanks for the link, I want aware, that explains a
lot...



Cheers,

/Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150105/eb5e41f9/attachment.html>