[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/Driver/ test/PCH/ test/SemaObjC/ test/SemaObjCXX/

[Douglas Gregor]

On Jun 12, 2011, at 11:29 AM, Chris Lattner wrote:

> 
> On Jun 10, 2011, at 6:09 PM, Douglas Gregor 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.
> 
> Nice, thanks for landing this Doug.
> 
> Some random comments:
> 
> 1. Should this have a __has_feature check?
> 
> 2. Should the dox in the manual mention -f[no-]objc-infer-related-result-type?

IMO, "no" to both… this is meant to be an evolutionary step for the language, and the flags are really just there in case we run into trouble and need to back off on these changes. We've not yet seen any need for these flags, and they may go away in the future if we continue to see no need for them.

Plus, it's not really a "feature" per se but a change in semantics.

> 3. Please add a doxygen comment to CheckObjCMethodOverrides

Sure, r132917.

> 4. Why add the RelatedResultType bit to ObjCMethodDecl?  Isn't it always determinable from the selector?


Not always. We also check for type compatibility between the explicitly-specified result type and the type associated with the context of the method (e.g., the class if it's in an interface/category/class extension/implementation/category implementation). It's a bit more work than I'd like to do in the AST itself.

	- Doug