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
Fix two opaque return type bugs #60044
Fix two opaque return type bugs #60044
Conversation
e3482a4
to
e766f95
Compare
// If we don't have substitutions, this is an opaque archetype from | ||
// another declaration being manipulated, and not an erasure of a | ||
// concrete type to an opaque type inside its defining declaration. | ||
if (!substitutions.empty()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there is a better way to check this unfortunately...
@swift-ci Please smoke test |
This cannot be represented in the ABI because we expect that the opaque return type can be instantiated from the generic arguments of its declaring context. Reconstructing type metadata for the DynamicSelfType would require opaque return type instantiation to also take the self *value*. Fixes rdar://72407668 / apple#56367
…tion Move the check where we insert UnderlyingToOpaqueExpr earlier in coerceToType(). Otherwise, returning a metatype or function type would attempt to perform a conversion instead of building a UnderlyingToOpaqueExpr. Fixes part of apple#60038.
e766f95
to
78e9af7
Compare
@swift-ci Please smoke test |
@swift-ci Please test source compatibility |
some
keyword in a closure type #64799