New issue
Advanced search Search tips

Issue 746559 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Blocking:
issue 729895
issue 729906



Sign in to add a comment

Can’t build device/bluetooth with the 10.13 SDK and clang’s -Wunguarded-availability-new

Project Member Reported by mark@chromium.org, Jul 19 2017

Issue description

While building device/bluetooth/bluetooth_adapter_mac.mm with the 10.13 SDK (from Xcode 9b3 9M174d), -Wunguarded-availability-new produces warnings (errors with -Werror) about enum constants from CoreBluetooth.framework being unavailable before 10.13. The errors are reproduced below.

The enum constants are CBManagerStateUnsupported and CBManagerStatePoweredOn. These are members of the CBManagerState enum, which is defined in <CoreBluetooth/CBManager.h> as

typedef NS_ENUM(NSInteger, CBManagerState) {
        CBManagerStateUnknown = 0,
        CBManagerStateResetting,
        CBManagerStateUnsupported,
        CBManagerStateUnauthorized,
        CBManagerStatePoweredOff,
        CBManagerStatePoweredOn,
} NS_ENUM_AVAILABLE(10_13, 10_0);

which does state that these are available beginning in 10.13. Indeed, this isn’t in earlier SDKs. However, in previous SDKs, the CBCentralManagerState enum is available in <CoreBluetooth/CBCentralManager.h>. This has been deprecated in 10.13 with the recommendation to use CBManager instead, but the names and values are equivalent except for the presence/absence of “Central”. These older names can be used with older SDKs.

The problem is that -Wunguarded-availability-new makes it difficult or impossible to write code that is compatible with the 10.13 SDK and older SDKs (such as 10.10, which Chrome currently uses for official builds).

device/bluetooth/bluetooth_adapter_mac.h attempts to allow the new names to be used with older SDKs by providing local definitions of the new names in terms of the old when building with pre-10.13 SDKs (https://chromium.googlesource.com/chromium/src/+/724d9901b9f8f44e67a9b9d6da0722bb443e5d0c/device/bluetooth/bluetooth_adapter_mac.h#32, https://chromium.googlesource.com/chromium/src/+/724d9901b9f8f44e67a9b9d6da0722bb443e5d0c). This worked until -Wunguarded-availability-new.

We’re now in a situation where we can’t use the old names with the 10.13 SDK without triggering the errors in  bug 729906 , and we can’t use the new names with the 10.13 SDK because Clang doesn’t realize that we have our own definitions of them when building with older SDKs.

The errors:

../../device/bluetooth/bluetooth_adapter_mac.mm:162:33: error: 'CBManagerStateUnsupported' is only available on macOS 10_13 or newer [-Werror,-Wunguarded-availability-new]
                                CBManagerStateUnsupported);
                                ^~~~~~~~~~~~~~~~~~~~~~~~~
../../../../../Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/CoreBluetooth.framework/Headers/CBManager.h:31:28: note: 'CBManagerState' has been explicitly marked partial here
typedef NS_ENUM(NSInteger, CBManagerState) {
                           ^
../../device/bluetooth/bluetooth_adapter_mac.mm:162:33: note: enclose 'CBManagerStateUnsupported' in an @available check to silence this warning
                                CBManagerStateUnsupported);
                                ^~~~~~~~~~~~~~~~~~~~~~~~~
../../device/bluetooth/bluetooth_adapter_mac.mm:171:33: error: 'CBManagerStatePoweredOn' is only available on macOS 10_13 or newer [-Werror,-Wunguarded-availability-new]
                                CBManagerStatePoweredOn);
                                ^~~~~~~~~~~~~~~~~~~~~~~
../../../../../Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/CoreBluetooth.framework/Headers/CBManager.h:31:28: note: 'CBManagerState' has been explicitly marked partial here
typedef NS_ENUM(NSInteger, CBManagerState) {
                           ^
../../device/bluetooth/bluetooth_adapter_mac.mm:171:33: note: enclose 'CBManagerStatePoweredOn' in an @available check to silence this warning
                                CBManagerStatePoweredOn);
                                ^~~~~~~~~~~~~~~~~~~~~~~
