[cfe-dev] PList output for clang Tidy

[Marc J. Driftmeyer]

Yes, Plist goes back to 1986 and in its modern form is just a straight 
up xml file.

It is cross-platform supported on FreeBSD, Linux and elsewhere. Adding 
these features, and or making it the same level quality from OS X, iOS, 
FreeBSD, Linux, etc., via Clang/Clang-Tidy makes a lot of sound sense.

- Marc


On 01/05/2015 09:49 AM, Anna Zaks wrote:
> + Ted
>
>> On Jan 5, 2015, at 2:02 AM, Manuel Klimek <klimek at google.com 
>> <mailto: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 at gmail.com 
>> <mailto:xazax.hun at gmail.com>> wrote:
>>
>>     Hello everyone,
>>
>>     The Clang Static analyzer can output the diagnosticsin 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 makePlistDiagnostics 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)
>
>>
>> Cheers,
>> /Manuel
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- 

Marc J. Driftmeyer

email:mjd at reanimality.com <mailto:%27mjd at reanimality.com%27>
www:www.reanimality.com <http://www.reanimality.com>

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