<div dir="ltr"><div class="gmail_extra"><div>Hi Gábor,</div><div><br></div><div class="gmail_quote">On Mon, Jan 5, 2015 at 11:21 AM, Gábor Horváth <span dir="ltr"><<a href="mailto:xazax.hun@gmail.com" target="_blank">xazax.hun@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div class="h5">On 5 January 2015 at 11:02, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">+chandler and daniel; I think that are all the chefs we need for this particular porridge<br><br><div class="gmail_quote"><div><div>On Mon Jan 05 2015 at 10:05:02 AM Gábor Horváth <<a href="mailto:xazax.hun@gmail.com" target="_blank">xazax.hun@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><span style="font-family:arial,helvetica,sans-serif"><font>Hello everyone,<br><br></font></span></div><span style="font-family:arial,helvetica,sans-serif"><font>The Clang Static analyzer can output the diagnostics </font></span><span style="font-family:arial,helvetica,sans-serif"><font><font>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.<br><br></font></font></span><span style="font-family:arial,helvetica,sans-serif"></span></div><span style="font-family:arial,helvetica,sans-serif"><font>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.<br><br></font></span></div><span style="font-family:arial,helvetica,sans-serif"><font>In my opinion we need to extend the plist format to:<br></font></span></div><span style="font-family:arial,helvetica,sans-serif"><font>* Support notes that are not events<br></font></span></div><span style="font-family:arial,helvetica,sans-serif"><font>* Support fixits<br><br></font></span></div><div><span style="font-family:arial,helvetica,sans-serif"><font>What do you think, what would be the bast way to extend the format with those informations?<br></font></span></div></div></blockquote></div></div></div></blockquote></div></div></div></div></div></blockquote><div><br></div><div>Ted or Anna can say whether it's possible to extend the plist Static Analyzer output format and what's the best way to do this. Also, as you noted, most of PlistDiagnostics should be factored out and exposed in a form of some API to be reusable. This can be done completely independent of the ClangTidy part of the changes. Ted, Anna and Jordan should be the right people to send relevant patches to.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><span style="font-family:arial,helvetica,sans-serif"><font>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. </font></span><span style="font-family:arial,helvetica,sans-serif"><font>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 </font></span><span style="font-family:arial,helvetica,sans-serif"><font>PlistDiagnostics class available so we can inherit from it. What do you think, what would be the best way to organize these changes? <br></font></span></div></div></blockquote><div><br></div></div></div><div>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.</div></div></blockquote></div></div></div></div></div></blockquote><div><br></div><div>Chandler, do you have any thoughts on this?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_quote"><div>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).<br><br></div></div></blockquote><div> </div></div></div><div>In my proposal it would be possible to create a Diag Consumer that can consume both PathDiagnostics and regular Diagnostics. It would be possible, to make the same object to consume both Clang and Static Analyzer diags.</div></div></div></div></blockquote><div><br></div><div>The problem is not consuming messages from the Static Analyzer in a different format (ClangTidy already subscribes to PathDiagnostics), but the fact that ClangTidy uses Clang DiagnosticsEngine internally to handle diagnostics from the Static Analyzer, from all checks, and from the compiler. It means that to handle all information from PathDiagnostic we'd need to either extend Clang's diagnostic subsystem or rewrite a significant part of ClangTidy to introduce an alternative way to handle PathDiagnostics inside ClangTidy. It seems to me that the former is a much superior solution.</div><div><br></div><div>In any case we'd also need to extend the ClangTidyError structure (used to return ClangTidy results to clients) to accommodate additional information from PathDiagnostic.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>It may not be as clean as merging the two kinds of diagnostics, but I suspect this approach is faster to implement. In the long term I do agree that, it would be desirable to use the same mechanisms for both Static Analyzer and Clang. But I am not sure that, I have enough time for a refactoring like that. <br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_quote"><div><br></div><div>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.</div></div></blockquote><div><br></div></span><div>I don't know if we could rename that. PList is not Clang specific, Apple uses this format in other projects as well.  </div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_quote"><div><br></div><div>Cheers,</div><div>/Manuel</div><div> </div></div></blockquote><div><br></div><div>Thanks,<br>Gábor <br></div></div></div></div></blockquote></div><br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,</div><div class="gmail_extra">Alex</div></div>