Skip to content

SymbolGraphGen: Expand anyAppleOS availability in symbol graphs#88813

Merged
tshortli merged 3 commits intoswiftlang:mainfrom
tshortli:expand-any-apple-os-in-symbol-graphs
May 8, 2026
Merged

SymbolGraphGen: Expand anyAppleOS availability in symbol graphs#88813
tshortli merged 3 commits intoswiftlang:mainfrom
tshortli:expand-any-apple-os-in-symbol-graphs

Conversation

@tshortli
Copy link
Copy Markdown
Contributor

@tshortli tshortli commented May 4, 2026

In documentation, @available(anyAppleOS 26, *) should be expanded to platform-specific availability attributes, rather than being rendered as an attribute for the platform "Any Apple OS". Also, teach swift-symbolgraph-extract to optionally limit platform availability in the symbol graph output to just active platforms when the -active-platform-availability-only flag is specified.

This PR also includes an NFC change to stop including headers like SymbolGraphOptions.h in ASTContext.h so that modifying them doesn't always involve a full rebuild of the compiler.

Resolves rdar://174557919.

@tshortli tshortli requested a review from a team as a code owner May 4, 2026 22:48
@tshortli
Copy link
Copy Markdown
Contributor Author

tshortli commented May 4, 2026

@swift-ci please smoke test

Comment thread test/SymbolGraph/Symbols/Mixins/Availability/AnyAppleOS/Expansion.swift Outdated
@tshortli tshortli force-pushed the expand-any-apple-os-in-symbol-graphs branch from 329a723 to 10f5540 Compare May 5, 2026 20:24
@tshortli
Copy link
Copy Markdown
Contributor Author

tshortli commented May 5, 2026

@swift-ci please test macOS

@tshortli tshortli force-pushed the expand-any-apple-os-in-symbol-graphs branch from 10f5540 to db97c29 Compare May 6, 2026 03:37
@tshortli
Copy link
Copy Markdown
Contributor Author

tshortli commented May 6, 2026

@swift-ci please test

tshortli added 3 commits May 6, 2026 06:43
Anything that can be forward declared in ASTContext.h should be because it is
included by nearly every implementation file in the compiler. Avoiding these
includes allows these various options types to be changed without a full
rebuild.

NFC.
In documentation, `@available(anyAppleOS 26, *)` should be expanded to
platform-specific availability attributes, rather than being rendered as an
attribute for the platform "Any Apple OS".

Partially resolves rdar://174557919.
When -active-platform-availability-only is specified swift-symbolgraph-extract
should only emit availability metadata for the active platform (inferred from
the -target).

Resolves rdar://174557919.
@tshortli tshortli force-pushed the expand-any-apple-os-in-symbol-graphs branch from db97c29 to d78b08a Compare May 6, 2026 13:43
@tshortli
Copy link
Copy Markdown
Contributor Author

tshortli commented May 6, 2026

@swift-ci please test

@tshortli
Copy link
Copy Markdown
Contributor Author

tshortli commented May 7, 2026

swiftlang/llvm-project#12912

@swift-ci please test macOS

// platform inferred from the -target. Include app extension availability,
// too.
Options.ActivePlatform =
platformForTriple(Target, /*enableAppExtensionRestrictions=*/true);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding support for application extensions as well, we were tracking this as a future improvement (rdar://175796455)

Copy link
Copy Markdown
Contributor

@QuietMisdreavus QuietMisdreavus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good, thanks! I have one question about an implementation detail, but it's not critical in the grand scheme. (I'm just worried about anyAppleOS expanding to include a different/newer platform in the future and having to update this code here.)

Comment on lines +676 to +682
static const PlatformKind ApplePlatforms[] = {
PlatformKind::macOS,
PlatformKind::iOS,
PlatformKind::watchOS,
PlatformKind::tvOS,
PlatformKind::visionOS,
};
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It strikes me as a bit odd that we aren't deferring to some other list of expanded platforms that exist elsewhere in the availability logic. Is the anyAppleOS availability check doing some other kind of check where it doesn't have a list like this?

@tshortli
Copy link
Copy Markdown
Contributor Author

tshortli commented May 8, 2026

There isn't a more central list because availability checking doesn't really do any expansion like this (platform availability inheritance is handled via queries built on switch statements). I agree that this is fragile but I don't have a good alternative right now. Even looping over all platforms would be inefficient and require specialized logic because we would want to discard the app extension platforms.

@QuietMisdreavus
Copy link
Copy Markdown
Contributor

Right, that's what i figured; a lot of what SymbolGraphGen is doing has to go around what the rest of the compiler is doing because it's a different paradigm. Thanks for the reply; this should be good to go.

@tshortli tshortli merged commit e9aa9ac into swiftlang:main May 8, 2026
6 checks passed
@tshortli tshortli deleted the expand-any-apple-os-in-symbol-graphs branch May 8, 2026 16:35
Copy link
Copy Markdown

@snprajwal snprajwal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with some comments that can be addressed later on. Thanks for working on this!

// CHECK-NEXT: "major": 26
// CHECK-NEXT: }
// CHECK-NEXT: },
// FIXME: [availability] watchOS introduction should be 11
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have a GitHub issue to track this? If not, could you please create one?

Comment thread lib/DriverTool/swift_symbolgraph_extract_main.cpp
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants