Idea: Extend @available so that it can imply an upper bound too


Bugzilla Link	PR33815
Status	REOPENED
Importance	P enhancement
Reported by	Nico Weber (nicolasweber@gmx.de)
Reported on	2017-07-17 07:38:57 -0700
Last modified on	2017-08-01 09:41:14 -0700
Version	unspecified
Hardware	PC Linux
CC	arphaman@gmail.com, erik.pilkington@gmail.com, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

(Feature idea; not important; feel free to WontFix.)

This is a somewhat common pattern:

  if (@available(macos 10.10, *)) {
    DoThingUsingNewAPIs()
  } else {
    DoThingUsingOldAPIs()
  }

(e.g. here:
https://cs.chromium.org/chromium/src/content/common/quarantine/quarantine_mac.mm?l=239)

@available helps with the first half of that branch, but the implementation of
DoThingUsingOldAPIs() often has to suppress Wdeprecated-declaration (see e.g.
the above-linked file). It'd be cool if the else of an if
(@available(macos10.10)) was a "at most macOS 10.9" region, which could call
functions marked with attrib(availability(deprecated=10.10), and then in those
functions calls to deprecated functions wouldn't be emitted.

...hmm, looking more at this example, there's this comment:

// Once Chrome no longer supports macOS 10.9, this code will no longer be
// necessary. Note that LSCopyItemAttribute was deprecated in macOS 10.8, but
// the replacement to kLSItemQuarantineProperties did not exist until macOS
// 10.10.

So I think this only helps in situations where the availability annotation in
the SDK is wrong. Suppressing warnings for that is OK, I suppose.

Quuxplusone / LLVMBugzillaTest

Idea: Extend @available so that it can imply an upper bound too #32787