[cfe-commits] r117271 - in /cfe/trunk: lib/Sema/SemaDeclObjC.cpp test/SemaObjC/class-conforming-protocol-2.m test/SemaObjC/method-conflict-1.m test/SemaObjC/method-typecheck-3.m

[John McCall]

On Oct 25, 2010, at 2:58 PM, David Chisnall wrote:
> On 25 Oct 2010, at 22:49, John McCall wrote:
>> The issue with sends to 'id' that I was thinking about is that there's an extremely loose sort of type-checking applied to them:  if the given selector has only one known signature, the call follows that.  My worry is that this can introduce multiple signatures and thus foil type-checking, whereas clearly the right behavior is to use the most general known signature.
> 
> That is possibly the correct behaviour when the types are object types - although it's not always clear cut there.  What happens if you have a method that takes an NSString and an NSArray and a method that takes an NSArray and an NSString?  Neither is a generalisation of the other.  It's also not possible for non-object types, and with the Apple runtimes you will get stack corruption if you guess the wrong C types in code generation, so it should really be a hard error in these cases (although without whole-program analysis, including private classes in all linked frameworks and processes connected via DO, you can't actually guarantee this at compile time).

Yeah, clearly we should only eliminate a signature from consideration when it's a strict subtype of another by the new matching rules.  We'd still want errors on any other kind of ambiguity.

> The GNUstep runtime now uses type information in the dispatch, which helps eliminate this kind of problem at run time (we can throw an exception, but with LanguageKit we can also generate a stub method at run time that fixes up the types with the correct boxing / unboxing).
> 
>>> I'm not sure that there are any future directions - I'm just making the warning a bit tighter in its checking.
>> 
>> There are some internal discussions in flight about ways to avoid 'id' in certain extremely common cases.
> 
> I'd be interested if this discussion could be made public...

I can't really promise anything there, sorry.

>>>> Anyway, we'll talk it over with the Apple runtime people;  I think we can make a pretty compelling case.
>>> 
>>> It shouldn't matter to them - it doesn't affect code generation, or even which programs are accepted, it just makes some programs compile without warnings that had spurious warnings before.
>> 
>> I should clarify that the runtime team here also guides the design of the language.
>> 
>> We have an internal deadline coming up, and it seems that we'd prefer not to make this change for it, so I'm going to introduce a specialized warning for covariant/contravariant overrides which will need to be enabled on Darwin.  Whether it's on by default and you have to specifically disable it or it's off by default and Darwin triples specifically enable it is something I'm still ambivalent about.
> 
> Fair enough.

John.