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

[Alexander Kornienko]

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.

On Thu, Mar 12, 2015 at 3:47 AM, Andrew C. Morrow <andrew.c.morrow at gmail.com
> wrote:

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150313/3cf91a12/attachment.html>