lazy not accounted for in ChainArrayAllocation cop

[reedjosh1]

lazy in a chain should negate the ChainArrayAllocation cop.

Expected behavior

some_array.lazy.map(&:some_obj_method).reject(&:nil?).first

Should not trigger a perf cop since this is actually a very performant (at least not too aweful) way of getting the first non-nil result. lazy should negate the chain cop as it no longer is a performance issue.

Actual behavior

Cop triggers as follows:

[Performance/ChainArrayAllocation] [I]  Use unchained `map` and `reject!`(followed by `return array` if required) instead of chaining `map...reject`.

Steps to reproduce the problem

Run perf cops on above code snippet.

RuboCop version

$ grep cop Gemfile.lock
    rubocop (1.6.1)
      rubocop-ast (>= 1.2.0, < 2.0)
    rubocop-ast (1.4.1)
    rubocop-performance (1.9.1)
      rubocop (>= 0.90.0, < 2.0)
      rubocop-ast (>= 0.4.0)
    rubocop-rails (2.9.1)
      rubocop (>= 0.90.0, < 2.0)
    rubocop-rake (0.5.1)
      rubocop
    rubocop-rspec (2.1.0)
      rubocop (~> 1.0)
      rubocop-ast (>= 1.1.0)
      rubocop (>= 0.52)
  rubocop (= 1.6.1)
  rubocop-performance (= 1.9.1)
  rubocop-rails (= 2.9.1)
  rubocop-rake (= 0.5.1)
  rubocop-rspec (= 2.1.0)

[marcandre]

Indeed, looks like a bug.

BTW, lazy is typically much less performant than the non lazy version in practice...

Also not clear in your example why some_array.find(&:some_obj_method) isn't the way to go...

[reedjosh1]

Also not clear in your example why some_array.find(&:some_obj_method) isn't the way to go...

find returns the object for which some_obj_method is non-nil. I want the results of the method some_obj_method for the first that is non-nil.

BTW, lazy is typically much less performant than the non lazy version in practice...

This is true, I'm sure.

But, for most things the perf difference is small enough to justify the one-liner vs the 3-4 line equivalent. It is particularly so in my use case.

Also, thanks for the cool cop!

[marcandre]

🤦, of course.