Skip to content

Add ArgumentMatcher for matching call arguments to function parameters#3292

Open
loveucifer wants to merge 4 commits intomainfrom
feature/argument-matcher
Open

Add ArgumentMatcher for matching call arguments to function parameters#3292
loveucifer wants to merge 4 commits intomainfrom
feature/argument-matcher

Conversation

@loveucifer
Copy link
Member

@loveucifer loveucifer commented Mar 7, 2026

This adds a new ArgumentMatcher utility for matching the arguments of a function call to the parameters of a function declaration

This is just part of Phase 1 and it covers:

  • Labeled arguments (matched by external label)
  • Positional arguments (matched to _ parameters by position)
  • External vs. internal parameter names
  • Default parameters accepted (omission doesn't throw; synthesis deferred)

This is ultimately part of inline refactoring features discussed with @ahoppen over swift forums ( implementation plan can be found hereNotion

This adds a new ArgumentMatcher utility for matching the arguments of a
function call to the parameters of a function declaration

Phase 1 covers:
- Labeled arguments (matched by external label)
- Positional arguments (matched to `_` parameters by position)
- External vs. internal parameter names
- Default parameters accepted (omission doesn't throw; synthesis deferred)
@ahoppen
Copy link
Member

ahoppen commented Mar 8, 2026

@hamishknight @rintaro Would one of you be able to review this PR?

@loveucifer
Copy link
Member Author

its still in works as im reading through rust lsp for this and i think this will take a while but probably worth it

@ahoppen
Copy link
Member

ahoppen commented Mar 8, 2026

You’ll probably want to follow the implementation of argument matching in the compiler. #3046 and #3054 were efforts that started this in the past and that should have valuable information.

Copy link
Member

@rintaro rintaro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI, the compiler implementation lives here https://github.com/swiftlang/swift/blob/e25af44da87f1899a00dd6fa71fe26669cffb3bc/lib/Sema/CSSimplify.cpp#L999

We don't need to implement everything from the start, but we should eventually support the full functionality. With that in mind, it would be good to model the data types carefully upfront.

Sorry I don't have a concrete proposal yet, but please keep this in mind as you think through the design.


/// The expression at the call site that should be substituted for uses of
/// ``internalName`` in the function body.
public let argument: ExprSyntax
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, I'm not sure this should be modeled using Syntax types.
In many cases the element doesn't correspond to written syntax (e.g. default argument values or synthesized functions) in general. It may be simpler to represent this using dedicated data types instead.

call: FunctionCallExprSyntax,
parameters: FunctionParameterListSyntax
) throws -> [ArgumentMatch] {
let arguments = Array(call.arguments)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should take trailing closures into account

/// matched to the parameter list.
public static func match(
call: FunctionCallExprSyntax,
parameters: FunctionParameterListSyntax
Copy link
Member

@rintaro rintaro Mar 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'd also need to support subscript and calling closures eventually.


/// The expression at the call site that should be substituted for uses of
/// ``internalName`` in the function body.
public let argument: ExprSyntax
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering variadic parameters, the relationship between a parameter and arguments is not always 1:1. It can be 1:n.

@loveucifer
Copy link
Member Author

this was quite long , i will keep checking if thee is something i can fix though

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants