Xcode 10 and -Wunguarded-availability-new

589 views
Skip to first unread message

Vadim Zeitlin

unread,
Apr 15, 2019, 7:45:04 PM4/15/19
to wx-dev
Hello,

If I try to use NSAppearanceNameDarkAqua in the code, I get warnings like
the following from Xcode 10 compiler:

src/osx/cocoa/settings.mm:68:57: warning: 'NSAppearanceNameDarkAqua' is only available on macOS 10.14 or newer [-Wunguarded-availability-new]
@[NSAppearanceNameAqua, NSAppearanceNameDarkAqua]];
^~~~~~~~~~~~~~~~~~~~~~~~
.../NSAppearance.h:62:38: note: 'NSAppearanceNameDarkAqua' has been marked as being introduced in macOS 10.14 here, but the deployment target is macOS 10.7.0
APPKIT_EXTERN NSAppearanceName const NSAppearanceNameDarkAqua NS_AVAILABLE_MAC(10_14);
^
osx/cocoa/settings.mm:68:57: note: enclose 'NSAppearanceNameDarkAqua' in an @available check to silence this warning

This partially makes sense, but I don't understand a couple of things
here:

1. Why don't I get the same warning about NSAppearanceNameAqua which is
declared with NS_AVAILABLE_MAC(10_9) which is still greater than 10.7?

2. Why is it the only place in the code which results in these warnings,
when we have a few more places where wxPlatformInfo::CheckOSVersion()
is used to check that we're running under 10.14?

3. Last but very much not least: is there any way to get rid of this
warning without using @available as advised (because this would break
compilation with earlier Xcode versions AFAICS) or explicitly disabling
this warning?

TIA!
VZ

Stefan Csomor

unread,
Apr 16, 2019, 2:03:53 PM4/16/19
to wx-...@googlegroups.com
Hi

src/osx/cocoa/settings.mm:68:57: warning: 'NSAppearanceNameDarkAqua' is only available on macOS 10.14 or newer [-Wunguarded-availability-new]
@[NSAppearanceNameAqua, NSAppearanceNameDarkAqua]];
^~~~~~~~~~~~~~~~~~~~~~~~
.../NSAppearance.h:62:38: note: 'NSAppearanceNameDarkAqua' has been marked as being introduced in macOS 10.14 here, but the deployment target is macOS 10.7.0
APPKIT_EXTERN NSAppearanceName const NSAppearanceNameDarkAqua NS_AVAILABLE_MAC(10_14);
^
osx/cocoa/settings.mm:68:57: note: enclose 'NSAppearanceNameDarkAqua' in an @available check to silence this warning

This partially makes sense, but I don't understand a couple of things
here:

1. Why don't I get the same warning about NSAppearanceNameAqua which is
declared with NS_AVAILABLE_MAC(10_9) which is still greater than 10.7?

2. Why is it the only place in the code which results in these warnings,
when we have a few more places where wxPlatformInfo::CheckOSVersion()
is used to check that we're running under 10.14?

well I learned something new today as well :-) :

Xcode 9 introduced two new warnings
-Wunguarded-availability
and
-Wunguarded-availability-new
the former is off by default, the latter on by default
-Wunguarded-availability-new only warns about API introduced in or after macOS 10.13, iOS 11, tvOS 11 or watchOS 4.

3. Last but very much not least: is there any way to get rid of this
warning without using @available as advised (because this would break
compilation with earlier Xcode versions AFAICS) or explicitly disabling
this warning?

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wunguarded-availability-new "

(...) code using new API here

#pragma clang diagnostic pop

Thanks for your work,

Stefan

Vadim Zeitlin

unread,
Apr 16, 2019, 3:33:15 PM4/16/19
to wx-...@googlegroups.com
On Tue, 16 Apr 2019 18:03:51 +0000 Stefan Csomor wrote:

SC> 3. Last but very much not least: is there any way to get rid of this
SC> warning without using @available as advised (because this would break
SC> compilation with earlier Xcode versions AFAICS) or explicitly disabling
SC> this warning?
SC>
SC> #pragma clang diagnostic push
SC> #pragma clang diagnostic ignored "-Wunguarded-availability-new "
SC>
SC> (...) code using new API here
SC>
SC> #pragma clang diagnostic pop

OK, I'll do this, I just hoped there could be some way to emulate
"@available" magic somehow, i.e. let the compiler know that our
CheckOSVersion() does the same thing it does. But then I have no real idea
how does "@available" work...

BTW, is there some place where (modern) Objective-C syntax is concisely
summarized? You usually can find things once you know what you're looking
for, but my problem is that I almost never do and having some sort of an
overview/summary would be very helpful.

TIA,
VZ

Stefan Csomor

unread,
Apr 17, 2019, 6:01:16 AM4/17/19
to wx-...@googlegroups.com
Hi

SC> 3. Last but very much not least: is there any way to get rid of this
SC> warning without using @available as advised (because this would break
SC> compilation with earlier Xcode versions AFAICS) or explicitly disabling
SC> this warning?
SC>
SC> #pragma clang diagnostic push
SC> #pragma clang diagnostic ignored "-Wunguarded-availability-new "
SC>
SC> (...) code using new API here
SC>
SC> #pragma clang diagnostic pop

