[cfe-dev] Getting diagnostic information from clang
klimek at google.com
Wed Jun 3 05:00:22 PDT 2015
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.
> >> 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.
has a section on how to write clang-tidy checks
> 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
> Does that help?
> >> I'd appreciate any help.
> >> Thank you,
> >> Nate
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev