<div dir="ltr"><div dir="ltr">On Mon, 15 Jun 2020 at 21:16, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 25 May 2020 at 14:56, Stephen Kelly via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</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">On 20/12/2019 21:01, Stephen Kelly via cfe-dev wrote:<br>
> <br>
> Hi,<br>
> <br>
> (Apologies if you receive this twice. GMail classified the first one as <br>
> spam)<br>
> <br>
> Aaron Ballman and I met by chance in Belfast and we discussed a way <br>
> forward towards making AST Matchers easier to use, particularly for C++ <br>
> developers who are not familiar with the details of the Clang AST.<br>
> <br>
> For those unaware, I expanded on this in the EuroLLVM conference this <br>
> year, and then expanded on it at ACCU:<br>
> <br>
>   <a href="https://steveire.wordpress.com/2019/04/30/the-future-of-ast-matching" rel="noreferrer" target="_blank">https://steveire.wordpress.com/2019/04/30/the-future-of-ast-matching</a><br>
> <br>
> One step in the process of getting there is changing the default <br>
> behavior of AST Matchers to ignore invisible nodes while matching using <br>
> the C++ API, and while matching and dumping AST nodes in clang-query.<br>
> <br>
> I think this is the most important change in the entire proposal as it <br>
> sets out the intention of making the AST Matchers easier to use for C++ <br>
> developers who are not already familiar with Clang APIs.<br>
> <br>
> To that end, I've written an AST to motivate the change:<br>
> <br>
> <br>
> <a href="https://docs.google.com/document/d/17Z6gAwwc3HoRXvsy0OdwU0X5MFQEuiGeSu3i6ICOB90" rel="noreferrer" target="_blank">https://docs.google.com/document/d/17Z6gAwwc3HoRXvsy0OdwU0X5MFQEuiGeSu3i6ICOB90</a> <br>
> <br>
> <br>
> We're looking for feedback before pressing forward with the change. I <br>
> already have some patches written to port clang-tidy and unit tests to <br>
> account for the change of default.<br>
<br>
<br>
This change is now in master.<br></blockquote><div><br></div><div>Is this change responsible for <a href="https://bugs.llvm.org/show_bug.cgi?id=46287" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=46287</a> ? If so, I think the current behavior is very confusing, and seems harmful. By default, a cxxConstructExpr matcher no longer matches all CXXConstructExprs, which seems very strange and surprising, and likewise it's alarming that an AST dump from clang-query no longer correctly dumps the AST.</div><div><br></div><div>Perhaps as an alternative, we should not skip implicit nodes when trying to match a node that might be implicit (analogous to how Type::getAs steps over sugar nodes except when looking for that type sugar node),</div></div></div></blockquote><div><br></div><div>To be clear: the behavior I think we should consider is that we consider whether each implicit node matches our matcher before stepping over it. So (for example) an (implicit) ImplicitCastExpr wrapping an (implicit) CXXConstructExpr wrapping an IntegerLiteral would be matched by a cxxConstructExpr() matcher, but would also be matched by an integerLiteral() matcher.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> and instead of hiding implicit nodes in the AST dump we should dim them out but still show them?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
clang-query has also been updated to allow setting the traversal mode. eg:<br>
<br>
   set traversal AsIs<br>
<br>
Since the original RFC I also added clang-query support to <a href="http://godbolt.org" rel="noreferrer" target="_blank">godbolt.org</a>, <br>
so you can experiment with it there instead of my personal instance of <br>
compiler-explorer:<br>
<br>
   <a href="https://gcc.godbolt.org/z/uwTgZS" rel="noreferrer" target="_blank">https://gcc.godbolt.org/z/uwTgZS</a><br>
<br>
If anyone watched my talk from EuroLLVM linked in my blog above, I am <br>
interested in feedback to know which feature I presented there you would <br>
most like to see upstreamed.<br>
<br>
Thanks,<br>
<br>
Stephen.<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>
</blockquote></div></div>