[cfe-dev] Match callback invocation order

[Billy O'Mahony via cfe-dev]

Hi Stephen,

thanks for the input.

Fortunately it's just C I'm interested in.

It's not just the order of certain function calls that are relevant; the
ordering of some conditional expressions and return stmts are also
relevant. And some of them are done via macros in which case, if I recall,
I see the source location being the location of the macro definition - not
the location of the macro usage.

It still sounds to me like MatchFinder is not doing exactly what it says on
the tin "The order of matches is guaranteed to be equivalent to doing a
pre-order traversal on the AST, and applying the matchers in the order in
which they were added to the MatchFinder."

I've experimented with RecursiveASTVisitor and that does invoke the
Visit<Node> functions in a natural/source-code order. So I will stick with
that strategy for now.

Cheers,
Billy.

On Wed, 17 Jun 2020 at 23:21, Stephen Kelly <steveire at gmail.com> wrote:

>
> On 15/06/2020 14:28, Billy O'Mahony via cfe-dev wrote:
> > I was expecting the matches to be in line-number order. In fact I'm
> > really depending on that for the custom tool I want to build as it
> > needs to analyze the order in which certain fns are called.
>
>
> I'm not sure line numbers are the thing to rely on if that is your goal.
> Consider for example a lambda inside a function (though maybe you are
> only working on C, not C++?). Your matcher for callExpr() would need to
> distinguish between calls inside and outside the lambda.
>
> Regardless of whether C++ is relevant to you, as David pointed out, this
> appears to be an optimization, so an alternative implementation might
> make sense anyway.
>
> I would recommend you match functions as you are with functionDecl() and
> then in your match callback, use something like (not tested)
>
> ast_matchers::match(functionDecl(
>
> forEachDescendant(callExpr(forFunction(functionDecl(equalsNode(FN)))))
>
> ), *FN, *Result.Context);
>
>
> The forFunction() matcher is the important part which will ensure that
> for example callExpr() in nested lambdas are not part of your result set.
>
> Then order the resulting nodes by their getBeginLoc() perhaps. (Macros
> may need to be accounted for).
>
> Thanks,
>
> Stephen.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200619/edd3504e/attachment-0001.html>