[CSSimplify] Open key path type before assignment to its record requirements #80081
Conversation
Previously key path type didn't have any requirements on their root and value types but now that they do, we need a dedicated place to perform an assignment and open/record all of the requirements.
…rements `Root` and `Value` generic parameters now have conformance requirements which we need to account for post-binding inference.
|
@swift-ci please test |
1 similar comment
|
@swift-ci please test |
| @@ -4675,6 +4675,12 @@ ConstraintSystem::matchTypesBindTypeVar( | |||
| : getTypeMatchFailure(locator); | |||
| } | |||
|
|
|||
| if (typeVar->getImpl().isKeyPathType()) { | |||
| return resolveKeyPath(typeVar, type, flags, locator) | |||
There was a problem hiding this comment.
Doing this in matchTypesBindTypeVar() seems wrong. Why can't you generate these constraints when the type variable is created?
There was a problem hiding this comment.
The type is created by inference, it's not possible to generate constraints then.
There was a problem hiding this comment.
The key paths are special in a way that we need to infer capability from the members in the chain before we can form the type.
There was a problem hiding this comment.
To elaborate more, when type variable is created there is no type for it. The type we get here is purely synthetic, formed by inference based on capabilities inferred from members referenced in a key path, which means that the type wasn't previously "opened" like in other places and has to be opened before it's assigned. I agree that this is unfortunate and we'd need a better way to express this but I don't see how we can do that without significant changes to inference.
… in key path context
…ypes in key path context
…h in key path context
|
@swift-ci please test |
RootandValuegeneric parameters now have conformance requirementswhich we need to account for post-binding inference.
Resolves: rdar://143161190