-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Diagnostics] Improve diagnostics for invalid type access on existential types. #60671
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
Conversation
typealias access on existential types by mentioning the base type in the error message.
existential type in expression context.
@swift-ci please smoke test |
@@ -188,6 +187,25 @@ Type TypeResolution::resolveDependentMemberType( | |||
|
|||
auto *concrete = ref->getBoundDecl(); | |||
|
|||
if (auto concreteBase = genericSig->getConcreteType(baseTy)) { | |||
bool hasUnboundOpener = !!getUnboundTypeOpener(); |
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.
Should this be !
?
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.
Nope, I want the value of getUnboundTypeOpener
as a bool
. This !!
pattern is used elsewhere in TypeCheckType.cpp on getUnboundTypeOpener
to do the same thing.
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.
Oh interesting! I didn’t know we had a !!
.
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 didn't either until I looked at the other call-sites of TypeChecker::isUnsupportedMemberTypeAccess
😄
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 didn’t know we had a
!!
Some time ago this pattern made me hang for a second too. It's just a double negation and equivalent to (bool)getUnboundTypeOpener()
in this context.
@swift-ci please smoke test |
This change improves the error message for invalid associated type and type alias access on a protocol or existential type, and fixes a case of missing diagnostics for invalid type access on a generic parameter that is same-type-constrained to an existential type.
Resolves: rdar://88092865