Skip to content

AST: Refactor AvailableAttr representation to use AvailabilityDomain #78541

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 9 commits into from
Jan 11, 2025

Conversation

tshortli
Copy link
Contributor

@tshortli tshortli commented Jan 10, 2025

Replace the PlatformKind and PlatformAgnosticAvailabilityKind properties of AvailableAttr with AvailabilityDomain and AvailableAttr::Kind. This will allow @available attributes to model availability for arbitrary domains, instead of just a predefined set of platforms plus the swift and _PackageDescription domains. Since resolving the domain specified by an attribute may require performing a name lookup in the future, getCachedDomain() returns an optional even though currently the domain is always fully resolved during parsing.

This PR is mostly NFC, with two notable exceptions:

  • The ASTDumper output for AvailableAttr has been corrected and expanded.
  • Availability attribute inference has been improved to handle non-platform-specific availability more gracefully because it was more difficult to preserve the existing, buggy behavior. A new test covers a case that was previously poorly tested and generated bad implicit @available attributes but now generates correct ones.

AvailableAttr::Kind and AvailabilityDomain are designed to replace
PlatformAgnosticAvailabilityKind, allowing AvailableAttr to more flexibly model
availability for arbitrary domains. For now, the new constructor just
translates its inputs into inputs for the existing constructor. Once all of the
callers of the existing AvailableAttr constructor have been updated to use the
new constructor, the representation of AvailableAttr will be updated to store
the new properties.
The platform field now indicates whether the attribute applies universally, to
a specific platform, to the Swift language, or to package descriptions.
Additionally the output now reflects whether or not the attribute specifies
unconditional deprecation or unavailabity or is `noasync`.
It was difficult to preserve the existing, buggy behavior of availability
attribute inference with respect to attributes specifying availability for
non-platform-specific domains. Instead, this change improves attribute merging
by tracking every domain independently, and only merging attributes from the
same domain.
@tshortli tshortli force-pushed the available-attr-remodel branch from 1d47307 to c0e01dc Compare January 11, 2025 03:18
@tshortli
Copy link
Contributor Author

@swift-ci please test

@tshortli
Copy link
Contributor Author

@swift-ci please build toolchain macOS

@tshortli tshortli enabled auto-merge January 11, 2025 07:22
@tshortli tshortli merged commit 393ad98 into swiftlang:main Jan 11, 2025
5 of 6 checks passed
@tshortli tshortli deleted the available-attr-remodel branch January 11, 2025 17:10
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.

1 participant