[cfe-dev] warning if method availability is newer than minimum deployment target

[Ted Kremenek]

Hi Sebastian,

Richard has been doing some great work to try and wire up the necessary infrastructure to implement some (or all) of this warning in the static analyzer.  My own goal is to try and make this a compiler warning at some point in addition to a static analyzer warning, since it will get the highest visibility among users.  It's much tricker to do as a compiler warning, given the performance requirements of the compiler and the tricks we will need to do to get the necessary accuracy which we get for free with the static analyzer.  It's a back burner project for me right now, but there is definitely interest in pushing this forward.

Ted

On Jan 23, 2013, at 10:58 AM, Sebastian Hagedorn <hagi.dd at web.de> wrote:

> Hi Richard, Hi Ted,
> 
> I just found this post in the archive and was wondering if this was still on your (or anyone else's) radar? I absolutely agree with Richard in that I find it pretty inconvenient to find new APIs in projects with an older deployment target. If you use the Android SDK & tools, Lint will give you warnings for any APIs that are newer than your deployment target (it's called minimum SDK there...). If you use them deliberately and only under certain conditions, you can add a @TargetAPI annotation to surpress the warning:
> 
> http://tools.android.com/recent/lintapicheck
> 
> A similar behaviour should be fairly easy to add to Clang and would make it heaps easier to implement/ensure backward compatibility of iOS/Mac apps. As a matter of fact, I've made the topic of backward compatibility the subject of my diploma thesis and started hacking on Clang a few days ago and already see these warnings popping up.
> 
> An initial (very informal) survey on this issue revealed that app developers would appreciate such a feature and they'd prefer having the compiler issue the warnings with every build (with a command line option to disable the feature) rather than running the analyzer separately. For my first hacks, I started checking the API version in the methods of "SemaExprObjC.cpp", although I can see that from a conceptial point of view, it's probably not the best place... 
> 
> I'm keen to hear your thoughts on that, and whether or not you are working on similar Clang features.
> 
> Cheers
> Hagi
> 
>> On 28 Oct 2012, at 06:00, Ted Kremenek <kremenek at apple.com> wrote:
>> > 
>> > Hi Richard,
>> > 
>> > I think it would be easy to add a warning that checks if a use API is newer than the minimum deployment target, but I would not want that warning to go into mainline Clang because (1) most developers would hate the warning as it would produce too many false positives and (2) I believe we can do much better than that.  While it might be "hard" to get it right, I think it is quite doable.
>> > 
>> > I'm curious about your last comment, that "unless a standard convention is used it is going to be almost impossible to do well."  Can you elaborate?  I thought there were standard conventions for checking for weak linked APIs, etc?
>> > 
>> > Cheers,
>> > Ted
>> 
>> hey ted,
>> 
>> perhaps you are right, maybe i was just being too lazy. the current documentation on using weakly linked apis is here:
>> 
>> https://developer.apple.com/library/mac/#documentation/developertools/conceptual/cross_development/Using/using.html#//apple_ref/doc/uid/20002000-SW6
>> 
>> so maybe it is as simple as checking that every call to an api newer than the minimum deployment target is contained in a block like this example:
>> 
>> if ([UIImagePickerController instancesRespondToSelector:@selector (availableCaptureModesForCameraDevice:)]) {
>>     // Method is available for use.
>> } else {
>>     // Method is not available.
>> }
>> 
>> but i have the feeling there are some edge cases to take care of here, as well as handling C apis.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130123/dad3a31c/attachment.html>