<div dir="ltr"><div>On Mon, Feb 25, 2019 at 9:37 PM Jan Korous <<a href="mailto:jkorous@apple.com">jkorous@apple.com</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">Hi Ilya,<br>
<br>
This looks awesome!<br>
<br>
I am just curious - since the expected workflow is to always start with ASTMatchers do you plan to provide utilities to overcome limitations of AST you mention?</blockquote><div>Syntax trees are actually independent of matchers, an input to build them is a clang AST and one can find syntax tree nodes for the corresponding AST nodes afterwards.</div><div>The matchers are just another way to find interesting AST nodes, so we can use the same mechanism to map from the AST node (found by the matcher) to the syntax tree node.</div><div><br></div><div>I guess the confusing part of the document was the FAQ section about ASTMatchers, I've changed it to make it clear ASTMatchers are not planned as the only input source.</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">For example - do you plan to implement some functionality for separating a set of AST nodes based on their syntactic nature?<br></blockquote><div>No plans to do this and it feels like building the syntax tree might be an overkill to solve this. Intuition is that this should be solvable with a switch on the AST node types.</div><div>That said, this is something that would definitely pop up while implementing the syntax trees.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks.<br>
<br>
Jan<br>
<br>
<br>
> On Feb 25, 2019, at 10:50 AM, Ilya Biryukov via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> Hi everyone, <br>
> <br>
> We would like to propose a new way of writing refactorings on top of the Clang infrastructure. Our is to have nice APIs that hide tedious tasks, like dealing with macros or adding parentheses around changed expressions. <br>
> <br>
> Design is discussed in detail here:<br>
> <a href="https://docs.google.com/document/d/161XftOcF-ut1pGQr5ci9kXd_y0jRQl3y9sVyvuEkLDc/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/document/d/161XftOcF-ut1pGQr5ci9kXd_y0jRQl3y9sVyvuEkLDc/edit?usp=sharing</a> <br>
> <br>
> Please let us know what you think either by adding comments to the document or directly in this thread.<br>
> Eager to hear your thoughts!<br>
> <br>
> -- <br>
> Regards,<br>
> Ilya Biryukov<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>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Regards,</div><div>Ilya Biryukov</div></div></div></div></div></div>