Problem
When an Objective-C enum typedef carries API_UNAVAILABLE(maccatalyst) on the typedef (rather than on the enum body), xtro-sharpie's EnumCheck.VisitEnumDecl does not detect the unavailability and incorrectly reports the enum as !missing-enum! on Mac Catalyst.
Concrete example
In the FileProvider SDK headers (Xcode 27.0 Beta 3), the following enums are explicitly marked unavailable on Mac Catalyst:
NSFileProviderContentPolicyNSFileProviderNamespacePolicy
When running xtro against the Mac Catalyst assembly, these are reported as:
!missing-enum! NSFileProviderContentPolicy not bound
!missing-enum! NSFileProviderNamespacePolicy not bound
These are false positives: the enums are correctly not bound for Mac Catalyst because the SDK marks them as unavailable.
Root cause
In the Clang AST, when you have:
typedef NS_ENUM(NSInteger, NSFileProviderNamespacePolicy) {
NSFileProviderNamespacePolicyDefault = 0,
...
} API_UNAVAILABLE(maccatalyst);The API_UNAVAILABLE(maccatalyst) availability attribute is attached to the TypedefDecl that names the enum, not to the EnumDecl that describes the enum body.
EnumCheck.VisitEnumDecl (tests/xtro-sharpie/xtro-sharpie/EnumCheck.cs) checks availability via:
// check availability macros to see if the API is available on the OS and not deprecated
if (!decl.IsAvailable ())
return;Because the availability attribute is on the TypedefDecl and not the EnumDecl, IsAvailable() returns true for Mac Catalyst, and xtro proceeds to look for the enum in the Mac Catalyst assembly—where it correctly does not exist.
Workaround
The affected entries have been added to tests/xtro-sharpie/api-annotations-dotnet/MacCatalyst-FileProvider.ignore as false positives in PR #26165.
Proposed fix
In EnumCheck.VisitEnumDecl, after checking decl.IsAvailable(), also find the corresponding TypedefDecl (if any) and check its availability. If the typedef is unavailable on the current platform, skip the enum.
Alternatively, the IsAvailable() extension on Decl (tests/xtro-sharpie/xtro-sharpie/Helpers.cs) could be extended to also walk up to any enclosing typedef and check its attributes.
Related
Problem
When an Objective-C enum typedef carries
API_UNAVAILABLE(maccatalyst)on the typedef (rather than on the enum body), xtro-sharpie'sEnumCheck.VisitEnumDecldoes not detect the unavailability and incorrectly reports the enum as!missing-enum!on Mac Catalyst.Concrete example
In the FileProvider SDK headers (Xcode 27.0 Beta 3), the following enums are explicitly marked unavailable on Mac Catalyst:
NSFileProviderContentPolicyNSFileProviderNamespacePolicyWhen running xtro against the Mac Catalyst assembly, these are reported as:
These are false positives: the enums are correctly not bound for Mac Catalyst because the SDK marks them as unavailable.
Root cause
In the Clang AST, when you have:
The
API_UNAVAILABLE(maccatalyst)availability attribute is attached to theTypedefDeclthat names the enum, not to theEnumDeclthat describes the enum body.EnumCheck.VisitEnumDecl(tests/xtro-sharpie/xtro-sharpie/EnumCheck.cs) checks availability via:Because the availability attribute is on the
TypedefDecland not theEnumDecl,IsAvailable()returnstruefor Mac Catalyst, and xtro proceeds to look for the enum in the Mac Catalyst assembly—where it correctly does not exist.Workaround
The affected entries have been added to
tests/xtro-sharpie/api-annotations-dotnet/MacCatalyst-FileProvider.ignoreas false positives in PR #26165.Proposed fix
In
EnumCheck.VisitEnumDecl, after checkingdecl.IsAvailable(), also find the correspondingTypedefDecl(if any) and check its availability. If the typedef is unavailable on the current platform, skip the enum.Alternatively, the
IsAvailable()extension onDecl(tests/xtro-sharpie/xtro-sharpie/Helpers.cs) could be extended to also walk up to any enclosing typedef and check its attributes.Related
.ignoreworkaround