<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Few comments; please see below.<div><br><div><div>On May 19, 2009, at 10:04 AM, steve naroff wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Motivation: Simplify clang's representation of ObjC Type's.</div><div><br></div><div>Quick review: clang's Objective-C support currently implements 4 distinct ways to refer to instances - they are:</div><div><br></div><div>(1) "id": No static type information (essentially an object-oriented "void *"). </div><div>(2) "<i>Interface</i> *": Refers to an instance of type <i>Interface</i>.</div><div>(3) "id <p1, p2>": Refers to any instance that adopts the 'p1 & p2' protocols.</div><div>(4) "<i>Interface</i> <p1, p2> *": Refers to an instance of type <i>Interface</i> that adopts the 'p1 & p2' protocols.</div><div><br></div><div>Some brief historical notes relevant to this discussion:</div><div><br></div><div>(1) The original implementation of ObjC only supported "id" (which was implemented by a C typedef in "objc.h").</div><div>(2) Interface-based typing was later added. Unlike "id" (where the pointer was implicit), interface-based typing still involves an explicit C pointer declaration. This is because we didn't want to close the door on supporting value-based objects (circa 1988). After 20 years, we've never seriously considered adding value objects to ObjC (since they don't support our release-to-release binary compatibility goals). In hindsight, it's too bad interface-based typing didn't have an implicit pointer (like Java). Oh well.</div><div>(3) Protocol-based typing was later added to both (1) and (2).</div><div>(4) Lastly, GCC supports "Class <p1, p2>". Chris and I decided to defer supporting this until we simplified the ObjC types under discussion.</div><div><br></div><div>This very brief history lesson might help explain the current set of ObjC type AST's. For example:</div><div><br></div><div>(1) We have no ObjC Type AST for "id" (it is currently a magic TypedefType AST installed by Sema and accessed through ASTContext).</div><div>(2) We have ObjCInterfaceType, which unlike "id", doesn't imply a pointer.</div><div>(3) Lastly, we have an ObjCQualifiedIdType (with no relation to the magic typedef) and ObjCQualifiedInterfaceType (which is related to ObjCInterfaceType).</div><div><br></div><div>So, reasoning about ObjC object pointer types involves knowing about all the subtle historical differences noted above. ASTContext::isObjCObjectPointerType() helps mask some of the complexity, however there are many other places in clang where the differences are explicit/cumbersome. To help simplify things, I'd like to consider moving to the following single AST that would represent all ObjC object pointer types. Here is some pseudo code:</div><div><br></div><div>class <b>ObjCObjectPointerType</b> : public Type, public llvm::FoldingSetNode {</div><div><br></div><div> // We could used the lower order bits to encode id/Class (which are built-in, not user-defined).</div><div> // Alternatively, we could synthesize built-in ObjCInterfaceDecl's that correspond to id/Class.</div><div> ObjCInterfaceDecl *Decl;</div><div><br></div><div><div> // List of protocols, sorted on protocol name. No protocol is entered more than once.</div><div> llvm::SmallVector<ObjCProtocolDecl*, 8> Protocols;</div><div><br></div></div><div><div>public:</div><div> bool isObjCIdType();</div></div></div></blockquote><div><br class="webkit-block-placeholder"></div>Is there going to be isObjCClassType() in the future?</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div> bool isObjCInterfaceType();</div></div></div></blockquote>This name is confusing to me. Since this AST is for pointers only, shouldn't it be named something like isObjCInterfacePointerType()?</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div> bool isObjCQualifiedIdType();</div><div> bool isObjCQualifiedInterfaceType();</div></div></div></blockquote>Same as my last question.</div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div> ...</div><div>};</div><div><br></div><div>The following classes would be deprecated: ObjCQualifiedIdType, ObjCQualifiedInterfaceType. ObjCInterfaceType will still exist, however it's usage will be minimal (since you can't declare a variable/field of ObjCInterfaceType). You can, however specify an ObjCInterfaceType as an argument to @encode(<i>Interface</i>).</div></div></div></blockquote><div><br class="webkit-block-placeholder"></div>You are keeping ObjCInterfaceType for stand-alone interface (and presumably a variation for qualified interface type). </div><div>If so, then it is not clear to me how you do a type conversion from <span class="Apple-style-span" style="font-weight: bold; ">ObjCObjectPointerType to </span>ObjCInterfaceType when user asks for it.</div><div>I know that it is rare, but it can happen as in the following test case:</div><div><br class="webkit-block-placeholder"></div><div><div>@interface I @end</div><div>I *pi;</div><div>int main()</div><div>{</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>return sizeof (*pi);</div><div>}</div><div><br class="webkit-block-placeholder"></div><div>I guess a more general question is does a pointer to ObjCInterfaceType conforms to <b>ObjCObjectPointerType? </b></div><div><b>- Fariborz</b></div><div><b><br class="webkit-block-placeholder"></b></div><div><br class="webkit-block-placeholder"></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><br></div></div><div><div>Note that the implicit pointer is a little odd (since it doesn't directly reflect what the user typed). For example, the type for "<i>Interface</i> *" will contain 0 pointer types and the type for "<span class="Apple-style-span" style="font-style: italic; ">Interface</span> **" will contain 1 pointer type. While this may seem odd, it is more useful and reflects the common idiom. The fact that the common idiom doesn't reflect the language syntax is more of an historical artifact (as mentioned above).</div><div><br></div><div>Since a lot of code depends on the ObjC type classes, I wanted to get some feedback before I start tearing things up:-) The actual conversion will be done in several phases (assuming everyone likes the general direction).</div><div><br></div><div>Thanks in advance for any feedback!</div><div><br></div><div>snaroff</div></div></div>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></blockquote></div><br></div></body></html>