Hi all,
With clang version 3.1 (trunk 146375) the code below generates a false positive warning:
test.m:7:6: warning: 'terminate:' is deprecated [-Wdeprecated-declarations]
[NSApp terminate:nil];
^
As best as I can tell, that method is not deprecated. The global variable NSApp is declared as 'id'. If I cast it to NSApplication* the warning goes away. This warning did not occur a few weeks ago, nor does it with gcc.
Is it a bug or am I missing something?
This change was made intentionally in r145999. There are multiple
methods called terminate in Cocoa.h, and one of them (specifically,
the one on NSInputServiceProvider) is deprecated. It's possible the
heuristic and/or the headers need tweaks.
-Eli
Do you want me to file a bug?
I've never understood why the NSApp global is 'id' and not 'NSApplication*'. This has caused other warnings in the past, like <rdar://6845498>.
Cheers,
Hi all,
With clang version 3.1 (trunk 146375) the code below generates a false positive warning:
test.m:7:6: warning: 'terminate:' is deprecated [-Wdeprecated-declarations]
[NSApp terminate:nil];
^As best as I can tell, that method is not deprecated. The global variable NSApp is declared as 'id'. If I cast it to NSApplication* the warning goes away. This warning did not occur a few weeks ago, nor does it with gcc.
Is it a bug or am I missing something?
This change was made intentionally in r145999. There are multiple
methods called terminate in Cocoa.h, and one of them (specifically,
the one on NSInputServiceProvider) is deprecated. It's possible the
heuristic and/or the headers need tweaks.
That is correct. This was intentionally done on user request when receiver type is 'id' and there is at least one deprecated method
of the given name. Type-cast always removes the warning.
- Fariborz
Yeah, I don't think there's a better option right now. There are things we could
do if we had "bounded bottom" typing, e.g. something with the message-send
behavior of id but with a guaranteed minimum protocol. But we don't.
John.
This breaks the chromium build with the 10.6 sdk. So the recommended
fix is to explicitly typecast NSApp everywhere it's used?
Another solution is to not use the NSApp global (which is 'id'), but instead call [NSApplication sharedApplication] (which is 'NSApplication*').
I filed rdar://10566004 asking that NSApp be changed from 'id' to 'NSApplication*'.
This breaks the chromium build with the 10.6 sdk. So the recommended
fix is to explicitly typecast NSApp everywhere it's used?Another solution is to not use the NSApp global (which is 'id'), but instead call [NSApplication sharedApplication] (which is 'NSApplication*').
Or simply define a macro (or an inline function) that perform this cast.
I filed rdar://10566004 asking that NSApp be changed from 'id' to 'NSApplication*'.
Though it may look easy to fix, I would not rely on Apple to fix this soon. I'm waiting for more than 2 years that they add some missing availability macros in there SDKs (for instance, the whole ColorSync API introduced in 10.6). And this lack of 'weak' attribute is far more annoying as it causes crash at runtime and not simply a compiler warning.
-- Jean-Daniel
It doesn't just _look_ easy to fix, it surely is easy, no? 
Anyway, I thought you'd be amused to know that the bug has come back as a dupe of rdar://2745084, which, looking at my old bugs, puts it at around August 2001. Wow!
Mechanically easy, certainly, but it has implications. NSApp is not necessarily an instance of NSApplication; it can be an instance of a subclass specified in Info.plist. Changing its type would break an unknowable amount of existing, correct code. I assume radar 2745084 is marked Works Correctly for this reason.