Skip to content

Handle forwarding parameters in parser - #578

Open
Morriar wants to merge 1 commit into
mainfrom
at/handle-forwarding-params
Open

Handle forwarding parameters in parser#578
Morriar wants to merge 1 commit into
mainfrom
at/handle-forwarding-params

Conversation

@Morriar

@Morriar Morriar commented Apr 2, 2026

Copy link
Copy Markdown
Contributor

Summary

Expand ... (ForwardingParameterNode) into *args, **kwargs, &block instead of crashing with an unexpected parameter error.

Based on #562 by @kddnewton — simplified the approach to avoid wrapping every case in arrays: just mapflat_map and a single new when branch.

Includes test for both def m1(...) and def m2(a, ...).

Closes #562

Expand `...` (ForwardingParameterNode) into `*args, **kwargs, &block`
instead of crashing with an unexpected parameter error.

Based on #562
@Morriar
Morriar requested a review from a team as a code owner April 2, 2026 22:06
@vinistock

Copy link
Copy Markdown
Member

I think the changes are fine, but I do want to confirm one aspect of this. There one minor difference before ... and the expansion, which is the fact that you cannot refer to specific parameter parts when using .... For example:

def foo(...)
  # there's no way to use forwarding parameters that isn't including all
  # of them. I can't print only the keyword ones or refer exclusively to the block
end

def bar(*args, **kwargs, &block)
  # Here, while equivalent at the call site (accepts any argument), I can refer
  # to the individual parameter parts
end

Is this something we need to be concerned about? Would it be better to have RBI print the forwarding parameter instead?

Morriar added a commit that referenced this pull request Jul 17, 2026
Ruby argument forwarding (...) is a distinct parameter form, and expanding it to *args, **kwargs, &block loses source fidelity. Model it explicitly so RBI parsing and printing round-trip forwarding methods.

Add RBI::ForwardingParam and wire it through parser, visitors, printers, and RBS output.
Skip add-sig templates for forwarding methods because Sorbet doesn't support signatures on argument forwarding.
Treat forwarding params as merge-compatible only with the same forwarding shape.

Closes #562.
Closes #578.

Signed-off-by: Alexandre Terrasa <alexandre.terrasa@shopify.com>
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