<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 27, 2014 at 9:22 AM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 2014-Oct-24, at 16:37, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
>> Notice that only the links to parents (i.e., `context:`) are explicit<br>
>> here -- backlinks are implied.  For example, !7 and !8 point to !6, but<br>
>> not the reverse.<br>
><br>
> This may be a problem - the difference between nodes in a structure/class_type's member list, and those that are not in the member list but refer to the class/structure as their parent is meaningful. Type units use this distinction to avoid emitting instantiation-specific data into the canonical type unit (nested classes, implicit special members, member template instantiations, etc).<br>
><br>
> Not sure what the right answer will be there.<br>
<br>
</span>Interesting.  Could we model that with a Boolean flag on the child?<br></blockquote><div><br></div><div>That would be an option.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also, would there be value in modelling type units more explicitly in<br>
the IR?<br></blockquote><div><br>I don't see any particular value there, given the type uniquing work that's already been done, etc.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Presumably when dumping the fields will come in a specific, defined order? (probably not preserving the original source order, etc) Variation there would probably make checking harder than it needs to be.<br>
<br>
</span>Right.<br>
<span class=""><br>
><br>
> Would it be possible to omit the names of unreferenced nested metadata? (if you have a bunch of member functions in a class, but don't need to refer to them elsewhere (eg: those member functions aren't defined in this translation unit)) - that'd help readability/writeability, but probably wouldn't impact FileCheck.<br>
<br>
</span>Certainly possible, but is it generally desirable?</blockquote><div><br></div><div>I would imagine so - is there any reason the names/numbers would be preferable?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  I guess we'll<br>
sort that out when I get there.<br></blockquote><div><br></div><div>Sure enough.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
><br>
> Also the whole "metadata " prefix on anything is a bit verbose, if we can omit that in some/many places, that'll help reduce the visual noise/improve readability/writeability.<br>
><br>
> But most/all of that I imagine is fairly easily incremental change/improvement, nothing fundamental that needs to be chosen up-front.<br>
<br>
</div></div></blockquote></div><br></div></div>