[cfe-dev] Getting diagnostic information from clang

Nathan Wilson nwilson20 at gmail.com
Wed Jun 3 04:47:47 PDT 2015


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.

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

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/1deb3f51/attachment.html>


More information about the cfe-dev mailing list