<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 4, 2015 at 4:17 PM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><br><blockquote type="cite">On Feb 4, 2015, at 3:53 PM, Frédéric Riss <<a href="mailto:friss@apple.com" target="_blank">friss@apple.com</a>> wrote:<br><br><br><blockquote type="cite">On Feb 4, 2015, at 3:46 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>> wrote:<br><br><br><blockquote type="cite">On 2015-Feb-04, at 15:37, Frédéric Riss <<a href="mailto:friss@apple.com" target="_blank">friss@apple.com</a>> wrote:<br><br><blockquote type="cite"><blockquote type="cite"><br>- The word 'context' is overloaded: `MDNode::getContext()` already<br>exists, and returns an `LLVMContext&`; `DIDescriptor` uses 'context'<br>to mean "the node that this one is defined inside".  I chose the<br>word 'parent' instead of 'context' here.  Is this word okay?  If<br>not, what about 'scope'?  This will be reflected in the assembly<br>changes to come (I'd like the C++ names to match the assembly names,<br>although technically it's not necessary).<br><br>I'd /probably/ go with scope (we already have scope in the MDLocations, so that seems consistent), but fairly on-the-fence.<br><br></blockquote><br>Weirdly, I didn't even notice that :).  In that case I like 'scope'<br>better too.  I'll update to that before commit.<br></blockquote><br>Seems most natural. Can the futur getScope() return something that doesn’t derive from MDScope?<br></blockquote><br>I don't think so.<br></blockquote><br>That was my impression also, and it makes it even more appropriate IMHO.<br><br></blockquote><div><br></div></div></div><div>Just a few general remarks to throw into the discussion:</div><div><br></div><div>- Would it make sense to use something like tablegen to generate the repetitive parts? I’m slightly worried about copy&paste bugs, moderately worried about refactoring it in the future.</div><div><br></div><img border="0" usemap="#14b571924a68cff5_llvm_1_1DIScope_inherit__map" alt="Inheritance graph" height="254" width="751" src="cid:BB5B6097-6C55-43B2-AF9F-44384A8B1BE6@apple.com"><br><div><br></div><div>As for scopes, there are several things that bug me about the current class hierarchy that we could fix now:</div><div>- DIFile should not be a scope (the concept of files is IMO orthogonal to scoping and there is always something more appropriate to put a node into: compile unit, module, namespace)</div></div></blockquote><div><br>IIRC we do this when # line directives change the file-name part-way through. But I could be wrong... only vague idea.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>- DIBasicType should not be scope</div></div></blockquote><div><br>Part of this is the ability to treat all types the same - multiple inheritance might be an alternative, but without that we want to treat all types equally in some codepaths, but then only some types are valid scopes, etc. - so there's a few different axes on which we want to refer to these things. It's tricky. But certainly worth thinking about.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>- It’s questionable whether a DICompositetype should be a DIDerivedType</div><div>- A DISubroutineType should be neither a DIDerivedType nor DIScope</div><div>- Using DIDerivedTypes for CV qualifiers is a bit wasteful but it does map nicely to DWARF</div><div><br></div><div>otherwise, thanks for doing this!</div><span class="HOEnZb"><font color="#888888"><div>-- adrian</div></font></span></div></blockquote></div><br></div></div>