[cfe-commits] r143867 - in /cfe/trunk: include/clang/AST/ include/clang/Basic/ include/clang/Serialization/ lib/ARCMigrate/ lib/AST/ lib/Analysis/ lib/CodeGen/ lib/Rewrite/ lib/Sema/ lib/Serialization/ lib/StaticAnalyzer/Core/ test/Analysis/ tools/libclang/

[jahanian]

There are numerous code which declare c-style methods inside the interface. Interface scope is just ignored.
We should maintain this behavior. When I did the DeclContext work, I want through extra work not to change this.

- Fariborz

On Nov 7, 2011, at 8:24 PM, John McCall wrote:

> On Nov 7, 2011, at 7:14 PM, Ted Kremenek wrote:
>> On Nov 6, 2011, at 1:01 AM, John McCall wrote:
>>> --- cfe/trunk/test/Analysis/casts.m (original)
>>> +++ cfe/trunk/test/Analysis/casts.m Sun Nov  6 03:01:30 2011
>>> @@ -33,9 +33,10 @@
>>>   RDR10087620Enum   elem;
>>> }
>>> @property (readwrite, nonatomic) RDR10087620Enum elem;
>>> + at end
>>> +
>>> static void
>>> adium_media_ready_cb(RDR10087620 *InObj)
>>> {
>>>   InObj.elem |= EEOne;
>>> }
>>> - at end
>>> \ No newline at end of file
>> 
>> Why was this test modified?
> 
> It was (as far as I could tell) inadvertently testing the ability to do
> property accesses in code within an @interface declaration.
> The bug referenced is just about enum promotions interfering
> with analysis.
> 
> This was a problem for my refactor because it is otherwise
> not possible to fail to find appropriate method declarations
> for an access to an explicit property.
> 
> My assumption was that Clang does not intentionally support
> this language "feature";  note that GCC doesn't even correctly
> parse it.  Unlike code in @implementations, it's completely
> useless, because the code can always be sunk after the
> interface (unless you've got some crazy typeof(foo()) there,
> but that seems to serve no purpose).
> 
> There are also pretty severe language-design problems with
> the entire idea, starting with analogies to the problems that
> mandate two-pass parsing of class definitions in C++:  the class
> might later provide explicit declarations of the getter or setter,
> and our initial type-checking will be incorrect or at least outdated.
> 
> We should probably explicitly error instead of accepting it with
> possibly-unexpected behavior, though.
> 
> John.
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20111108/9b130988/attachment.html>