<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 27/05/2020 15:24, Sam McCall wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+sYUsLAQ_d7BtFRr=pt_qunGDR4E8DkTsnOGzyBwWuKQ6rntw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Hi Stephen,</div>
<div><br>
</div>
<div>First off: I think we've mitigated this enough on our end
that we're not in immediate need of changes beyond fixing the
problems found in Transformers.</div>
<div>Thanks for being so engaged on this, it helped a lot
clarifying our options and I think we can help make this
smoother for adopters when this gets released.</div>
</div>
</blockquote>
<p><br>
</p>
<p>Great!<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CA+sYUsLAQ_d7BtFRr=pt_qunGDR4E8DkTsnOGzyBwWuKQ6rntw@mail.gmail.com">
<div dir="ltr">
<div>I've also had a chance to sync internally with Dmitri,
Haojian, Yitzhak and Manuel and get their perspectives too.</div>
<div><br>
</div>
<div>Some brief notes on our local fixes:</div>
<div>Haojian wrote a (matcher/transformer-based!) tool to
identify the "roots" where matchers were passed into consuming
clang APIs and mechanically wrapped them with traverse() at
that point.</div>
</div>
</blockquote>
<p><br>
</p>
<p>Sounds good. There's something MC-Escher-like pleasing about
that.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CA+sYUsLAQ_d7BtFRr=pt_qunGDR4E8DkTsnOGzyBwWuKQ6rntw@mail.gmail.com">
<div dir="ltr">
<div>This was applied across the codebase, whether needed to
make tests pass or not. We have no plans to systematically
remove AsIs from these - tool owners can do this (or not) as
part of maintenance.</div>
<div>We chose this approach because:</div>
<div> - there was preference for expressing this subtle
difference next to the matcher logic rather than "burying" it
in tool framework stuff. Otherwise there's little prospect of
ever using the new mode, and copy/pasting matchers would give
mysteriously different results.</div>
</div>
</blockquote>
<p><br>
</p>
<p>Yes, I listed the "burying" method as something small and quick
that would be quick to unblock others, but not a long-term
solution.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CA+sYUsLAQ_d7BtFRr=pt_qunGDR4E8DkTsnOGzyBwWuKQ6rntw@mail.gmail.com">
<div dir="ltr">
<div> - it was amenable to automated refactoring and thus
scaling (more-so than modifying tool entry points) because
there were a few identifiable points to instrument.</div>
<div> - applying it to everything meant not worrying about
whether tests were adequate</div>
<div> - updating all tools to use the new traversal mode
probably isn't a good use of time due to the long tail.</div>
<div><br>
</div>
<div>There were ~40 direct uses of ASTContext::getParents(),
whose behaviour was also changed, and these were significantly
more work to adapt. (Apparently. I wasn't the one doing the
work :-))</div>
<div>I suppose the trivial/safe fix is to set and restore the
mode before each call, but this seems pretty gross - this
doesn't seem like something that should require mutating
global state.</div>
</div>
</blockquote>
<p><br>
</p>
<p>Yes, I agree it has a bit of a smell. There is a <span style="font-size:11pt;font-family:'Courier New';color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;" id="docs-internal-guid-e63db8ba-7fff-436d-90eb-4f050da6c219">TraversalKindScope</span>
RAII type for use in a few checks as it was only needed in
`::check` implementations.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CA+sYUsLAQ_d7BtFRr=pt_qunGDR4E8DkTsnOGzyBwWuKQ6rntw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>How do you feel about making the old behaviour and the
traversal-mode-respecting version of this function both
reasonably available, with matchers calling the new one?</div>
<div>I don't have a strong opinion on naming/structure, but
would prefer existing getParents() calls to either get the
existing behaviour or a build break forcing a choice.</div>
</div>
</blockquote>
<p><br>
</p>
<p>That sounds fine to me.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CA+sYUsLAQ_d7BtFRr=pt_qunGDR4E8DkTsnOGzyBwWuKQ6rntw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>We had some discussion of the direction of the change
overall (I know it's late for this). Making matchers easier is
great. Some concern that you really have to know the AST to
use matchers effectively</div>
</div>
</blockquote>
<p>[Side note:<br>
</p>
<p>This is something of a side-note to this thread, but I don't
think you do need to be familiar with AST structure in order to
use AST Matchers. At least not in the future. <br>
</p>
<p>Consider</p>
<p> <a class="moz-txt-link-freetext" href="https://steveire.files.wordpress.com/2018/11/all-no-ast.png?w=900&h=590">https://steveire.files.wordpress.com/2018/11/all-no-ast.png?w=900&h=590</a><br>
</p>
<p>versus</p>
<p> <a class="moz-txt-link-freetext" href="https://steveire.files.wordpress.com/2018/11/allenabled.png?w=900&h=590">https://steveire.files.wordpress.com/2018/11/allenabled.png?w=900&h=590</a><br>
</p>
<p>The latter is what we have today. The former does not require
users to be familiar with the AST because clang-query can tell you
what matchers and source locations you can use with binding
results:<br>
</p>
<p> <a class="moz-txt-link-freetext" href="http://ce.steveire.com/z/Kbk8Yj">http://ce.steveire.com/z/Kbk8Yj</a></p>
<p>I demo'd these clang-query features in November 2018 but I
haven't been able to get the patches upstream and I haven't seen
interest or drive from the community in getting the patches
actually approved unfortunately. <br>
</p>
<p> <a class="moz-txt-link-freetext" href="https://steveire.wordpress.com/2019/01/02/refactor-with-clang-tooling-at-codedive-2018/">https://steveire.wordpress.com/2019/01/02/refactor-with-clang-tooling-at-codedive-2018/</a><br>
</p>
<p>If you have a declarative debugger for your matchers you don't
need to debug via an trip through the AST either:<br>
</p>
<p> <a class="moz-txt-link-freetext" href="http://ce.steveire.com/z/Miznm_">http://ce.steveire.com/z/Miznm_</a><br>
</p>
<p>I demo'd that one at EuroLLVM 2019 along with a Proof of Concept
Qt UI for this stuff:
<a class="moz-txt-link-freetext" href="https://steveire.wordpress.com/2019/04/30/the-future-of-ast-matching-refactoring-tools-eurollvm-and-accu/">https://steveire.wordpress.com/2019/04/30/the-future-of-ast-matching-refactoring-tools-eurollvm-and-accu/</a><br>
</p>
<p>It is definitely not necessary for novices to see an AST dump or
to be very familiar with it before starting. It might be the
current state in LLVM upstream, but it hasn't needed to be true
for almost 1.5 years, depending on how you see it :).</p>
<p>
</p>
<p>There is a huge amount more that we could do to improve
mechanical refactoring tools for novices and others. But I haven't
been able to drive that forward because I can't get my changes
reviewed upstream in a timeframe that reflects a drive from
upstream to get them in. That means I can't stay engaged and I
have to disappear for months. Better is possible :).<br>
</p>
<p>If you or someone you know have interest in any of this and have
drive to actually get them upstream (this is the critical part -
the desire to approve the patches) please let me know.</p>
<p>End Side Note]<br>
</p>
<blockquote type="cite"
cite="mid:CA+sYUsLAQ_d7BtFRr=pt_qunGDR4E8DkTsnOGzyBwWuKQ6rntw@mail.gmail.com">
<div dir="ltr">
<div>, and this might give the illusion you only need to know
syntax. But some pushback against this idea:
ignoreImplicit.... is a hassle even for experienced people.</div>
</div>
</blockquote>
<p>Yes.</p>
<p>Thanks,</p>
<p>Stephen<br>
</p>
</body>
</html>