Skip to content

Preserve anonymous parameters in generated RBIs - #2687

Open
Morriar wants to merge 4 commits into
mainfrom
at/preserve-anonymous-parameters
Open

Preserve anonymous parameters in generated RBIs#2687
Morriar wants to merge 4 commits into
mainfrom
at/preserve-anonymous-parameters

Conversation

@Morriar

@Morriar Morriar commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

Ruby reflects anonymous splat, keyword splat, and block parameters using pseudo-names:

def foo(*, **, &); end

method(:foo).parameters
# => [[:rest, :*], [:keyrest, :**], [:block, :&]]

Tapioca was treating those names as invalid parameter names and replacing them with fallback names like _arg0, _arg1, and _arg2. That caused two issues:

  • Methods were generated with named parameters instead of preserving the original anonymous syntax.
  • RBS-translated signatures could lose parameter types because Sorbet keeps the signature types under the original names: "*", "**", and "&".

For example, this could generate invalid RBI like:

sig { params(_arg0: , _arg1: , _arg2: ).void }
def foo(*_arg0, **_arg1, &_arg2); end

This change preserves anonymous parameter names for signature lookup, while rendering them as anonymous RBI parameters:

sig { params("*": ::Integer, "**": ::String, "&": T.proc.void).void }
def foo(*, **, &); end

It also bumps the minimum rbi dependency to 0.4.1, since older versions don’t support anonymous RestParam, KwRestParam, and BlockParam nodes represented with nil names.

@Morriar
Morriar requested a review from a team as a code owner July 28, 2026 21:01
Comment thread lib/tapioca/gem/listeners/methods.rb Outdated
Comment on lines +131 to +134
anonymous_parameter = anonymous_parameter_name?(type, name)
name = fallback_arg_name unless anonymous_parameter || valid_parameter_name?(name)

[type, name]
[type, name, anonymous_parameter]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
anonymous_parameter = anonymous_parameter_name?(type, name)
name = fallback_arg_name unless anonymous_parameter || valid_parameter_name?(name)
[type, name]
[type, name, anonymous_parameter]
is_anonymous_parameter = anonymous_parameter_name?(type, name)
name = fallback_arg_name unless is_anonymous_parameter || valid_parameter_name?(name)
[type, name, is_anonymous_parameter]

Comment thread lib/tapioca/gem/listeners/methods.rb Outdated
)

sanitized_parameters.each do |type, name|
sanitized_parameters.each do |type, name, anonymous_parameter|

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
sanitized_parameters.each do |type, name, anonymous_parameter|
sanitized_parameters.each do |type, name, is_anonymous_parameter|

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Do we need to thread the 3rd parameter through like this?

Could we instead modify the definition of name above, where anonymous_parameter is first set?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

rc

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

We need to pass something because the method param needs to be generated with a nil name but the signature param lookup needs the "*" name.

I change the tuple to use both names instead of passing the anonymous flag 👍

Morriar added 4 commits July 28, 2026 17:36
Keep anonymous splat, keyword splat, and block parameter names for signature lookup while rendering them as anonymous RBI parameters.
@Morriar
Morriar force-pushed the at/preserve-anonymous-parameters branch from 3a3dbeb to 095ee15 Compare July 28, 2026 21:36
@Morriar Morriar self-assigned this Jul 28, 2026
@Morriar Morriar added the enhancement New feature or request label Jul 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants