<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><blockquote type="cite" class="">On Feb 4, 2015, at 3:53 PM, Frédéric Riss <<a href="mailto:friss@apple.com" class="">friss@apple.com</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Feb 4, 2015, at 3:46 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" class="">dexonsmith@apple.com</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On 2015-Feb-04, at 15:37, Frédéric Riss <<a href="mailto:friss@apple.com" class="">friss@apple.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">- The word 'context' is overloaded: `MDNode::getContext()` already<br class="">exists, and returns an `LLVMContext&`; `DIDescriptor` uses 'context'<br class="">to mean "the node that this one is defined inside". I chose the<br class="">word 'parent' instead of 'context' here. Is this word okay? If<br class="">not, what about 'scope'? This will be reflected in the assembly<br class="">changes to come (I'd like the C++ names to match the assembly names,<br class="">although technically it's not necessary).<br class=""><br class="">I'd /probably/ go with scope (we already have scope in the MDLocations, so that seems consistent), but fairly on-the-fence.<br class=""><br class=""></blockquote><br class="">Weirdly, I didn't even notice that :). In that case I like 'scope'<br class="">better too. I'll update to that before commit.<br class=""></blockquote><br class="">Seems most natural. Can the futur getScope() return something that doesn’t derive from MDScope?<br class=""></blockquote><br class="">I don't think so.<br class=""></blockquote><br class="">That was my impression also, and it makes it even more appropriate IMHO.<br class=""><br class=""></blockquote><div class=""><br class=""></div><div class="">Just a few general remarks to throw into the discussion:</div><div class=""><br class=""></div><div class="">- 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 class=""><br class=""></div><img border="0" usemap="#llvm_1_1DIScope_inherit__map" alt="Inheritance graph" apple-inline="yes" id="B3937DC9-5D99-4F56-B5AE-F24E32BCB95B" height="254" width="751" apple-width="yes" apple-height="yes" src="cid:BB5B6097-6C55-43B2-AF9F-44384A8B1BE6@apple.com" class=""><br class=""><div class=""><br class=""></div><div class="">As for scopes, there are several things that bug me about the current class hierarchy that we could fix now:</div><div class="">- 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 class="">- DIBasicType should not be scope</div><div class="">- It’s questionable whether a DICompositetype should be a DIDerivedType</div><div class="">- A DISubroutineType should be neither a DIDerivedType nor DIScope</div><div class="">- Using DIDerivedTypes for CV qualifiers is a bit wasteful but it does map nicely to DWARF</div><div class=""><br class=""></div><div class="">otherwise, thanks for doing this!</div><div class="">-- adrian</div></body></html>