OK, I'll do this, I just hoped there could be some way to emulate
"@available" magic somehow, i.e. let the compiler know that our
CheckOSVersion() does the same thing it does. But then I have no real idea
how does "@available" work...

from https://developer.apple.com/library/archive/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html#//apple_ref/doc/uid/TP40001051-CH1-SW2

"
To guard the use of new APIs, use an if statement combined with @available, a new Objective-C expression that checks the system version. For example:

if (@available(macOS 10.13, iOS 11, *)) {
// The compiler will not warn about uses of APIs from macOS 10.13
// or iOS 11 here
}
C or C++ code can use __builtin_available, a new builtin whose semantics are equivalent to @available.
The -Wunguarded-availability flag is off by default to prevent unexpected warnings in existing projects. -Wunguarded-availability-new, a less strict version of the compiler flag that warns about unguarded uses of APIs only when they were introduced in macOS 10.13 or later, iOS 11 or later, tvOS 11 or later, or watchOS 4 or later. The -Wunguarded-availability-new flag is on by default. (7184689)
"

So we could somehow have a macro that is different when used in xcode9+ (for 10.14 SDK xcode 10 would be used anyway) and uses __builtin_available, the latter is used like so
if (__builtin_available(iOS 11, macOS 10.13, *))
{
CFNewAPIOniOS11();
}

so we chould have a macro that both uses our own CheckVersion and __builtin_available

BTW, is there some place where (modern) Objective-C syntax is concisely
summarized? You usually can find things once you know what you're looking
for, but my problem is that I almost never do and having some sort of an
overview/summary would be very helpful.

something like this : https://www.raywenderlich.com/3028-objective-c-cheat-sheet-and-quick-reference ?

HTH

Stefan


Vadim Zeitlin

unread,
Apr 17, 2019, 6:13:34 PM4/17/19
to wx-...@googlegroups.com
On Wed, 17 Apr 2019 10:01:13 +0000 Stefan Csomor wrote:

SC> from https://developer.apple.com/library/archive/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html#//apple_ref/doc/uid/TP40001051-CH1-SW2
SC>
SC> "
SC> To guard the use of new APIs, use an if statement combined with @available, a new Objective-C expression that checks the system version. For example:
SC>
SC> if (@available(macOS 10.13, iOS 11, *)) {
SC> // The compiler will not warn about uses of APIs from macOS 10.13
SC> // or iOS 11 here
SC> }
SC> C or C++ code can use __builtin_available, a new builtin whose semantics are equivalent to @available.
SC> The -Wunguarded-availability flag is off by default to prevent unexpected warnings in existing projects. -Wunguarded-availability-new, a less strict version of the compiler flag that warns about unguarded uses of APIs only when they were introduced in macOS 10.13 or later, iOS 11 or later, tvOS 11 or later, or watchOS 4 or later. The -Wunguarded-availability-new flag is on by default. (7184689)
SC> "
SC>
SC> So we could somehow have a macro that is different when used in xcode9+ (for 10.14 SDK xcode 10 would be used anyway) and uses __builtin_available, the latter is used like so
SC> if (__builtin_available(iOS 11, macOS 10.13, *))
SC> {
SC> CFNewAPIOniOS11();
SC> }
SC>
SC> so we chould have a macro that both uses our own CheckVersion and __builtin_available

Thanks, I hadn't realized they also had a builtin for this and it indeed
makes things simpler and more understandable, so I've created

https://github.com/wxWidgets/wxWidgets/pull/1299

based on your idea (as you already know because I've requested your review
there, but I'm also posting it here in case anybody else might want to look
there and comment).

SC> BTW, is there some place where (modern) Objective-C syntax is concisely
SC> summarized? You usually can find things once you know what you're looking
SC> for, but my problem is that I almost never do and having some sort of an
SC> overview/summary would be very helpful.
SC>
SC> something like this : https://www.raywenderlich.com/3028-objective-c-cheat-sheet-and-quick-reference ?

Thanks, but this is a bit too basic... I guess there is no substitute to
actually reading Apple docs, so I'll try to find time to do this.

Regards,
VZ

Stefan Csomor

unread,
Apr 18, 2019, 5:23:38 AM4/18/19
to wx-...@googlegroups.com
Hi

SC> so we chould have a macro that both uses our own CheckVersion and __builtin_available

Thanks, I hadn't realized they also had a builtin for this and it indeed
makes things simpler and more understandable, so I've created

https://github.com/wxWidgets/wxWidgets/pull/1299

based on your idea (as you already know because I've requested your review
there, but I'm also posting it here in case anybody else might want to look
there and comment).

that's great, thanks a lot


SC> BTW, is there some place where (modern) Objective-C syntax is concisely
SC> summarized? You usually can find things once you know what you're looking
SC> for, but my problem is that I almost never do and having some sort of an
SC> overview/summary would be very helpful.
SC>
SC> something like this : https://www.raywenderlich.com/3028-objective-c-cheat-sheet-and-quick-reference ?

Thanks, but this is a bit too basic... I guess there is no substitute to
actually reading Apple docs, so I'll try to find time to do this.

yes, I understand, I just either found the full obj-c manual, or very small summaries, nothing in between

Thanks,

Stefan


Reply all
Reply to author
Forward
0 new messages