[cfe-dev] How to get Function Definition from CallExpr

[Kevin Boos]

Ah, I see now that there are multiple hasBody() functions. I just tried
using that hasBody(FunctionDecl *&), and it returns false. Makes sense
because it's essentially the same as me manually iterating over each
redecl.

I am indeed using ASTConsumer alongside a RecursiveASTVisitor in the
libtooling environment. So you're saying that my code (some analysis inside
VisitFunctionDecl or VisitStmt, per se) will be unaware of the existence of
a future foo() definition until VisitFunctionDecl is called on that foo()
definition?

If so, then there is no way to inspect the body/definition of foo() until
VisitFunctionDecl visits it, right? Specifically, while visiting the main()
FunctionDecl*, I cannot access the Stmts inside the foo() definition?
That's really what I need.

Thanks again,
Kevin


On Tue, Jul 16, 2013 at 6:29 PM, Eli Friedman <eli.friedman at gmail.com>wrote:

> On Tue, Jul 16, 2013 at 4:06 PM, Kevin Boos <kevinaboos at gmail.com> wrote:
> > Thanks so much for your quick reply.
> >
> > I have been using hasBody(), isThisDeclarationADefinition(), etc... to
> > determine if the Decl* i'm looking at is actually a definition -- those
> are
> > useful. I was merely testing things with the redecl chain just to see if
> I
> > could get the definition that way even if getDirectCallee() returned the
> > function prototype.
>
> There's also a form of FunctionDecl::hasBody() which lets you retrieve
> the definition.
>
> > How would I determine if clang has parsed the definition? Sorry, I'm a
> bit
> > of a beginner here. I thought that Clang first parsed the source file,
> built
> > an AST, and then allowed you to Visit each type of AST node. All I know
> is,
> > at that point, Clang would not yet have visited the definition of foo(),
> but
> > I assume it would have parsed it...?
>
> It depends on how exactly you're getting at the AST.  The ASTConsumer
> API in particular returns one declaration at a time.
>
> -Eli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130716/ec4df18a/attachment.html>