../../device/bluetooth/bluetooth_adapter_mac.mm:605:45: error: 'CBManagerStatePoweredOn' is only available on macOS 10_13 or newer [-Werror,-Wunguarded-availability-new]
  if ([low_energy_central_manager_ state] < CBManagerStatePoweredOn) {
                                            ^~~~~~~~~~~~~~~~~~~~~~~
../../../../../Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/CoreBluetooth.framework/Headers/CBManager.h:31:28: note: 'CBManagerState' has been explicitly marked partial here
typedef NS_ENUM(NSInteger, CBManagerState) {
                           ^
../../device/bluetooth/bluetooth_adapter_mac.mm:605:45: note: enclose 'CBManagerStatePoweredOn' in an @available check to silence this warning
  if ([low_energy_central_manager_ state] < CBManagerStatePoweredOn) {
                                            ^~~~~~~~~~~~~~~~~~~~~~~
3 errors generated.
 

Comment 1 by thakis@chromium.org, Jul 19 2017

I think this is an SDK bug, and since that's still in beta I filed these rdars hoping they'd fix this:
https://openradar.appspot.com/33375728
https://openradar.appspot.com/33375690

Comment 2 by tapted@chromium.org, Jul 21 2017

Status: Available (was: Untriaged)
Thanks for filing those rdars!

[mac triage] I guess this is ExternalDependency for now, but I don't want to put this in a closed state.

If Apple don't come through.. I can't really come up with anything smarter than just suppressing the warnings until we drop support for compiling against the 10.12 SDK :/

Unlike the color profile stuff, I don't think this will result in runtime errors. Apple might just be assuming nobody wants to compile against any SDK older than the newest SDK you can support.

Comment 3 by thakis@chromium.org, Jul 21 2017

If they don't fix this, I think the Best Workaround (tm) is to use the old enum names, and cast the result of [CBManager state] to CBCentralManagerState.

Comment 4 by tapted@chromium.org, Jul 26 2017

Cc: -tapted@chromium.org
Owner: tapted@chromium.org
Status: Started (was: Available)
I think Apple have been silent on the rdars. I'll try to figure out something.. hopefully it won't be too ugly.

Comment 5 by tapted@chromium.org, Jul 27 2017

-> https://chromium-review.googlesource.com/c/587510/ . Just waiting on a full build...
Project Member

Comment 6 by bugdroid1@chromium.org, Jul 28 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/993f08cc857c186d49cf47c63a0dd07ea3b05aa9

commit 993f08cc857c186d49cf47c63a0dd07ea3b05aa9
Author: Trent Apted <tapted@chromium.org>
Date: Fri Jul 28 03:38:58 2017

MacOS 10.13 SDK Workaround for bluetooth CBCentralManagerState.

The 10.13 SDK deprecates the CBCentralManagerState enum, but marks the
replacement enum with limited availability, making it unusable. API methods
now return the new enum, so to compare enum values the new enum must be cast.
This is an SDK bug: rdar://33375728

An earlier change (r477867) tried to work around the SDK bug by moving
to the non-deprecated enum via a redeclare. But this stopped working
with a clang roll and -Wunguarded-availability-new.

Using the deprecated enum means we'll eventually get deprecation warnings
when trying to bump the minimum supported SDK version to 10.13, but maybe
the SDK will be in a better shape by then.

Bug:  746559 
Change-Id: I0ed7d563ee00578a442f5b2986c4b516cffbc236
Reviewed-on: https://chromium-review.googlesource.com/587510
Reviewed-by: Giovanni Ortuño Urquidi <ortuno@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#490244}
[modify] https://crrev.com/993f08cc857c186d49cf47c63a0dd07ea3b05aa9/device/bluetooth/bluetooth_adapter_mac.h
[modify] https://crrev.com/993f08cc857c186d49cf47c63a0dd07ea3b05aa9/device/bluetooth/bluetooth_adapter_mac.mm
[modify] https://crrev.com/993f08cc857c186d49cf47c63a0dd07ea3b05aa9/device/bluetooth/bluetooth_adapter_mac_unittest.mm
[modify] https://crrev.com/993f08cc857c186d49cf47c63a0dd07ea3b05aa9/device/bluetooth/bluetooth_low_energy_discovery_manager_mac.mm
[modify] https://crrev.com/993f08cc857c186d49cf47c63a0dd07ea3b05aa9/device/bluetooth/test/bluetooth_test_mac.mm
[modify] https://crrev.com/993f08cc857c186d49cf47c63a0dd07ea3b05aa9/device/bluetooth/test/mock_bluetooth_central_manager_mac.h

Comment 7 by tapted@chromium.org, Jul 28 2017

Status: Fixed (was: Started)

Sign in to add a comment