Fix each_with_index argument handling #807
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes #744 and cleans up a couple of related things discovered while down that rabbit hole.
The block
RubyEnumerable
creates to handleeach_with_index
was incorrectly assigned a fixed arity of two. When theeach
we passed this block to is implemented with acall
rather than ayield
, this arity was enforced. This resulted in wrapping zero or one arguments in an array (which is what leads to #744) or, in the case of more than two arguments, lopping off the extra arguments.This pull updates the
each_with_index
block to haveArity.OPTIONAL
, and fixes theEachWithIndex.call
logic around packaging up the arguments to handle all arities properly.Also noticed that
RubyEnumerator$EachWithIndex
needed precisely the same logic around argument packaging, and refactored it to use the fixedRubyEnumerable$EachWithIndex
. In particular, this fixes an issue whereRubyEnumerator$EachWithIndex
handled multiple arguments incorrectly (it always truncated down to the first arg).