Skip to content
  • Jeremy Evans's avatar
    aae8223c
    Dup splat array in certain cases where there is a block argument · aae8223c
    Jeremy Evans authored
    This makes:
    
    ```ruby
      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:
    
    ```ruby
      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:
    
    ```ruby
      args = Struct.new(:a).new([:x, :y])
      def args.to_a; a; end
      def args.to_proc; a.pop; ->{}; end
      foo(*args, &args)
      # calls foo with 1 argument (:x)
      # not 2 arguments (:x and :y)
    ```
    
    A perfect solution would require completely disabling the
    optimization.
    
    Fixes [Bug #16504]
    Fixes [Bug #16500]
    aae8223c
    Dup splat array in certain cases where there is a block argument
    Jeremy Evans authored
    This makes:
    
    ```ruby
      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:
    
    ```ruby
      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:
    
    ```ruby
      args = Struct.new(:a).new([:x, :y])
      def args.to_a; a; end
      def args.to_proc; a.pop; ->{}; end
      foo(*args, &args)
      # calls foo with 1 argument (:x)
      # not 2 arguments (:x and :y)
    ```
    
    A perfect solution would require completely disabling the
    optimization.
    
    Fixes [Bug #16504]
    Fixes [Bug #16500]
Loading