[Sema] Make typealiases in protocols available for nested type lookup. #2885
Conversation
This involved several complications, mostly making the distinction between typealiases whose definitions contain associated types and those which don't: - Only check final component of compound idents for existential-typeness, so that it is legal to refer to a nested typealias inside the existential. - New diagnosis for trying to use typealias which is an alias for an associated type outside of the defining protocol. - Add check on member lookup to omit typealiases to assoc types, similar to existing treatment of assoc types. - Added test.
|
@swift-ci Please test |
|
@DougGregor Would you mind taking a quick look at this? Thanks! |
|
@gregomni I have a set of changes I'm working on here -- take a look at slavapestov@358ff8f |
|
@slavapestov That rearrangement looks great! I don't think it conflicts with / directly intersects the changes here. |
|
Sounds good! One thing I noticed is that the current code breaks when the typealias names an associated type, but as an argument of a bound generic. Eg, protocol P { associatedtype A; typealias T = [A] } I'll have an updated version of my patch ready tomorrow. |
| // Substitute the base into the member's type. | ||
| if (Type memberType = substMemberTypeWithBase(dc->getParentModule(), | ||
| typeDecl, type, | ||
| /*isTypeReference=*/true)) { | ||
|
|
||
| // Similar to the associated type case, ignore typealiases containing | ||
| // associated types when looking into a non-protocol. |
There was a problem hiding this comment.
It might be clearer to factor out the entire predicate into its own method, because then in addition to comments you can rely on the method name to understand what's going on
What's in this pull request?
This involved a couple complications, mostly making the distinction between typealiases whose definitions contain associated types and those which don't:
This PR arises out of the conversation in this pull swiftlang/swift-evolution#321 where @lattner was surprised that this didn't already work (I was surprised too - oops.).
Also note that all of this is currently disabled by default and enabled by the -enable-protocol-typealiases flag (done in #2803).
Resolved bug number: (SR-)
Before merging this pull request to apple/swift repository:
Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
Validation Testing
Lint Testing
Note: Only members of the Apple organization can trigger swift-ci.