[FIX #4189] Lint/AmbiguousBlockAssociation cites unambiguous lambda p…

[smakagon]

Fixes problem reported in #4189.
With this fix the following code is ok for AmbiguousBlockAssociation cop:

scope :technical, -> { where(technical: true) }

Now AmbiguousBlockAssociation cop treats lambda properly.

[ivanovaleksey]

One more thing...

For the following code
expect(described_class.new.by_coordinates).to eq {}
I receive

Parenthesize the param eq {} to make sure that the block will be associated with the eq method call.

Is it expected behavior?

[smakagon]

@ivanovaleksey yes, i think that's expected behavior because we call method .to and pass two params eq and {}. Parser treats {} as a block.

[smakagon]

@ivanovaleksey It's expected behavior that cop adds offense, but I'm not sure about error message though.

[ivanovaleksey]

Yes, that is the case.

Parenthesize the param eq {} ...

Does it mean to write expect(described_class.new.by_coordinates).to (eq {})?

[smakagon]

@ivanovaleksey I've just checked your example and it returns the following message:

Parenthesize the param eq {} to make sure that the block will be associated with the eq method call.

Which is good. It means that your should add parentheses for (eq {}) to make sure that block {} will be associated with eq method, not with to.

[bbatsov]

This needs a changelog entry.

[ivanovaleksey]

@smakagon actually it should be
expect(described_class.new.by_coordinates).to eq({})

This way it doesn't produce offense.
But the question in the same: is it okay that one receives a message like this?

[Drenmi]

@ivanovaleksey: This cop is meaningless to run on RSpec files, because the DSL deliberately uses the constructs this cop is checking for. 🙂

[ivanovaleksey]

@Drenmi thanks, I see.
I just wanted to clarify that everything is fine with this fix.

[smakagon]

@bbatsov updated changelog. Thanks.

[shayani]

I updated my gem to 0.48.1 but I'm still having the same warning for my scope:
scope :by_local_assembly_id, ->(id) { where(local_assembly_id: id) }

[giangneolab]

@shayani me too

[janraasch]

The problem is present in v0.48.1 as can be seen from this comment. So I suppose the fix will be part of the next rubocop release.

[jonas054]

I want to add something for clarification.

@ivanovaleksey wrote:

Does it mean to write expect(described_class.new.by_coordinates).to (eq {})?

Yes, that what RuboCop wants you to write. It assumes that passing a block and not an empty hash is what you wanted. The fact that eq takes one parameter and no block is something that RuboCop doesn't know. A check for this could be implemented in rubocop-rspec, but OTOH rspec will tell you ArgumentError: wrong number of arguments (0 for 1) when you try to run the code.