Navigation Menu

Skip to content
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

Closed
pcantrell opened this issue Apr 8, 2018 · 9 comments
Closed

[SR-7380] KeyPath cannot infer type in [keyPath:] context #49928

pcantrell opened this issue Apr 8, 2018 · 9 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself key paths Feature: key paths (both native and Objective-C) type checker Area → compiler: Semantic analysis

Comments

@pcantrell
Copy link

Previous ID SR-7380
Radar rdar://problem/34376681
Original Reporter @pcantrell
Type Bug
Status Resolved
Resolution Done
Environment

Swift 4.1

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, KeyPaths, TypeChecker
Assignee @mdiep
Priority Medium

md5: dc04cd7b30a9a60b279e876915880f3e

is duplicated by:

  • SR-5865 Key path expression is "ambiguous without more context"

Issue Description:

This code does not compile:

"str"[keyPath: \.count]

It gives the error “Type of expression is ambiguous without more context.” Adding an explicit type to the left of the dot fixes it:

"str"[keyPath: \String.count]

However, with a trivial wrapping of the `[keyPath: …]` access in a func, the implicit type works:

func applyKeyPath<T,U>(_ keyPath: KeyPath<T,U>, to val: T) -> U {
    return val[keyPath: keyPath]
}
applyKeyPath(\.count, to: "str")

Is this a bug?

May be related to SR-6740, but seems distinct.

@belkadan
Copy link
Contributor

belkadan commented Apr 9, 2018

@xedin?

@xedin
Copy link
Member

xedin commented Apr 10, 2018

@jckarter If unresolved member is used as an argument for keypath subscript, should it get contextual type from its base type?

@mdiep
Copy link
Contributor

mdiep commented Jun 5, 2018

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?

@mdiep
Copy link
Contributor

mdiep commented Jun 8, 2018

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 #&#8203;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 #&#8203;0 to parameter #&#8203;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 $T4 arg cone $T7, the solver can't connect them. checkTypeOfBinding explicitly disallows converting that constraint into an equivalence since both sides are a type variable.

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.

@xedin
Copy link
Member

xedin commented Jun 8, 2018

@mdiep I think contextual member should get a type from the base (so connect $T0 and $T1 through equality probably), but I'm not completely sure, that's why I asked @jckarter about that...

@mdiep
Copy link
Contributor

mdiep commented Jun 8, 2018

I think that's what should happen, but I'm unsure where/how to do that.

@xedin
Copy link
Member

xedin commented Jun 8, 2018

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.

@rudkx
Copy link
Member

rudkx commented Jun 11, 2018

@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.

@mdiep
Copy link
Contributor

mdiep commented Jun 13, 2018

Fixed by #17094

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself key paths Feature: key paths (both native and Objective-C) type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

5 participants