<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 17, 2008, at 1:09 PM, steve naroff wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div><blockquote type="cite"><div>Another example would be a client that wanted to rename 'x'.  How would it know all of the declarations for the same variable?  There are lots of cases where clients, looking the AST for a translation unit, want to know which declarations refer to the same thing.<br></div></blockquote></div><br><div>Absolutely. Building a cross reference map of some kind is easy to do. For example, Sema has the following maps that track *all* declarations for a given method (within a particular translation unit):</div><div><br></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 10px/normal Monaco; color: rgb(0, 116, 0); "><span style="color: rgb(0, 0, 0); ">  </span>/// Instance/Factory Method Pools - allows efficient lookup when typechecking</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 10px/normal Monaco; color: rgb(0, 116, 0); "><span style="color: rgb(0, 0, 0); "> <span class="Apple-converted-space"> </span></span>/// messages to "id". We need to maintain a list, since selectors can have</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 10px/normal Monaco; color: rgb(0, 116, 0); "><span style="color: rgb(0, 0, 0); "> <span class="Apple-converted-space"> </span></span>/// differing signatures across classes. In Cocoa, this happens to be </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 10px/normal Monaco; color: rgb(0, 116, 0); "><span style="color: rgb(0, 0, 0); "> <span class="Apple-converted-space"> </span></span>/// extremely uncommon (only 1% of selectors are "overloaded").</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 10px/normal Monaco; color: rgb(63, 110, 116); "><span style="color: rgb(0, 0, 0); "> <span class="Apple-converted-space"> </span></span>llvm<span style="color: rgb(0, 0, 0); ">::</span><span style="color: rgb(92, 38, 153); ">DenseMap</span><span style="color: rgb(0, 0, 0); "><</span>Selector<span style="color: rgb(0, 0, 0); ">,<span class="Apple-converted-space"> </span></span><span style="color: rgb(38, 71, 75); ">ObjCMethodList</span><span style="color: rgb(0, 0, 0); ">><span class="Apple-converted-space"> </span></span>InstanceMethodPool<span style="color: rgb(0, 0, 0); ">;</span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 10px/normal Monaco; color: rgb(63, 110, 116); "><span style="color: rgb(0, 0, 0); "> <span class="Apple-converted-space"> </span></span>llvm<span style="color: rgb(0, 0, 0); ">::</span><span style="color: rgb(92, 38, 153); ">DenseMap</span><span style="color: rgb(0, 0, 0); "><</span>Selector<span style="color: rgb(0, 0, 0); ">,<span class="Apple-converted-space"> </span></span><span style="color: rgb(38, 71, 75); ">ObjCMethodList</span><span style="color: rgb(0, 0, 0); ">><span class="Apple-converted-space"> </span></span>FactoryMethodPool<span style="color: rgb(0, 0, 0); ">;</span></div><div><font class="Apple-style-span" face="Monaco" size="2"><span class="Apple-style-span" style="font-size: 10px; "><br></span></font></div><div>If maps like this are of general interest, we might consider adding API to Sema to extract some of the knowledge prior to its death? As an alternative, we could also post-process the AST's and build whatever maps are needed. My gut says it will be a combination.</div></div></span></blockquote><div><br></div><div>It seems to me that Sema is already building much of this information and then just throwing it away.  If we refactor those data structures to be outside of Sema, Sema could populate them for its own use and any client that wishes to retain them afterwards could do so.  I agree that it will probably end up requiring a combination of extracting information from Sema and then (lazily) doing some post-processing.</div><div><br></div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div><div><span class="Apple-style-span" style="color: rgb(20, 79, 174); -webkit-text-stroke-width: -1; ">I think the point we are in violent agreement about is the need for "AST middleware" that sits between various clang AST clients and Sema. Some of this middleware may come directly from Sema (with a bit of refactoring).</span></div></div></span></blockquote><br></div><div>Exactly my feeling as well.</div><br><div><br></div></body></html>