Skip to content

AST: Add new implementation of getOpenedExistentialSignature() #76206

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

slavapestov
Copy link
Contributor

This new mechanism allows type variables to appear in the existential type. It will eventually replace the old variant that takes a parent generic signature.

@slavapestov slavapestov force-pushed the existential-signature-rework-part-1 branch from df4af5b to 56a279a Compare September 2, 2024 21:48
@slavapestov slavapestov marked this pull request as ready for review September 2, 2024 21:51
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov
Copy link
Contributor Author

@swift-ci Please test source compatibility

@slavapestov slavapestov force-pushed the existential-signature-rework-part-1 branch from 56a279a to 369a57e Compare September 2, 2024 23:11
@slavapestov slavapestov force-pushed the existential-signature-rework-part-1 branch from 369a57e to 39d77b8 Compare September 3, 2024 01:42
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov
Copy link
Contributor Author

@swift-ci Please test source compatibility

@slavapestov slavapestov merged commit ba585fd into swiftlang:main Sep 3, 2024
5 checks passed
// Specifically ignore parameterized protocols and existential
// metatypes because we can erase them to the upper bound.
if (type->is<ParameterizedProtocolType>() ||
type->is<ExistentialMetatypeType>()) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

@slavapestov I think we need to be more careful with this sort of loosening. The more sophisticated erasure we support, the harder it will be for everyone to get off of it once we come up with something better. The non-metatype case was never supported, so I think the same should hold for an existential metatype:

class C<T> {}
protocol P {
  associatedtype A

  func f() -> any P & C<A>
  func fMeta() -> any (P & C<A>).Type
}

do {
  let p: any P
  let _ = p.f() // error
  let _ = p.fMeta() // crash
}

The call to fMeta() used to miscompile and now crashes, so we can still make it an error.

Copy link
Collaborator

Choose a reason for hiding this comment

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

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.

2 participants