clang-tidy 3.6 - how to suppress caret diagnostics?

Hi -

I asked this over on cfe-user last week, but got no response there:

http://lists.cs.uiuc.edu/pipermail/cfe-users/2015-March/000662.html

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. However, passing -extra-arg=-fno-caret-diagnostics to clang-tidy seems to have no effect, and clang-tidy rejects the bare -fno-caret-diagnostics flag.

Please see the original post for more details.

Any suggestions?

Thanks, Andrew

In article <CA+Acj4e9n7Y97T_jC4CMCkaVH+kVgBFfOfYB9JH+SLw0KemUeQ@mail.gmail.com>,
    "Andrew C. Morrow" <andrew.c.morrow@gmail.com> writes:

I asked this over on cfe-user last week, but got no response there:

http://lists.cs.uiuc.edu/pipermail/cfe-users/2015-March/000662.html

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?

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.

> 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

Hi Andrew, Richard,

I asked this over on cfe-user last week, but got no response there:

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.

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.

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?

I can't promise that I can add the support for these quickly, but it
definitely seems like a useful thing to have.

> 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.

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 nightly builds <http://llvm.org/apt/> without
hassle of compiling clang-tidy yourself.

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.

You're just the first one who asks for this feature.

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

-- Alex