-
Notifications
You must be signed in to change notification settings - Fork 10.4k
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
[SR-7380] KeyPath cannot infer type in [keyPath:] context #49928
Comments
@jckarter If unresolved member is used as an argument for keypath subscript, should it get contextual type from its base type? |
I'm interested in taking a look at this. @rudkx You said you'd looked at this before and might have some pointers for me? |
This is where the constraint system seems to get stuck: Score: 0 0 0 0 0 0 0 0 0 1 0
Type Variables:
$T0 as String @ locator@0x114841c00 [StringLiteral@7380.swift:1:1]
$T1 subtype_of_existential bindings={} @ locator@0x114841c90 [KeyPath@7380.swift:1:16]
$T2 [lvalue allowed] fully_bound subtype_of_existential involves_type_vars bindings={} @ locator@0x114841c90 [KeyPath@7380.swift:1:16]
$T3 subtype_of_existential involves_type_vars bindings={} @ locator@0x114841c90 [KeyPath@7380.swift:1:16]
$T4 subtype_of_existential involves_type_vars bindings={} @ locator@0x114841c90 [KeyPath@7380.swift:1:16]
$T5 as (keyPath: $T7) @ locator@0x114841ec0 [Subscript@7380.swift:1:6 -> subscript index]
$T6 [lvalue allowed] subtype_of_existential involves_type_vars bindings={} @ locator@0x114841ee0 [Subscript@7380.swift:1:6 -> subscript result]
$T7 subtype_of_existential involves_type_vars bindings={} @ locator@0x1148424f8 [Subscript@7380.swift:1:6 -> subscript member -> function argument]
$T8 [lvalue allowed] equivalent to $T6 @ locator@0x1148424f8 [Subscript@7380.swift:1:6 -> subscript member -> function argument]
$T9 subtype_of_existential involves_type_vars bindings={} @ locator@0x1148424f8 [Subscript@7380.swift:1:6 -> subscript member -> function argument]
Active Constraints:
Inactive Constraints:
@lvalue $T1[.count: value] == $T2 [[locator@0x114841d10 [KeyPath@7380.swift:1:16 -> key path component #​0]]];
$T2 equal $T3 [[locator@0x114841c90 [KeyPath@7380.swift:1:16]]];
$T4 arg conv $T7 [[locator@0x1148426d0 [Subscript@7380.swift:1:6 -> subscript index -> comparing call argument #​0 to parameter #​0]]];
$T4 key path from $T1 -> $T3 [[locator@0x114841c90 [KeyPath@7380.swift:1:16]]];
$T7 key path projecting String -> $T8 [[locator@0x114841f50 [Subscript@7380.swift:1:6 -> subscript member]]];
$T8 equal $T9 [[locator@0x114841f50 [Subscript@7380.swift:1:6 -> subscript member]]];
Resolved overloads:
selected overload set choice key path application root String The subscript has been resolved to key path application. The key path application won't simplify because the type of key path isn't known (the base type is, but the value type isn't). The key path constraint won't simplify because the base type isn't known. Even though these constraints are connected through I could use a pointer about where to go from here. I'm not sure how to get the key path constraint and key path application constraint to share information to resolve the member. |
I think that's what should happen, but I'm unsure where/how to do that. |
I think it should happen when we generate constraints in CSGen, detect that there is a contextual type requirement e.g. unresolved member and use type of base instead of generating new type variable. |
@mdiep, https://bugs.swift.org/browse/SR-5865 is the same issue. I'll leave it to you to decide which to resolve as a dup of the other, but it probably makes sense to keep this as the active bug since you've already added commentary here. |
Fixed by #17094 |
Environment
Swift 4.1
Additional Detail from JIRA
md5: dc04cd7b30a9a60b279e876915880f3e
is duplicated by:
Issue Description:
This code does not compile:
It gives the error “Type of expression is ambiguous without more context.” Adding an explicit type to the left of the dot fixes it:
However, with a trivial wrapping of the `[keyPath: …]` access in a func, the implicit type works:
Is this a bug?
May be related to SR-6740, but seems distinct.
The text was updated successfully, but these errors were encountered: