<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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 class=""><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><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">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. So, I really would like to do this via parsing of clang-tidy diagnostics output, if possible.</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">
<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><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. 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><br></div><div><br></div></div></div></div>