<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi Andrew, Richard,</div><div class="gmail_quote"><br></div><div class="gmail_quote">> <span style="font-size:12.8000001907349px">I asked this over on cfe-user last week, but got no response there:</span></div><div><span style="font-size:12.8000001907349px"><br>Sorry, I wasn't even aware of this list before I saw your e-mail. Currently cfe-dev is a better place for clang-tidy questions.</span></div><div class="gmail_quote"><br></div><div class="gmail_quote">Re: your main question. While in general YAML/JSON/... would be a better format to output clang-tidy results for other tools, I see that there are valid use cases for parsing text diagnostic output, as there are many tools doing this with compiler diagnostics. And we certainly need to allow configuration of the diagnostic output. However --extra-arg is just not the right mechanism for this, as it just modifies compilation arguments clang-tidy gets from a compilation database. We can't configure output of clang-tidy using these arguments, as they can be arbitrary and even different for each processed file.</div><div class="gmail_quote"><br></div><div class="gmail_quote">A better way to make diagnostic output configurable is to add top-level clang-tidy flags. Is it the only flag you need or would some other similar flags be useful as well?</div><div class="gmail_quote"><br></div><div class="gmail_quote">I can't promise that I can add the support for these quickly, but it definitely seems like a useful thing to have.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Thu, Mar 12, 2015 at 3:47 AM, Andrew C. Morrow <span dir="ltr"><<a href="mailto:andrew.c.morrow@gmail.com" target="_blank">andrew.c.morrow@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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Mar 11, 2015 at 7:00 PM, Richard <span dir="ltr"><<a href="mailto:legalize@xmission.com" target="_blank">legalize@xmission.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"><br><span><br>
> I have a need to parse the output of clang-tidy, and the presence of caret<br>
> diagnostics makes this more difficult, so I'd like to turn them off.<br>
<br>
</span>If you're trying to feed the analysis of clang-tidy into another tool,<br>
wouldn't it be more useful to have the output in JSON format or<br>
something that is designed to be machine consumable instead of human<br>
consumable?<br></blockquote><div><br></div></span><div>In my particular case, the consuming tool is the emacs flycheck package. I'm attempting to extend it with a new C/C++ checker that invokes clang-tidy as the checker for projects with a compilation database.</div><div><br></div><div><a href="http://flycheck.readthedocs.org/en/latest/dev/extending.html#defining-new-syntax-checkers" target="_blank">http://flycheck.readthedocs.org/en/latest/dev/extending.html#defining-new-syntax-checkers</a><br></div><div><br></div><div>I'm not particularly familiar with the flycheck internals, so I'm basing my work on the existing clang -fsyntax-only based syntax checker, which extracts relevant errors and warnings by matching line patterns in the clang output. That checker invokes clang with -fno-caret-diagnostics, among other flags, to simplify its parsing task. I had hoped to simply adopt the same matching rules for the clang-tidy based checker, but I can only do so if I can suppress the caret diagnostics from clang-tidy.</div><div><br></div><div>While I agree with you that machine readable output would be the best way to feed information to a consuming tool in general, I'm worried that extending flycheck to consume JSON or similar would be a much larger project than what I had hoped to undertake, though I have not yet investigated whether it already supports it easily. Not to mention that such a feature wouldn't be available in a stable clang release for some time.</div></div></div></div></blockquote><div><br></div><div>Given that clang-tidy is still under active development, I don't think it makes much sense to stick to stable clang releases. In case you're on Ubuntu/Debian, you can use <a href="http://llvm.org/apt/">nightly builds</a> without hassle of compiling clang-tidy yourself. </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> So, I really would like to do this via parsing of clang-tidy diagnostics output, if possible.</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">
<br>
If we have to change clang-tidy, I would think that generating machine<br>
consumable output would be the better change instead of just<br>
suppressing the caret diagnostics.<br></blockquote><div><br></div></span><div>Even if parsing text diagnostics isn't the most elegant or robust approach, reading the clang-tidy help text descriptions for -extra-arg and -extra-arg-before sets, at least for me, an expectation that clang-tidy -extra-arg=-fno-caret-diagnostics would do the right thing. If that behavior is intentionally unsupported, some diagnostic should probably be issued, rather than silently ignoring the users request. It is also I think surprising that clang-tidy doesn't directly support -fno-caret-diagnostics, -fno-color-diagnostics, etc., given that one of its main purposes is generating diagnostics.</div></div></div></div></blockquote><div><br></div><div>You're just the first one who asks for this feature.</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> Passing -fno-caret-diagnostics was what I tried first, and I would not have reached for -extra-arg had that worked.</div><div><br></div><div>In any event, I appreciate your getting back to me.</div><div><br></div><div>Thanks,</div><div>Andrew</div></div></div></div></blockquote><div><br></div><div>-- Alex </div></div>
</div></div>