(no subject)

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.

It looks like cfe-user is not widely used. That is maybe unfortunate, in my
opinion there should be a place to ask user-ish questions without
cluttering the dev list.

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.

That makes sense, thanks for clarifying. Perhaps the help text for
-extra-arg could be amended to give some indication of which sort of flags
are honored, and which are not? It really did look like exactly what I
wanted.

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?

Ideally I think the whole set of diagnostics switches described here:

http://clang.llvm.org/docs/UsersManual.html#controlling-how-clang-displays-diagnostics

My reasoning is that if you have an existing tool parsing clang diagnostics
output it may already be using any of these flags to customize, and if the
goal is to make clang-tidy useable as a drop in replacement for 'clang
-fsyntax-only' or similar it would need to support the same options with
the same effects on diagnostic presentation.

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

Great. I've not looked into the clang-tidy code but if you think this would
be reasonably straightforward I might just try to implement it.

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.

It looks like cfe-user is not widely used. That is maybe unfortunate, in
my opinion there should be a place to ask user-ish questions without
cluttering the dev list.

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.

That makes sense, thanks for clarifying. Perhaps the help text for
-extra-arg could be amended to give some indication of which sort of flags
are honored, and which are not? It really did look like exactly what I
wanted.

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?

Ideally I think the whole set of diagnostics switches described here:

http://clang.llvm.org/docs/UsersManual.html#controlling-how-clang-displays-diagnostics

My reasoning is that if you have an existing tool parsing clang
diagnostics output it may already be using any of these flags to customize,
and if the goal is to make clang-tidy useable as a drop in replacement for
'clang -fsyntax-only' or similar it would need to support the same options
with the same effects on diagnostic presentation.

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

Great. I've not looked into the clang-tidy code but if you think this
would be reasonably straightforward I might just try to implement it.

It shouldn't be difficult to implement. Though it may require some non-zero
effort to comply with the project's coding style. If you want to give it a
shot, I'll be happy to review the patch (the preferred way is to send it to
me, CC: cfe-commits@ via Phabricator <http://reviews.llvm.org>, as
described here <http://llvm.org/docs/Phabricator.html&gt;\).

-- Alex