SymbolGraphGen: Expand anyAppleOS availability in symbol graphs#88813
SymbolGraphGen: Expand anyAppleOS availability in symbol graphs#88813tshortli merged 3 commits intoswiftlang:mainfrom
Conversation
|
@swift-ci please smoke test |
13219d6 to
5018355
Compare
4b14113 to
329a723
Compare
329a723 to
10f5540
Compare
|
@swift-ci please test macOS |
10f5540 to
db97c29
Compare
|
@swift-ci please test |
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.
db97c29 to
d78b08a
Compare
|
@swift-ci please test |
|
@swift-ci please test macOS |
| // platform inferred from the -target. Include app extension availability, | ||
| // too. | ||
| Options.ActivePlatform = | ||
| platformForTriple(Target, /*enableAppExtensionRestrictions=*/true); |
There was a problem hiding this comment.
Thanks for adding support for application extensions as well, we were tracking this as a future improvement (rdar://175796455)
QuietMisdreavus
left a comment
There was a problem hiding this comment.
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.)
| static const PlatformKind ApplePlatforms[] = { | ||
| PlatformKind::macOS, | ||
| PlatformKind::iOS, | ||
| PlatformKind::watchOS, | ||
| PlatformKind::tvOS, | ||
| PlatformKind::visionOS, | ||
| }; |
There was a problem hiding this comment.
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?
|
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. |
|
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. |
snprajwal
left a comment
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Do we have a GitHub issue to track this? If not, could you please create one?
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, teachswift-symbolgraph-extractto optionally limit platform availability in the symbol graph output to just active platforms when the-active-platform-availability-onlyflag is specified.This PR also includes an NFC change to stop including headers like
SymbolGraphOptions.hinASTContext.hso that modifying them doesn't always involve a full rebuild of the compiler.Resolves rdar://174557919.