[cfe-dev] Getting diagnostic information from clang

[Nathan Wilson]

On Jun 3, 2015 7:00 AM, "Manuel Klimek" <klimek at google.com> wrote:
>
> On Wed, Jun 3, 2015 at 1:47 PM Nathan Wilson <nwilson20 at gmail.com> wrote:
>>
>>
>> On Jun 3, 2015 4:23 AM, "Manuel Klimek" <klimek at google.com> wrote:
>> >
>> > On Tue, Jun 2, 2015 at 9:25 PM Nate Wilson <nwilson20 at gmail.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Is there any way to get information about where a diagnostic came
from in clang, e.g. the source from which the Diagnostic was constructed?
For example, when I try to assign to a member which doesn't exist in my
class/struct, I get:
>> >>
>> >> error: no member named 'foo' in 'Bar'
>> >>
>> >> Is there anyway for clang to tell me where this Diagnostic came from?
>> >
>> >
>> > Do you mean where in the Clang source it was generated?
>>
>> Yes I do, but i imagine it's not possible. Correct? Sorry for the
ambiguity. I'm asking about this because I'd like to see how clang
determined what I'm doing is wrong by looking at a backtrace (or
something). Not just in this case, but for something a little more
complicated in general as well which won't get put into the AST.
>
>
> Generally, you search for the diagnostic in the clang source code.
Diagnostics are in so-called tablegen files. Those will define the
diagnostic text and a constant that's used in the code. Once you have that
constant, you look for that constant in the clang source code, which then
shows you under which circumstances that diagnostic is emitted.

Yeah, I wasn't sure if there was a different way to find them. That makes
sense.

>
>>
>> >>
>> >> Similarly, when the AST is constructed and I'm able to assign a value
to foo, is there anyway for me to get the information about where the
lookup is correctly found (for a data member in particular)?
>> >>
>> >> Or, do would I need to do some libAST tooling, get called back when a
match is found, and debug from there?
>> >
>> >
>> > Depends on what you want to do - can you expand on what you are trying
to build?
>> >
>>
>> Sure, in this case there's a bug/feature request which I'd like work on
by looking at data members when they're being assigned to in a BinaryOp,
and if the syntax is not this->... = ..., emit a warning.
>
>
> I'd personally think this should be a clang-tidy warning, not a compiler
warning (as it seems purely stylistic).
> Clang-tidy warnings are generally easier to write and a good way to get
into clang's AST without needing to understand the compiler; if a warning
is shipped in clang-tidy and found more broadly useful / catching real
bugs, we can make it a real compiler warnings.
>
> http://clang.llvm.org/extra/clang-tidy.html
> has a section on how to write clang-tidy checks

Okay, thanks. I'll take a look and try to get in there. I don't recall the
bugzilla number off hand, but it was from a long time ago, maybe before
tidy existed...

>>
>> That's the source of my question. But, something else off the top off my
head would be to see the valid use of a dependent type being looked up and
used.
>>
>> Does that help?
>>
>> >>
>> >> I'd appreciate any help.
>> >>
>> >> Thank you,
>> >>
>> >> Nate
>> >>
>> >>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150603/ea1ebb7d/attachment.html>