<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Nov 7, 2011, at 7:14 PM, Ted Kremenek wrote:</div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Nov 6, 2011, at 1:01 AM, John McCall wrote:</div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-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: 0px; font-size: medium; ">--- cfe/trunk/test/Analysis/casts.m (original)<br>+++ cfe/trunk/test/Analysis/casts.m Sun Nov 6 03:01:30 2011<br>@@ -33,9 +33,10 @@<br> RDR10087620Enum elem;<br>}<br>@property (readwrite, nonatomic) RDR10087620Enum elem;<br>+@end<br>+<br>static void<br>adium_media_ready_cb(RDR10087620 *InObj)<br>{<br> InObj.elem |= EEOne;<br>}<br>-@end<br>\ No newline at end of file</span></blockquote></div><br><div>Why was this test modified?</div></div></blockquote></div><br><div>It was (as far as I could tell) inadvertently testing the ability to do</div><div>property accesses in code within an @interface declaration.</div><div>The bug referenced is just about enum promotions interfering</div><div>with analysis.</div><div><br></div><div>This was a problem for my refactor because it is otherwise</div><div>not possible to fail to find appropriate method declarations</div><div>for an access to an explicit property.</div><div><br></div><div>My assumption was that Clang does not intentionally support</div><div>this language "feature"; note that GCC doesn't even correctly</div><div>parse it. Unlike code in @implementations, it's completely</div><div>useless, because the code can always be sunk after the</div><div>interface (unless you've got some crazy typeof(foo()) there,</div><div>but that seems to serve no purpose).</div><div><br></div><div>There are also pretty severe language-design problems with</div><div>the entire idea, starting with analogies to the problems that</div><div>mandate two-pass parsing of class definitions in C++: the class</div><div>might later provide explicit declarations of the getter or setter,</div><div>and our initial type-checking will be incorrect or at least outdated.</div><div><br></div><div>We should probably explicitly error instead of accepting it with</div><div>possibly-unexpected behavior, though.</div><div><br></div><div>John.</div></body></html>