Skip to content

[AST] Special handling for existentials with superclass and marker pr… #71855

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 4 commits into from
Mar 8, 2024

Conversation

xedin
Copy link
Contributor

@xedin xedin commented Feb 23, 2024

…otocols

Even if protocol is not self-conforming it should be okay to produce a conformance based on superclass
if protocol bounds of the existential are all marker protocols.

Superclass concrete conformance is wrapped into an inherited conformance in such cases to
reference the existential.

@xedin
Copy link
Contributor Author

xedin commented Feb 27, 2024

@swift-ci please test

@xedin
Copy link
Contributor Author

xedin commented Feb 27, 2024

@swift-ci please test macOS platform

if (auto superclass = layout.explicitSuperclass) {
if (auto result =
lookupConformance(superclass, protocol, /*allowMissing=*/false)) {
if (protocol->isSpecificProtocol(KnownProtocolKind::Sendable) &&
Copy link
Contributor

Choose a reason for hiding this comment

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

Is the true branch reachable? It seems we only call this if !protocol->existentialConformsToSelf() but that would be false for Sendable

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I just moved this code over so I'm not sure.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I saw this in a couple other places I think, will investigate!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay, we do call this in two places where !protocol->existentialConformsToSelf() and later on in case when it is, so it would be reachable at leave in one spot.

@xedin xedin force-pushed the fix-sendable-keypath-conformance-issues branch 2 times, most recently from b7c6055 to 7526af5 Compare March 7, 2024 18:07
@xedin
Copy link
Contributor Author

xedin commented Mar 7, 2024

@swift-ci please test

xedin added 4 commits March 7, 2024 13:05
…otocols

Even if protocol is not self-conforming it should be okay to produce
a conformance based on superclass if protocol bounds of the existential
are all marker protocols.

Superclass concrete conformance is wrapped into an inherited conformance
in such cases to reference the existential.
@xedin xedin force-pushed the fix-sendable-keypath-conformance-issues branch from 7526af5 to 0ab7e12 Compare March 7, 2024 21:31
@xedin
Copy link
Contributor Author

xedin commented Mar 7, 2024

@swift-ci please test

@xedin xedin merged commit b17f0b5 into swiftlang:main Mar 8, 2024
xedin added a commit to xedin/swift that referenced this pull request Jun 4, 2024
…ngleTypeForFlatUniqueTypeRef`

The original check introduced by swiftlang#71855
is too broad. For concrete metadata we call the runtime demangler so
we need to strip off marker protocols when mangling that string and
`mangleTypeForReflection` already does that.
xedin added a commit to xedin/swift that referenced this pull request Jun 5, 2024
…ngleTypeForFlatUniqueTypeRef`

The original check introduced by swiftlang#71855
is too broad. For concrete metadata we call the runtime demangler so
we need to strip off marker protocols when mangling that string and
`mangleTypeForReflection` already does that.
xedin added a commit to xedin/swift that referenced this pull request Jun 5, 2024
…ngleTypeForFlatUniqueTypeRef`

The original check introduced by swiftlang#71855
is too broad. For concrete metadata we call the runtime demangler so
we need to strip off marker protocols when mangling that string and
`mangleTypeForReflection` already does that.
xedin added a commit to xedin/swift that referenced this pull request Jun 5, 2024
…ngleTypeForFlatUniqueTypeRef`

The original check introduced by swiftlang#71855
is too broad. For concrete metadata we call the runtime demangler so
we need to strip off marker protocols when mangling that string and
`mangleTypeForReflection` already does that.

(cherry picked from commit 5d243bd)
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