[patch/rfc] An opt-in warning for functions whose availability(introduced) is newer than the deployment target

[Nico Weber]

Doug or Fariborz, can one of you comment on if you're fine with this in
theory?

On Thu, Jan 29, 2015 at 3:33 PM, Nico Weber <thakis at chromium.org> wrote:

> Ping.
>
> Another way to think about this warning is that it effectively ignores
> declarations where the introduced version is higher than the deployment
> version.
>
> On Thu, Jan 8, 2015 at 6:14 PM, Nico Weber <thakis at chromium.org> wrote:
>
>> Hi,
>>
>> the Mac OS X and iOS SDKs add new functions in new releases. Apple
>> recommends using the newest SDK and setting the deployment target to
>> whatever old OS version one wants to support, and only calling new
>> functions after checking that they are available at runtime.
>>
>> In practice, we (Chromium) get this wrong. Others who support old OS X
>> versions get this wrong too. Hence, we (Chromium) use a very old SDK and
>> then manually declare new functions when we want to call them – this
>> reduces the chance of us forgetting if they are available at runtime
>> considerably, in practice. But using an old SDK has its problems –
>> sometimes the frameworks check which SDK an app was linked against and only
>> then activate bug fixes, and newer Xcodes don't ship include old SDKs.
>>
>> Ideally, we could use a new SDK but get a warning when we use a new API
>> without a manual redeclaration – this protects us against new APIs the same
>> way using an old SDK does without the drawbacks that this brings.
>>
>> The attached patch is a sketch how such a warning might work. How
>> repulsive is this idea? Are there other approaches to this problem? If the
>> basic idea is ok: Any comments on the implementation?
>>
>> I'm not sure who should look at this. dgregor, you wrote r128127 which
>> looks in the same area.
>>
>> Thanks,
>> Nico
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150202/327eede5/attachment.html>