<div dir="ltr">Thanks to Stephen and David for your help. I've filed a bug report 

<a href="https://bugs.llvm.org/show_bug.cgi?id=46423">https://bugs.llvm.org/show_bug.cgi?id=46423</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 20 Jun 2020 at 17:26, Stephen Kelly <<a href="mailto:steveire@gmail.com">steveire@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 19/06/2020 15:38, Billy O'Mahony wrote:<br>
> Hi Stephen,<br>
><br>
> thanks for the input.<br>
><br>
> Fortunately it's just C I'm interested in.<br>
><br>
> It's not just the order of certain function calls that are relevant; <br>
> the ordering of some conditional expressions and return stmts are also <br>
> relevant. And some of them are done via macros in which case, if I <br>
> recall, I see the source location being the location of the macro <br>
> definition - not the location of the macro usage.<br>
<br>
<br>
Yes, macros add complexity.<br>
<br>
<br>
><br>
> It still sounds to me like MatchFinder is not doing exactly what it <br>
> says on the tin "The order of matches is guaranteed to be equivalent <br>
> to doing a pre-order traversal on the AST, and applying the matchers <br>
> in the order in which they were added to the MatchFinder."<br>
<br>
<br>
Yes, this is at least a documentation bug, if the implementation isn't <br>
changed.<br>
<br>
Thanks,<br>
<br>
Stephen.<br>
<br>
<br>
</blockquote></div>