Skip to content

[6.2] AST: Stop diagnosing potentially unavailable declarations in unavailable contexts #80707

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

Conversation

tshortli
Copy link
Contributor

@tshortli tshortli commented Apr 10, 2025

  • Explanation: Potential unavailability of a declaration has always been diagnosed in contexts that do not have a sufficient platform introduction constraint, even when those contexts are also unavailable on the target platform. This behavior is overly strict, since the potential unavailability will never matter, but it's a longstanding quirk of availability checking. As a result, some source code has been written to work around this quirk by marking declarations as simultaneously unavailable and introduced for a given platform. When availability checking was refactored to be based on a constraint engine in AST/Sema: Continue adopting AvailabilityConstraint #79260, the compiler started effectively treating @available(macOS, unavailable, introduced: 15) as just @available(macOS, unavailable) because the introduction constraint was treated as lower priority and therefore superseded by the unavailability constraint. This caused a regression for the code that was written to work around the availability checker's strictness. The fix is to address this long standing issue and stop diagnosing potential unavailability in unavailable contexts.
  • Scope: Availability checking in regions of code that are marked unavailable for the target platform.
  • Issue/Radar: rdar://147945883
  • Original PR: AST: Stop diagnosing potentially unavailable declarations in unavailable contexts #80705
  • Risk: Medium. The main risk of this approach is source compatibility for regions of unavailable code. It's theoretically possible that restricting available declarations by introduction version in unavailable contexts is important to prevent ambiguities during overload resolution in some codebases. Source compatibility testing shows no regressions, though, and platform introduction based disambiguation has always been an unreliable technique since it doesn't work after the deployment target is raised.
  • Testing: New compiler tests.
  • Reviewer: @beccadax

@tshortli tshortli added 🍒 release cherry pick Flag: Release branch cherry picks swift 6.2 labels Apr 10, 2025
@tshortli
Copy link
Contributor Author

@swift-ci please test

@tshortli tshortli force-pushed the unavailable-and-introduced-6.2 branch from 4b2059c to 1cb5727 Compare April 10, 2025 21:48
@tshortli
Copy link
Contributor Author

@swift-ci please test

@tshortli tshortli changed the title [6.2] AST: Track platform unavailability and introduction as separate constraints [6.2] AST: Stop diagnosing potentially unavailable declarations in unavailable contexts Apr 10, 2025
@tshortli tshortli marked this pull request as ready for review April 10, 2025 22:51
@tshortli tshortli requested a review from a team as a code owner April 10, 2025 22:51
Copy link
Contributor

@nkcsgexi nkcsgexi left a comment

Choose a reason for hiding this comment

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

This is a fix to a recent regression so I consider it's proper to be cherry-picked to 6.2. Also, we could easily back out if we hit source compatibility issues given the affected code snippets are fairly identifiable.

…ble contexts.

Potential unavailability of a declaration has always been diagnosed in contexts
that do not have a sufficient platform introduction constraint, even when those
contexts are also unavailable on the target platform. This behavior is overly
strict, since the potential unavailability will never matter, but it's a
longstanding quirk of availability checking. As a result, some source code has
been written to work around this quirk by marking declarations as
simultaneously unavailable and introduced for a given platform:

```
@available(macOS, unavailable, introduced: 15)
func unavailableAndIntroducedInMacOS15() {
  // ... allowed to call functions introduced in macOS 15.
}
```

When availability checking was refactored to be based on a constraint engine in
swiftlang#79260, the compiler started effectively
treating `@available(macOS, unavailable, introduced: 15)` as just
`@available(macOS, unavailable)` because the introduction constraint was
treated as lower priority and therefore superseded by the unavailability
constraint. This caused a regression for the code that was written to work
around the availability checker's strictness.

We could try to match the behavior from previous releases, but it's actually
tricky to match the behavior well enough in the new availability checking
architecture to fully fix source compatibility. Consequently, it seems like the
best fix is actually to address this long standing issue and stop diagnosing
potential unavailability in unavailable contexts. The main risk of this
approach is source compatibility for regions of unavailable code. It's
theoretically possible that restricting available declarations by introduction
version in unavailable contexts is important to prevent ambiguities during
overload resolution in some codebases. If we find that is a problem that is too
prevalent, we may have to take a different approach.

Resolves rdar://147945883.
@tshortli tshortli force-pushed the unavailable-and-introduced-6.2 branch from 1cb5727 to 64fadaf Compare April 11, 2025 18:56
@tshortli
Copy link
Contributor Author

@swift-ci please test

@tshortli tshortli enabled auto-merge April 11, 2025 18:56
@tshortli tshortli merged commit bfe3fe7 into swiftlang:release/6.2 Apr 12, 2025
5 checks passed
@tshortli tshortli deleted the unavailable-and-introduced-6.2 branch April 12, 2025 15:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🍒 release cherry pick Flag: Release branch cherry picks swift 6.2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants