Add keypath method and initializer syntax under an experimental feature flag keypathWithMethodMembers

[amritpan]

This accompanies the compiler implementation for Method and Initializer Keypaths which extends keypath usage to include references to methods and initializers:

struct S {
  static let millenium = 3
  var year = 2024
  init() {}
  init(val value: Int = 2024) { year = value }
  
  func add(this: Int) -> Int { this + this}
  func add(that: Int) -> Int { that + that }
  static func subtract(_ val: Int) -> Int { return millenium - val }
  nonisolated func nonisolatedNextYear() -> Int { return year + 1 }
  consuming func consume() { print(year) }

  subscript(index: Int) -> Int { return year + index }
}

let kp1: KeyPath<S, () -> S> = \S.Type.init
let kp2: KeyPath<S, S> = \S.Type.init()
let kp3: KeyPath<S, (Int) -> S> = \S.Type.init(val:)
let kp4: KeyPath<S, S> = \S.Type.init(val: 2025)
let kp5: KeyPath<S, (Int) -> Int> = \S.add(this:)
let kp6: KeyPath<S, Int> = \S.add(that: 1)
let kp7: KeyPath<S, Int> = \S.Type.subtract(1)
let kp8: KeyPath<S, Int> = \S.nonisolatedNextYear()
let kp9: KeyPath<S, Int> = \S.nonisolatedNextYear().signum()
let kp10: KeyPath<S, String> = \S.nonisolatedNextYear().description
let kp11: KeyPath<S, ()> = \S.consume()
let kp12: KeyPath<S, Int> = \S.Type.init()[1]

[ahoppen]

The implementation looks good to me. I have a few small comments inline.

[ahoppen]

Why is the left parenthesis optional? Wouldn’t we just have a normal member component if we don’t have parentheses?

[amritpan]

I modeled this after .funcCallExpr but you're right and I will make this non optional. @ahoppen I also have 2 related questions:

.keyPathPropertyComponent has a .genericArgumentClause but I don't see any examples of it being used in the tests. Do you happen to know when that is used? It seems like a generic on the root (eg: \Box<Int>.item) is already being handled by KeyPathExpr.

Is there a way to make .labeledExprList optional? I forgot to account for this - partially applied methods parse their method name and arg list into DeclReferenceExpr and do not have a LabeledExprList. I'm inclined to create a second node to handle this (eg: .keyPathPartiallyAppliedComponent).

[ahoppen]

.keyPathPropertyComponent has a .genericArgumentClause but I don't see any examples of it being used in the tests. Do you happen to know when that is used? It seems like a generic on the root (eg: \Box<Int>.item) is already being handled by KeyPathExpr.

I don’t think a generic clause is actually valid in key path properties and maybe we should remove it. @rintaro Can you think of a reason why KeyPathPropertyComponentSyntax should have a generic arguments clause?

Is there a way to make .labeledExprList optional? I forgot to account for this - partially applied methods parse their method name and arg list into DeclReferenceExpr and do not have a LabeledExprList. I'm inclined to create a second node to handle this (eg: .keyPathPartiallyAppliedComponent).

I’m not sure I understand. If there are no parentheses, we should be able to parse the component as a KeyPathPropertyComponentSyntax. If there are parentheses and no arguments, arguments can just be an empty list. And if there are arguments … then it doesn’t need to be optional.

[amritpan]

I’m not sure I understand. If there are no parentheses, we should be able to parse the component as a KeyPathPropertyComponentSyntax. If there are parentheses and no arguments, arguments can just be an empty list. And if there are arguments … then it doesn’t need to be optional.

Should partial arguments should also be KeyPathPropertyComponentSyntax? method(_:) and method(arg:) for unapplied keypath methods are being parsed as DeclReferenceExpr with DeclNameArgumentListSyntax arguments instead of LabeledExprList. I have pushed changes that reflect this, unsure if there are any ramifications of doing it this way, but the Swift and c++ parser outputs match.

[ahoppen]

Some suggestions for more test cases

• \Foo.method<Int>()
• \Foo.method<Int>(arg:)
• \Foo.method(_:) for unnamed arguments

[amritpan]

• \Foo.method<Int>()
• \Foo.method<Int>(arg:)

I'm getting an unable to round trip message for these 2 invalid test cases (and no diagnostics). How do I resolve this?