<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 10, 2013, at 11:35 AM, John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 10, 2013, at 9:11 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 9, 2013, at 23:08 , John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Author: rjmccall<br>Date: Wed Apr 10 01:08:21 2013<br>New Revision: 179153<br><br>URL: <a href="http://llvm.org/viewvc/llvm-project?rev=179153&view=rev">http://llvm.org/viewvc/llvm-project?rev=179153&view=rev</a><br>Log:<br>Don't crash when mangling types defined in ObjC class extensions.<br><br>The original test case here was mangling a type name for TBAA,<br>but we can provoke this in C++11 easily enough.<br><br><a href="rdar://13434937">rdar://13434937</a><br><br>Modified:<br>    cfe/trunk/lib/AST/ItaniumMangle.cpp<br>    cfe/trunk/test/CodeGenObjCXX/mangle.mm<br><br>Modified: cfe/trunk/lib/AST/ItaniumMangle.cpp<br>URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ItaniumMangle.cpp?rev=179153&r1=179152&r2=179153&view=diff">http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ItaniumMangle.cpp?rev=179153&r1=179152&r2=179153&view=diff</a><br>==============================================================================<br>--- cfe/trunk/lib/AST/ItaniumMangle.cpp (original)<br>+++ cfe/trunk/lib/AST/ItaniumMangle.cpp Wed Apr 10 01:08:21 2013<br>@@ -1095,6 +1095,15 @@ void CXXNameMangler::mangleUnqualifiedNa<br>       mangleSourceName(FD->getIdentifier());<br>       break;<br>     }<br>+<br>+    // Class extensions have no name as a category, and it's possible<br>+    // for them to be the semantic parent of certain declarations<br>+    // (primarily, tag decls defined within declarations).  Such<br>+    // declarations will always have internal linkage, so the name<br>+    // doesn't really matter, but we shouldn't crash on them.  For<br>+    // safety, just handle all ObjC containers here.<br>+    if (isa<ObjCContainerDecl>(ND))<br>+      break;<br><br></blockquote><br></div><div>Is that true? If I do this awful thing:</div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">@interface SomeClass ()<div>@property struct Evil {</div><div><span class="Apple-tab-span" style="white-space:pre">     </span>int i;</div><div><span class="Apple-tab-span" style="white-space:pre">       </span>void print() const;</div><div>} myEvil;</div><div>@end</div></blockquote><div><br></div><div>then Evil gets internal linkage? (I guess that's an acceptable language rule, but I'm not sure where we would have stated that explicitly.)</div></div></blockquote><div><br></div><div>It does.  If we change our minds on this, then I think the right fix is to semantically parent 'struct Evil' to the surrounding context (which is always the global context) instead of the @interface.  (It can still be lexically parented to the @interface, of course.)</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Full test case (haven't rebuilt Clang yet, so I don't know what happens):</div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>@interface SomeClass</div><div>@end</div><div><br></div><div>@interface SomeClass ()</div><div>@property struct Evil {</div><div><div><span class="Apple-tab-span" style="white-space:pre">  </span></div>int i;</div><div><div><span class="Apple-tab-span" style="white-space:pre">        </span></div>void print() const;</div><div>} myEvil;</div><div>@end</div><div><br></div><div>@implementation SomeClass</div><div>@end</div><div><br></div><div>void Evil::print() const {}</div></blockquote></div></blockquote><div><br></div></div>I think that this works is fine.  The actually problematic thing is that you can also declare struct Evil outside of this, and we don't detect it as an invalid redeclaration.  That's probably not good.<div><br></div><div>A lot of stuff with non-ObjC declarations in ObjC containers is pretty problematic, really.<br></div></div></blockquote><div><br></div>C declarations inside ObjC containers does not provide any local context. It should't cause any unforeseen problem if we accept this</div><div>basic fact.</div><div><br></div><div>- Fariborz</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><br></div><div>John.</div></div></div>_______________________________________________<br>cfe-commits mailing list<br><a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits<br></blockquote></div><br></body></html>