Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clang can't compile headers from the MacOSX14 SDK when targeting catalyst #64438

Closed
nico opened this issue Aug 4, 2023 · 5 comments
Closed
Labels
clang:frontend Language frontend issues, e.g. anything involving "Sema"

Comments

@nico
Copy link
Contributor

nico commented Aug 4, 2023

This builds with Xcode 14's clang, but not with open-source clang:

% cat test.m
#import <UIKit/UIKit.h>

% path/to/clang++  -std=c++11 -target arm64-apple-ios16.6-macabi -isysroot sdk/xcode_links/MacOSX14.0.sdk -isystem sdk/xcode_links/MacOSX14.0.sdk/System/iOSSupport/usr/include -iframework sdk/xcode_links/MacOSX14.0.sdk/System/iOSSupport/System/Library/Frameworks ~/Desktop/foo.mm  -o ~/Desktop/foo.a
…
sdk/xcode_links/MacOSX14.0.sdk/System/Library/Frameworks/FileProvider.framework/Headers/NSFileProviderItem.h:127:32: error: 'NSFileProviderItemCapabilities' is unavailable: not available on macCatalyst
  127 | typedef NS_OPTIONS(NSUInteger, NSFileProviderItemCapabilities) {
      |                                ^

The diagnostic is correct! NSFileProviderItem.h does:

FILEPROVIDER_API_AVAILABILITY_V2_V3
typedef NS_OPTIONS(NSUInteger, NSFileProviderItemCapabilities) {

And NSFileProviderDefines.h does:

#define FILEPROVIDER_API_AVAILABILITY_V2_V3 API_AVAILABLE(ios(11.0), macos(11.0)) API_UNAVAILABLE(macCatalyst) API_UNAVAILABLE(watchos, tvos)

This expands to

__attribute__((availability(ios,introduced=11.0))) __attribute__((availability(macos,introduced=11.0))) __attribute__((availability(macCatalyst,unavailable))) __attribute__((availability(watchos,unavailable))) __attribute__((availability(tvos,unavailable)))

and it does mark NSFileProviderItemCapabilities as unavailable on macCatalyst.

In the 13.3 SDK, CFAvailability.h did:

#define CF_OPTIONS(_type, _name) _type _name; enum __CF_OPTIONS_ATTRIBUTES : _type

But in the 14.0 SDK, it instead does:

+#define CF_OPTIONS(_type, _name) _type _name; enum __CF_OPTIONS_ATTRIBUTES : _name

That is, previously the enum values were in an unnamed enum with underlying type NSUInteger, but now they're in an unnamed enum with underlying type NSFileProviderItemCapabilities. NSFileProviderItemCapabilities is unavailable and now referenced, so clang warns.

Here's a reduced repro based on that:

% cat repro.mm
#define CF_OPTIONS(_type, _name) enum : _name

__attribute__((availability(macos,introduced=11.0)))
__attribute__((availability(macCatalyst,unavailable))) 
typedef unsigned NSFileProviderItemCapabilities;

CF_OPTIONS(unsigned, NSFileProviderItemCapabilities) {
  A = 0,
};
% out/gn/bin/clang -std=c++17 -target arm64-apple-ios16.6-macabi repro.mm -isysroot ~/Downloads/MacOSX14.sdk   -c
repro.mm:7:22: error: 'NSFileProviderItemCapabilities' is unavailable: not available on macCatalyst
    7 | CF_OPTIONS(unsigned, NSFileProviderItemCapabilities) {
      |                      ^
repro.mm:5:18: note: 'NSFileProviderItemCapabilities' has been explicitly marked unavailable here
    5 | typedef unsigned NSFileProviderItemCapabilities;
      |                  ^
1 error generated.

Xcode 13.3's clang diags the same way on this repro. But Xcode 14's doesn't:

% /Users/thakis/Downloads/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -std=c++17 -target arm64-apple-ios16.6-macabi repro.mm -isysroot ~/Downloads/MacOSX14.sdk -c
# no diag

But if I remove the CF_OPTIONS macro and inline its contents, then xcode 14's clang also diags.

So it must have some "if avail diag is for unnamed enum where both the unavail type and the enum keyword are part of a macros, then don't diag" logic I guess?

@nico
Copy link
Contributor Author

nico commented Aug 4, 2023

The Xcode 14 clang change means that

  auto i = A;

now won't diag at all when targeting catalyst, even though the enum is marked as unavailable.

@BertalanD
Copy link
Member

Relevant downstream change: swiftlang#6431

@nico
Copy link
Contributor Author

nico commented Aug 4, 2023

Thanks!

@nico
Copy link
Contributor Author

nico commented Aug 7, 2023

@EugeneZelenko EugeneZelenko added clang:frontend Language frontend issues, e.g. anything involving "Sema" and removed new issue labels Aug 7, 2023
@llvmbot
Copy link
Collaborator

llvmbot commented Aug 7, 2023

@llvm/issue-subscribers-clang-frontend

@nico nico closed this as completed in bb58748 Aug 7, 2023
tru pushed a commit that referenced this issue Aug 8, 2023
…me from CF_OPTIONS

This cherry-picks swiftlang#6431
since without it, macOS 14 SDK headers don't compile when targeting
catalyst.

Fixes #64438.

(cherry picked from commit bb58748)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:frontend Language frontend issues, e.g. anything involving "Sema"
Projects
None yet
Development

No branches or pull requests

4 participants