<div dir="ltr"><div>Hey!</div><div><br></div><div>There's an existing infrastructure called "AST matchers" already available through Clang: <a href="http://clang.llvm.org/docs/LibASTMatchersReference.html">http://clang.llvm.org/docs/LibASTMatchersReference.html</a></div><div>As a gentle introduction, you could look at Tidy checks which *mainly* (but not exclusively) use these matchers to find constructs.</div><div><br></div><div>Custom tools can be created with the libTooling framework, if you want a binary with your own entry point.</div><div><br></div><div>When the AST matcher matches, you have the matched AST Node (which have an *extensive* hierarchy and lots and lots of query functions you can do on them!) in your hand in the match handler.</div><div><br></div><div>If you can sketch the problem where the match set is small, you would be better off matching this small set of nodes, and then walking back (you can query the context (namespace, record) of a method, from that you can go to the parent context, for records query their bases, etcc.).</div><div><br></div><div>Problem is that executing all these requires a semantically correct source file, otherwise there will be no (sensible) AST on which the matchers can run.</div><div><br></div><div>This means that if I have version A which works and version B which is broken in the build, the check(s) will also be broken.</div><div>If your checks would only run on the dependencies, you're safe.</div><div><br></div><div>As for the dependencies, to automatically invoke the analysis properly, Clang uses the "JSON Compilation Database" format. You need these "build logs" (build command for the dependency projects!, and potentially an executed build in some cases - e.g. if the project depends on build-generated files) so Clang knows with what flags to run the analysis with.</div><div>If you have your own libTooling project (your own binary you call, not clang-tidy), you can have a command-line argument that gets parsed as a compilation database.<br> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Madhura Ganesh via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> ezt írta (időpont: 2020. márc. 21., Szo, 8:58):<br></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>Hi All,</div><div><br></div><div>I am trying to solve a build contract problem where frequently my dependencies break the contract and my product fails to build.</div><div>To prevent this, i wanted to give a contract to my dependencies saying that hey you should not break these methods. Now, you may ask why not simply ask your dependencies to build my package and check, but it takes a long time to build my package, and hence wanted an easy check.</div><div><br></div><div>Let's suppose I establish a contract like this,</div><div><br></div><div>int Calculator::add(int, int) is an agreement and my dependency will should not change it,</div><div>if he changes this to say,</div><div>int Calculator::add(int, int), then my build contract test should fail.</div><div><br></div><div>To do that, I should parse the AST of both the packages and extract all the defined and used methods. Once, i have them i can check whether all the methods that i have used has a definition in the dependency AST or not.</div><div><br></div><div>Do we have a tooling already on this? wanted to know the right library to use on this as if i had to write this AST comparison from scratch, I should handle inheritance, typedefines and all of such cases.</div><div><br></div><div>Not sure if ast matcher would be right here, because I should understand the ast of consumer and create an ast matcher query from the used method and check if it exists in the producer which is round about, than doing a direct check on the method signatures as per the ast of producer and consumer.</div><div><br></div><div>Thanks in advance for your help!</div><div><br></div><div>Thanks,<br></div><div>Madhura Ganesh<br></div></div>
_______________________________________________<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>