Dup splat array in certain cases where there is a block argument
This makes:
args=[1,2,->{}];foo(*args,&args.pop)
call foo with 1, 2, and the lambda, in addition to passing the lambda as a block. This is different from the previous behavior, which passed the lambda as a block but not as a regular argument, which goes against the expected left-to-right evaluation order.
This is how Ruby already compiled arguments if using leading arguments, trailing arguments, or keywords in the same call.
This works by disabling the optimization that skipped duplicating the array during the splat (splatarray instruction argument switches from false to true). In the above example, the splat call duplicates the array. I've tested and cases where a local variable or symbol are used do not duplicate the array, so I don't expect this to decrease the performance of most Ruby programs. However, programs such as:
foo(*args,&bar)
could see a decrease in performance, if bar is a method call and not a local variable.
This is not a perfect solution, there are ways to get around this:
args=Struct.new(:a).new([:x,:y])defargs.to_a;a;enddefargs.to_proc;a.pop;->{};endfoo(*args,&args)# calls foo with 1 argument (:x)# not 2 arguments (:x and :y)
A perfect solution would require completely disabling the optimization.
Dup splat array in certain cases where there is a block argument
This makes:
call
foowith 1, 2, and the lambda, in addition to passing thelambda as a block. This is different from the previous behavior,
which passed the lambda as a block but not as a regular argument,
which goes against the expected left-to-right evaluation order.
This is how Ruby already compiled arguments if using leading
arguments, trailing arguments, or keywords in the same call.
This works by disabling the optimization that skipped duplicating
the array during the splat (splatarray instruction argument
switches from false to true). In the above example, the splat
call duplicates the array. I've tested and cases where a
local variable or symbol are used do not duplicate the array,
so I don't expect this to decrease the performance of most Ruby
programs. However, programs such as:
could see a decrease in performance, if
baris a method calland not a local variable.
This is not a perfect solution, there are ways to get around
this:
A perfect solution would require completely disabling the
optimization.
Fixes [Bug #16504]
Fixes [Bug #16500]