[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/

John McCall rjmccall at apple.com
Mon Nov 7 20:24:50 PST 2011


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20111107/80cef5c9/attachment.html>


More information about the cfe-commits mailing list