[cfe-commits] r132868 - in /cfe/trunk: docs/ include/clang/AST/ include/clang/Basic/ include/clang/Driver/ include/clang/Sema/ lib/AST/ lib/Analysis/ lib/Basic/ lib/CodeGen/ lib/Driver/ lib/Frontend/ lib/Parse/ lib/Sema/ lib/Serialization/ test/D

Douglas Gregor dgregor at apple.com
Mon Jun 13 15:35:17 PDT 2011


On Jun 13, 2011, at 12:42 PM, Eli Friedman wrote:

> On Mon, Jun 13, 2011 at 12:00 PM, Douglas Gregor <dgregor at apple.com> wrote:
>> 
>> On Jun 11, 2011, at 6:53 PM, Eli Friedman wrote:
>> 
>>> On Fri, Jun 10, 2011 at 6:09 PM, Douglas Gregor <dgregor at apple.com> wrote:
>>>> Author: dgregor
>>>> Date: Fri Jun 10 20:09:30 2011
>>>> New Revision: 132868
>>>> 
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=132868&view=rev
>>>> Log:
>>>> Implement Objective-C Related Result Type semantics.
>>>> 
>>>> Related result types apply Cocoa conventions to the type of message
>>>> sends and property accesses to Objective-C methods that are known to
>>>> always return objects whose type is the same as the type of the
>>>> receiving class (or a subclass thereof), such as +alloc and
>>>> -init. This tightens up static type safety for Objective-C, so that we
>>>> now diagnose mistakes like this:
>>>> 
>>>> t.m:4:10: warning: incompatible pointer types initializing 'NSSet *'
>>>> with an
>>>>      expression of type 'NSArray *' [-Wincompatible-pointer-types]
>>>>  NSSet *array = [[NSArray alloc] init];
>>>>         ^       ~~~~~~~~~~~~~~~~~~~~~~
>>>> /System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:72:1:
>>>> note:
>>>>      instance method 'init' is assumed to return an instance of its
>>>>      receiver
>>>>      type ('NSArray *')
>>>> - (id)init;
>>>> ^
>>>> 
>>>> It also means that we get decent type inference when writing code in
>>>> Objective-C++0x:
>>>> 
>>>>  auto array = [[NSMutableArray alloc] initWithObjects:@"one",  @"two",nil];
>>>>  //    ^ now infers NSMutableArray* rather than id
>>> 
>>> Would you mind taking a look at the failures on
>>> http://smooshlab.apple.com:8013/builders/gccTestSuite_clang-x86_64-darwin10-RA__obj-c
>>> and http://smooshlab.apple.com:8013/builders/gccTestSuite_clang-x86_64-darwin10-RA__obj-c++
>>> ?  I think this commit is the cause.
>> 
>> 
>> Yes, it was. I've fixed the test suite bugs in r132927.
> 
> Cool.
> 
> http://smooshlab.apple.com:8013/builders/gccTestSuite_clang-x86_64-darwin10-RA__c
> and http://smooshlab.apple.com:8013/builders/gccTestSuite_clang-x86_64-darwin10-RA__c++
> appear to be affected by a similar issue in
> block-weakblockassign.c/.C.

Should be fixed now, but we're waiting for the builder to reload expected results and such.

	- Doug



More information about the cfe-commits mailing list