Unavailable method checker

[Richard]

On 29 Oct 2013, at 17:11, Jordan Rose <jordan_rose at apple.com> wrote:

> The logic all seems correct here, but I think we can still do better on the message. The class and protocol cases seem a little underinformative to me, especially since the analyzer doesn't have a note where the availability shows up. So instead of a version kind, how about just passing the decl that has the availability attribute? That way we can say "method", "function", "class 'Foo'", or "protocol 'Foo'".
> 
> Also, it would be nice to include the platform name with the version. This code is stolen from DeclBase.cpp, but I don't have a better place for it right now.
> 
>   StringRef TargetPlatform = Context.getTargetInfo().getPlatformName();
>   StringRef PrettyPlatformName
>     = AvailabilityAttr::getPrettyPlatformName(TargetPlatform);
>   if (PrettyPlatformName.empty())
>     PrettyPlatformName = TargetPlatform;
> 
> "Calling method introduced in OS X 10.9 (deployment target is 10.8)"
> 
> But other than this polish this is looking very good. Have you tried running it on existing projects?
> Jordan

OK, I have changed the message as suggested, works for you?

I have been running this on some small projects, but today gave it a test on all the large old projects I have here. Mostly it is working well (and caught many unsafe calls I was not aware of), but there were some issues which I have addressed in the latest patch:

* id types cause false positives
When calling methods on id types (in block enumerations and so on) the method decl match is often incorrect, and so the version check information often causes false positives. I fixed this by not checking any ObjCMethodCall without a receiver interface.

* Array and Dictionary subscripting
When using subscripting in a project with a deployment target less than iOS6 (or 10.8?), every subscript will cause a version warning. However, as stated here:

https://developer.apple.com/library/ios/releasenotes/ObjectiveC/ObjCAvailabilityIndex/index.html

subscripting is handled back to iOS5 and 10.6. I am not sure of the best way to handle this, the current workaround was just to match the selectors by name and not version check when we have a subscript selector. Ideally the checker would make sure that the deployment target was high enough for the runtime to support subscripting, is there a way to get this information from some API?

* Methods that call [super sameMethod]
I had a few false positives where implementing eg

- (void)encodeRestorableStateWithCoder:(NSCoder *)coder
{
    [super encodeRestorableStateWithCoder:coder];
}

Currently I have left these as false positives, but perhaps there should be special casing to handle this situation too. What do you think about this, is it safe to ignore methods called on super that have been implemented on self, regardless of deployment target? 

Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131031/b82aa118/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unavailable-3110.patch
Type: application/octet-stream
Size: 21112 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131031/b82aa118/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131031/b82aa118/attachment-0001.html>