Skip to content

AST: Type-check @available attributes before synthesizing CaseIterable #79423

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 1 commit into from
Feb 17, 2025

Conversation

tshortli
Copy link
Contributor

@tshortli tshortli commented Feb 16, 2025

An AvailableAttr written in source with an unrecognized availability domain is now only marked invalid after type-checking the attribute. This resulted in a regression where CaseIterable synthesis was blocked incorrectly under the following very narrow circumstances:

  1. Every @available attribute on the elements of the enum is invalid.
  2. The module is being emitted and lazy type-checking is enabled.
  3. The enum is public and the only top-level declaration in the file.

Type-checking the attribute was delayed just enough that it would not be considered invalid by the time the CaseIterable conformance was being synthesized, resulting in a spurious error.

There were zero tests exercising CaseIterable synthesis for enums with elements that have availability requirements, so I added some.

Resolves rdar://144897917.

…able`.

An `AvailableAttr` written in source with an unrecognized availability domain
is now only marked invalid after type-checking the attribute. This resulted in a
regression where `CaseIterable` synthesis was blocked incorrectly under the
following very narrow circumstances:

1. Every `@available` attribute on the elements of the enum is invalid.
2. The module is being emitted and lazy type-checking is enabled.
3. The enum is public and the only top-level declaration in the file.

Type-checking the attribute was delayed just enough that it would not be
considered invalid by the type the `CaseIterable` conformance was being
synthesized, resulting in a spurious error.

There were zero tests exercising `CaseIterable` synthesis for enums with
elements that have availability requirements, so I added some.

Resolves rdar://144897917.
@tshortli
Copy link
Contributor Author

@swift-ci please test

@tshortli tshortli enabled auto-merge February 16, 2025 20:22
@tshortli tshortli merged commit 9020533 into swiftlang:main Feb 17, 2025
4 of 5 checks passed
@tshortli tshortli deleted the case-iterable-invalid-available branch February 17, 2025 02:36
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