<div dir="ltr"><div dir="ltr">On Sat, Jan 18, 2020 at 4:09 PM Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.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">FWIW, I think the proposed solution is a valuable goal.</blockquote><div><br></div><div>Goals should not be specified in terms of solutions, because given such framing, alternatives can't be considered. XY problem etc.</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">> Clang codebase does not have many matchers that are combinations of existing matchers, but code that uses Clang as a library (and often written by engineers who are not compiler experts and just need to get some refactoring done) does that very often in my experience working at Google.<br>
<br>
clang-tidy uses a fair amount of matchers that are combinations of<br>
existing matchers, but they're localized to the individual checks.</blockquote><div><br></div><div>Like I said, that is the case in the Clang codebase. However, my experience working at Google is different -- most often people compose existing matchers instead of defining new ones using AST_MATCHER.</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">> Syntax trees will be used in ClangTidy once they are more fleshed out.<br>
<br>
Is this a hope, or was this a decision made already?<br></blockquote><div><br></div><div>It is a direction towards which we are building libraries like Stencil, Transformer, Syntax trees. We can't say that we made a decision to use them in ClangTidy, because obviously not all of the infrastructure is there, so we can't evaluate it and make a justified decision. However, we are building these libraries hoping that they will make common refactoring and linting tooling (like ClangTidy) more accessible for novices, and easier to implement even for experts. If we didn't think that could be the case, we would not be building these libraries.</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">> It instantly creates a huge testing gap for existing AST matchers (which we currently test only in one mode). It also creates traps for existing code that will be able to start accidentally calling existing matchers in a traversal mode that they were not designed for.<br>
<br>
I think the testing gap can be solved with software solutions<br>
(judicious use of macros and/or templates). The traps for existing<br>
code are a bit of a concern, but truthfully, no more of a concern than<br>
use of StringRef is.</blockquote><div><br></div><div>It is very different: to catch misuses of StringRef, we already have ASan.</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">If the composed matcher is publicly exposed, it's<br>
something the author definitely has to account for. If the composed<br>
matcher is private to a particular check or other usage (which is the<br>
majority case as best I can tell),</blockquote><div><br></div><div>Correction: the majority case in llvm-project.git.</div></div><div><br></div><div>Dmitri</div><div><br></div>-- <br><div dir="ltr">main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br>(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>>*/</div></div>