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

[Richard]

On 26 Oct 2012, at 21:49, Ted Kremenek <kremenek at apple.com> wrote:

> On Oct 26, 2012, at 11:46 AM, John McCall <rjmccall at apple.com> wrote:
> 
>> On Oct 26, 2012, at 7:39 AM, Richard wrote:
>>> i am trying to generate warnings building an xcode project when calling a method that is available later than the current minimum deployment target. is this a job for a clang analyzer plugin, or is there some easier way to achieve this that i am not aware of?
>> 
>> In theory it's really straightforward to do;  there's an availability attribute which should give us this information.  In practice it's quite a bit harder because real code often intentionally uses APIs that aren't available on the minimum deployment target, and that's totally fine *if that code just doesn't run on such targets*.  Detecting that latter condition and suppressing the warning there is quite a bit harder.
> 
> 
> Hi Richard,
> 
> John is absolutely right.  There are well-known idioms, such as those published in Apple's SDK Compatibility Guide, which allow to use APIs newer than your minimum deployment target but then gracefully degrade when not running on a newer OS.  Doing this well regards doing dataflow and control-flow analysis.  It's something I have been thinking about recently, and if you have specific concerns or requests about such a warning I would love to hear them.
> 
> Cheers,
> Ted


hey ted, john

i understand the concept of weak linking to apis newer than the deployment target, but it is very easy to accidentally include api calls and receive no warning about this until the app crashes at runtime, and it is not really feasible to test an entire app flow on all possible ios versions when updating older projects. i have recently had to fix a couple of bugs for this exact reason.

perhaps it would be nice just to have an optional analysis step that would always output a warning to highlight api calls that are newer than the minimum deployment target, that could be ignored by the developer if an optional code path has been used? i feel that accidentally including newer apis is probably the more common case than the developer correctly handling this situation (well it is where i work anyway :). i agree that doing this right is a lot more work, and unless a standard convention is used it is going to be almost impossible to do well.

thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121027/101125d8/attachment.html>