<div dir="ltr">I'm not sure how to do what you need - but is it the right thing to do?<br><br>It would seem problematic to visit template instantiations for a warning about sturct layout - you could end up giving two contradictory warnings in two different instantiations? (or otherwise oscillate - one instantiation with a large type & suggests moving it to the beginning, another with a small type which suggests moving it to the middle, etc)<div><br>It seems to me that working on the template pattern (so you can account for the ambiguity of dependent-ly typed members) would be the safer diagnostic, no?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 2, 2015 at 11:11 AM, Ben Craig via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal">My eventual question:<u></u><u></u></p><p class="MsoNormal">What is the best way for analysis AST visitors to visit template instantiations?<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Background:<u></u><u></u></p><p class="MsoNormal">I am working on a checker that will report about excessive padding. Basically, any place where padding could be reduced by reordering data members, I want to emit a report. This is different from –Wpadding because I don’t want to report on items where there isn’t a relatively easy fix.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">The general way I’m implementing this is by using the check::ASTDecl<RecordDecl> visitor, returning early for some really troublesome cases, then using getASTRecordLayout. I then compare the actual size and padding against a computed optimal padding and size, and report when the observed padding doesn’t meet the optimal padding.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I started writing tests for this, and started to run into problems with C++ templates. Here is the most troublesome code test case I’ve hit so far:<u></u><u></u></p><p class="MsoNormal">template <typename T><u></u><u></u></p><p class="MsoNormal">struct Foo {<u></u><u></u></p><p class="MsoNormal"> // expected-warning@+1{{Excessive padding in struct 'Foo<int>::Nested'}}<u></u><u></u></p><p class="MsoNormal"> struct Nested { // doesn’t actually warn though…<u></u><u></u></p><p class="MsoNormal"> char c1;<u></u><u></u></p><p class="MsoNormal"> T t;<u></u><u></u></p><p class="MsoNormal"> char c2;<u></u><u></u></p><p class="MsoNormal"> };<u></u><u></u></p><p class="MsoNormal">};<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">struct Holder { //no-warning<u></u><u></u></p><p class="MsoNormal"> Foo<int>::Nested t1;<u></u><u></u></p><p class="MsoNormal"> Foo<char>::Nested t2;<u></u><u></u></p><p class="MsoNormal">};<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">It seems that by default, AnalysisConsumer doesn’t visit template instantiations. In fact, if I add “bool shouldVisitTemplateInstantiations() const { return true; }” to the AnalysisConsumer class, I get the reports I expect. Is there a better way for me to accomplish my goal? I don’t like the idea of turning on instantiation visitation for every checker just because my checker needs it.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Before I found AnalysisConsumer, I did make an attempt to walk the instantiations by visiting ClassTemplateDecl and iterating over specializations. That works ok if I don’t have nested Records, like I posted above. I hadn’t found the “right” way to recurse into the structure before finding shouldVisitTemplateInsantiations. Maybe a “better” approach is to basically copy RecursiveASTVisitor::TraverseClassInstantiation? I’m not sure if I’m comfortable duplicating that code, but if it’s the better option then I will.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Thanks for the help,<u></u><u></u></p><p class="MsoNormal">Ben Craig<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">Employee of Qualcomm Innovation Center, Inc.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p></div></div><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>