Skip to content

[SymbolGraphGen] add flags to filter platforms out of availability metadata #80778

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

Merged
merged 6 commits into from
Apr 14, 2025

Conversation

QuietMisdreavus
Copy link
Contributor

Resolves rdar://144379124

This PR adds two new flags to swift-frontend and two counterpart flags to swift-symbolgraph-extract, to control the platforms added to availability metadata in symbol graphs.

  • -symbol-graph-availability-platforms (swift-frontend) and -availability-platforms (swift-symbolgraph-extract) set an allow-list of platform names to emit the symbol graph. The capitalization needs to match the domains emitted in the symbol graph (e.g. Swift, iOS, Windows, OpenBSD, etc). An empty string can be passed to this option to filter out all platform-specific availability information.
  • -symbol-graph-block-availability-platforms (swift-frontend) and -block-availability-platforms (swift-symbolgraph-extract) do the inverse: They set a deny-list of platform names.

None of these options will filter out "unconditional" availability, like @available(*, deprecated) or anything else defined on the * domain.

In addition, this PR updates the --build-stdlib-docs and --preview-stdlib-docs commands in build-script to set an allow-list containing only Swift, to clean up the availability information for local previews.

@QuietMisdreavus
Copy link
Contributor Author

@swift-ci Please smoke test

Copy link
Contributor

@d-ronnqvist d-ronnqvist 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 to me.

I would maybe find the allow-list flag clearer if it included "allowed" or "filter" or such somewhere in the flag name. However, the flag is hidden from help, so I don't think it matters much.

Copy link

@anferbui anferbui left a comment

Choose a reason for hiding this comment

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

Looks great, left a small comment on the help documentation re: the capitalisation!

@@ -1774,6 +1774,16 @@ def symbol_graph_minimum_access_level: Separate<["-"], "symbol-graph-minimum-acc
HelpText<"Include symbols with this access level or more when emitting a symbol graph">,
MetaVarName<"<level>">;

def symbol_graph_availability_platforms: Separate<["-"], "symbol-graph-availability-platforms">,
Flags<[FrontendOption, NoInteractiveOption, SupplementaryOutput, HelpHidden]>,
HelpText<"Restrict availability metadata to the given platforms, e.g. 'macOS,swift'">,

Choose a reason for hiding this comment

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

Since the casing matters here, should this example be Swift?

Suggested change
HelpText<"Restrict availability metadata to the given platforms, e.g. 'macOS,swift'">,
HelpText<"Restrict availability metadata to the given platforms, e.g. 'macOS,Swift'">,

Should we also mention here about the capitalization needing to match the domains emitted in the symbol graph?


def symbol_graph_block_availability_platforms: Separate<["-"], "symbol-graph-block-availability-platforms">,
Flags<[FrontendOption, NoInteractiveOption, SupplementaryOutput, HelpHidden]>,
HelpText<"Remove the given platforms from symbol graph availability metadata, e.g. 'macOS,swift'">,

Choose a reason for hiding this comment

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

Same comment here

@@ -1788,6 +1798,16 @@ def omit_extension_block_symbols: Flag<["-"], "omit-extension-block-symbols">,
NoInteractiveOption, SupplementaryOutput, HelpHidden]>,
HelpText<"Directly associate members and conformances with the extended nominal when generating symbol graphs instead of emitting 'swift.extension' symbols for extensions to external types">;

def availability_platforms: Separate<["-"], "availability-platforms">,
Flags<[SwiftSymbolGraphExtractOption]>,
HelpText<"Restrict availability metadata to the given platforms, e.g. 'macOS,swift'">,

Choose a reason for hiding this comment

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

Same comment here


def block_availability_platforms: Separate<["-"], "block-availability-platforms">,
Flags<[SwiftSymbolGraphExtractOption]>,
HelpText<"Remove the given platforms from symbol graph availability metadata, e.g. 'macOS,swift'">,

Choose a reason for hiding this comment

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

Same comment here

@QuietMisdreavus
Copy link
Contributor Author

I would maybe find the allow-list flag clearer if it included "allowed" or "filter" or such somewhere in the flag name.

I think this makes sense. I didn't include "allow" or similar in the flag name to begin with because in my head it conflict with the behavior of "restrict everything else", but maybe having the dichotomy of "allow" versus "block" will make that clearer. I can go ahead and add that.

@QuietMisdreavus
Copy link
Contributor Author

@swift-ci Please smoke test

@QuietMisdreavus QuietMisdreavus enabled auto-merge (squash) April 14, 2025 17:10
@QuietMisdreavus
Copy link
Contributor Author

@swift-ci Please smoke test macOS

@QuietMisdreavus QuietMisdreavus merged commit 41120da into main Apr 14, 2025
3 checks passed
@QuietMisdreavus QuietMisdreavus deleted the vgm/sgf-platform-filter branch April 14, 2025 22:20
QuietMisdreavus added a commit that referenced this pull request Apr 14, 2025
…tadata (#80778)

* add option to filter availability metadata in symbol graphs

* filter out platform-specific availability in the stdlib docs

rdar://144379124
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.

3 participants