[cfe-dev] clang-tidy 3.6 - how to suppress caret diagnostics?

[Andrew C. Morrow]

On Wed, Mar 11, 2015 at 7:00 PM, Richard <legalize at xmission.com> wrote:

>
>
> > I have a need to parse the output of clang-tidy, and the presence of
> caret
> > diagnostics makes this more difficult, so I'd like to turn them off.
>
> If you're trying to feed the analysis of clang-tidy into another tool,
> wouldn't it be more useful to have the output in JSON format or
> something that is designed to be machine consumable instead of human
> consumable?
>

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.

http://flycheck.readthedocs.org/en/latest/dev/extending.html#defining-new-syntax-checkers

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.

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.


>
> If we have to change clang-tidy, I would think that generating machine
> consumable output would be the better change instead of just
> suppressing the caret diagnostics.
>

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.

In any event, I appreciate your getting back to me.

Thanks,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150311/4d841d4c/attachment.html>