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

amritpan · 2025-01-22T02:48:05Z

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 · 2025-01-22T18:40:13Z

CodeGeneration/Sources/SyntaxSupport/ExprNodes.swift

+      Child(
+        name: "leftParen",
+        kind: .token(choices: [.token(.leftParen)]),
+        isOptional: true
+      ),


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

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

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

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.

CodeGeneration/Sources/SyntaxSupport/ExprNodes.swift

Sources/SwiftParser/Expressions.swift

Tests/SwiftParserTest/ExpressionTests.swift

amritpan · 2025-02-04T23:06:00Z

Added additional tests to ensure Swift and c++ parsers match.

CodeGeneration/Sources/SyntaxSupport/ExprNodes.swift

Sources/SwiftParser/Expressions.swift

ahoppen · 2025-02-04T23:07:15Z

Sources/SwiftParser/Expressions.swift

+    while true {
+      let token = lookahead.peek().rawTokenKind
+      if token == .endOfFile || lookahead.atStartOfLine {
+        break
+      }
+      if token == .leftParen {
+        hasLParen = true
+      }
+      if token == .colon {
+        lookahead.consumeAnyToken()
+        // If there's a colon followed by a right parenthesis, it is
+        // a partial application and should be parsed as a property.
+        if lookahead.peek().rawTokenKind == .rightParen {
+          return false
+        }
+      }
+      if token == .rightParen {
+        hasRParen = true
+      }
+      lookahead.consumeAnyToken()
+    }
+    // If parentheses exist with no partial application pattern,
+    // parse as a key path method.
+    return hasLParen && hasRParen ? true : false


This seems problematic to me. I haven’t fully though it through but it has the potential for an unbounded lookahead, which could be very bad for parser performance and the use of consumeAnyToken to eat any uncovered token also seems like a pitfall to me.

What I would suggest is that in your actual parse* method, you call parseDottedExpressionSuffix outside of the if. That would parse any compound names, ie. unapplied function references. If we are at a parenthesis after that, continue parsing arguments for an applied key path reference. That way, you can also parse key paths like \Foo.t(a:)(2), mirroring the following valid Swift code

struct Foo { func t(a: Int) { self.t(a:)(2) } }

Or am I missing something with that approach?

This makes sense and I've updated the code to reflect this. For reasons I can't reproduce now, parseDottedExpressionSuffix did not work for me initially and so I wrote this new method. Regardless it works now. All good things to know about Lookahead as well. Thank you!

ahoppen

That looks great and is much simpler as well. Just two minor comments, everything else is great.

Sources/SwiftParser/Expressions.swift

Tests/SwiftParserTest/ExpressionTests.swift

Release Notes/602.md

ahoppen

Looks good to me 🚀

ahoppen · 2025-02-06T01:43:58Z

@swift-ci Please test

amritpan · 2025-02-06T21:04:43Z

Not sure why this test is failing - is it due to my imports in Expressions.swift?

ahoppen · 2025-02-06T21:39:46Z

Oh, I just didn’t test it with your PR in the compiler repo. Let’s try again.

swiftlang/swift#78823

@swift-ci Please test

ahoppen · 2025-02-06T22:29:27Z

Looks like you need to rebase this PR + re-generate the sources to adjust it for #2926.

amritpan · 2025-02-07T00:00:12Z

Rebased and regenerated, but running into this failure locally:

./swift-syntax-dev-utils local-pr-precheck
Building for debugging...
[1/1] Write swift-version--58304C5D6DBC2206.txt
Build of product 'swift-syntax-dev-utils' complete! (0.14s)
** Running code generation **
** Building target SwiftSyntax-all **
Building for debugging...
[55/55] Emitting module SwiftSyntaxBuilder
Build of target: 'SwiftSyntax-all' complete! (9.33s)
** Building target Examples-all **
Building for debugging...
error: couldn't build /.../swift-project/swift-syntax/Examples/.build/arm64-apple-macosx/debug/SwiftSyntax.build/sources because of missing inputs: /.../swift-project/swift-syntax/Sources/SwiftSyntax/Raw/RawSyntaxArena.swift, /.../swift-project/swift-syntax/Sources/SwiftSyntax/ArenaAllocatedBuffer.swift

ahoppen · 2025-02-07T01:20:34Z

Could you try if deleting Examples/.build fixes the issue you’re seeing locally?

ahoppen · 2025-02-07T01:20:49Z

swiftlang/swift#78823

@swift-ci Please test

ahoppen · 2025-02-07T02:10:26Z

swiftlang/swift#78823

@swift-ci Please test

amritpan · 2025-02-07T21:36:55Z

Yes, deleting Examples/.build fixed the issue locally.

ahoppen · 2025-02-08T00:15:28Z

Sorry, looks like you picked a bad time for your PR right now as you’re racing with @rintaro’s refactorings. Can you rebase + re-generate once more to pick up #2926?

amritpan · 2025-02-08T00:36:57Z

Yes, rebased and regenerated!

amritpan requested review from ahoppen and bnbarham as code owners January 22, 2025 02:48

ahoppen reviewed Jan 22, 2025

View reviewed changes

amritpan mentioned this pull request Jan 22, 2025

[Sema/SILGen/IRGen] Implement method & initializer keypaths. swiftlang/swift#78823

Open

amritpan force-pushed the method-keypaths branch from e0c6ccb to 7762c01 Compare January 30, 2025 20:06

amritpan requested a review from ahoppen January 30, 2025 20:39

amritpan force-pushed the method-keypaths branch 2 times, most recently from dfa57bf to dd259f6 Compare February 4, 2025 23:05

ahoppen reviewed Feb 4, 2025

View reviewed changes

amritpan force-pushed the method-keypaths branch 4 times, most recently from 6cf481b to 6790783 Compare February 5, 2025 23:06

amritpan requested a review from ahoppen February 5, 2025 23:06

ahoppen reviewed Feb 6, 2025

View reviewed changes

Sources/SwiftParser/Expressions.swift Outdated Show resolved Hide resolved

Tests/SwiftParserTest/ExpressionTests.swift Outdated Show resolved Hide resolved

Release Notes/602.md Outdated Show resolved Hide resolved

amritpan force-pushed the method-keypaths branch from 6790783 to fa3596e Compare February 6, 2025 01:31

amritpan requested a review from ahoppen February 6, 2025 01:32

ahoppen approved these changes Feb 6, 2025

View reviewed changes

amritpan force-pushed the method-keypaths branch from fa3596e to 5c3310a Compare February 6, 2025 23:57

amritpan requested a review from ahoppen February 7, 2025 00:00

amritpan force-pushed the method-keypaths branch from 5c3310a to e0e888e Compare February 8, 2025 00:35

amritpan added 3 commits February 7, 2025 16:36

Add experimental flag and keyPathMethodComponent node.

13c17fa

Add supporting code.

082e3c6

Parse method and initializer keypaths.

fa70433

amritpan force-pushed the method-keypaths branch from e0e888e to fa70433 Compare February 8, 2025 00:36

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

amritpan commented Jan 22, 2025 •

edited

Loading

ahoppen left a comment

ahoppen Jan 22, 2025

amritpan Jan 28, 2025

ahoppen Jan 29, 2025

amritpan Jan 30, 2025

amritpan commented Feb 4, 2025

ahoppen Feb 4, 2025

amritpan Feb 5, 2025

ahoppen left a comment

ahoppen left a comment

ahoppen commented Feb 6, 2025

amritpan commented Feb 6, 2025

ahoppen commented Feb 6, 2025

ahoppen commented Feb 6, 2025

amritpan commented Feb 7, 2025

ahoppen commented Feb 7, 2025

ahoppen commented Feb 7, 2025

ahoppen commented Feb 7, 2025

amritpan commented Feb 7, 2025

ahoppen commented Feb 8, 2025

amritpan commented Feb 8, 2025

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

Are you sure you want to change the base?

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

Conversation

amritpan commented Jan 22, 2025 • edited Loading

ahoppen left a comment

Choose a reason for hiding this comment

ahoppen Jan 22, 2025

Choose a reason for hiding this comment

amritpan Jan 28, 2025

Choose a reason for hiding this comment

ahoppen Jan 29, 2025

Choose a reason for hiding this comment

amritpan Jan 30, 2025

Choose a reason for hiding this comment

amritpan commented Feb 4, 2025

ahoppen Feb 4, 2025

Choose a reason for hiding this comment

amritpan Feb 5, 2025

Choose a reason for hiding this comment

ahoppen left a comment

Choose a reason for hiding this comment

ahoppen left a comment

Choose a reason for hiding this comment

ahoppen commented Feb 6, 2025

amritpan commented Feb 6, 2025

ahoppen commented Feb 6, 2025

ahoppen commented Feb 6, 2025

amritpan commented Feb 7, 2025

ahoppen commented Feb 7, 2025

ahoppen commented Feb 7, 2025

ahoppen commented Feb 7, 2025

amritpan commented Feb 7, 2025

ahoppen commented Feb 8, 2025

amritpan commented Feb 8, 2025

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

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

amritpan commented Jan 22, 2025 •

edited

Loading