Support `itblock` #2077

Earlopain · 2025-04-11T10:31:35Z

All cops that handle numblock now also handle itblock. itblock is relatively new and the required rubocop-ast version is required via RuboCop 1.75

Before submitting the PR make sure the following are checked:

Feature branch is up-to-date with master (if not - rebase it).
Squashed related commits together.
Added tests.
Updated documentation.
Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

Earlopain · 2025-04-11T10:33:16Z

lib/rubocop/cop/rspec/hooks_before_examples.rb

          check_hooks(node.body) if multiline_block?(node.body)
        end

-        alias on_numblock on_block


This had no effect, so I removed it. It relies on a previous block and then simply uses next_sibling together with any_block (which includes itblock). I only added tests to show it already works.

Earlopain · 2025-04-11T10:34:17Z

lib/rubocop/cop/rspec/mixin/metadata.rb

            on_metadata_arguments(metadata_arguments)
          end
        end
-        alias on_numblock on_block


This module is included in 4 cops and none have tests for numblocks. So I simply removed this one.

I don't think handling these blocks makes sense in context anyways and it was only added here because of the internal affairs cop

I think it would be helpful to have some guidelines on when to add numblock/itblock aliases, and when it does not. It's too easy to appease toe internal affairs cop and just add a useless alias.

In this case it's for describe/context. You could handle numblocks but what would taking a block argument even do for those functions? There are a few other cases like this that I can think of like prepend/include/extend that take a block but never any arguments.

I guess as long as the block actually takes an argument. If a use can write foo { |arg| } and have the code make sense, then the same with numblock/itblock should also be possible.

I recall we had a PR where we were adding aliases everywhere, and then we just disabled that cop, and decided not to merge the pr. I yet to see any missed offence caused by lack of those aliases to justify their addition.

I can see how that cop can be annoying. Personally I never use numblocks (and I think I'm not the only one, just doesn't look very nice) but I do actually write it.

Earlopain · 2025-04-11T10:35:15Z

rubocop-rspec.gemspec


  spec.add_dependency 'lint_roller', '~> 1.1'
-  spec.add_dependency 'rubocop', '~> 1.72', '>= 1.72.1'
+  spec.add_dependency 'rubocop', '~> 1.75'


1.75 transitively depends on rubocop-ast >= 1.43.0 which is good enough

Earlopain · 2025-04-11T10:38:20Z

I guess I should clarify: itblock is foo { it }, where it is the same as _1 for numblock. It's a separate node type.

spec/spec_helper.rb

Earlopain · 2025-04-11T10:40:57Z

Hm, coverage is reduced because when using the parser gem on_itblock will never get called (rather, its interpreted as a plain block node). Any tips on how to solve this?

pirj · 2025-04-11T11:45:27Z

spec/rubocop/cop/rspec/hook_argument_spec.rb

+
+    context 'when Ruby 3.4', :ruby34, unsupported_on: :parser do
+      it 'does not flag :example for hooks' do
+        expect_no_offenses(<<~RUBY)


Can you please change this to ‘it.run’ not to offend the other cop?

I copy-pasted the current numblock specs, will change these as well.

pirj · 2025-04-11T11:48:38Z

spec/rubocop/cop/rspec/hooks_before_examples_spec.rb

+      expect_offense(<<~RUBY)
+        RSpec.describe User do
+          it { is_expected.to be_after_around_hook }
+          around { it }


I wonder if this would work anyway without making a special case for an it-block? Looks like a regular no-args block call with an ‘it’ call inside. No surprise, this may or may not be an it-block, hard to tell.

Side note, how does Ruby knows ‘describe { it { foo } }’ is not an it-block?

By what I propose here to keep the spec, and attempt to remove special handling in the cop. Chances are it will work anyway.

Yup, that's what I did: #2077 (comment)

Side note, how does Ruby knows ‘describe { it { foo } }’ is not an it-block?

it with block had special considerations from ruby itself, it only points to the block argument when it doesn't take a block itself. https://bugs.ruby-lang.org/issues/18980

The following cases have been discussed:

it method, most famously in RSpec: You almost always pass a positional and/or block argument to RSpec's it, so the conflict is avoided with my proposal. You virtually never use a completely naked it

Earlopain · 2025-05-21T12:39:21Z

Coverage is no longer an issue (rubocop/rubocop#14119) but now there's a gnarly-looking ruby-head failure I'm 100% certain is not my fault (: (https://bugs.ruby-lang.org/issues/21357)

Earlopain · 2025-07-29T16:31:34Z

Friendly ping

CHANGELOG.md

pirj · 2025-09-15T21:50:44Z

Would it make sense to pivot this a bit and use on_any_block? Is this even a thing? Now all three different flavours of blocks are there, and you've added the ability to use any_block in Node Pattern and the Node#any_block_type? predicate method, but is there on_any_block?

Where is on_itblock from? I can see on_numblock defined along with on_block_pass and a regular on_block. But where is on_itblock coming from? I see this PR of yours, but don't quite get what's going on. Prism-related code in Parser? 🤔

Side note: is it correct to say that there are actually four, not three block types?

      it_block { do_something(it) }
      numbered_block { do_something(_1) }
      normal_block { |arg| do_something(arg) }
      block_pass(&do_something)

Does it affect this PR? We do want to support all types, including blockpass, no?

Earlopain · 2025-09-16T07:11:31Z

Could it make sense to pivot this a bit and use on_any_block? Is this even a thing?

No, that's not a thing. These "node groups" only exist when checking an individual node at the moment.

Where is on_itblock from?

It comes from here. There's some metaprogramming involved but in the end it results in the node being visited. The rest is in prism. It provides the native ruby ast for free and then it just needs to be translated and the builder needs to know about it too. Prism has its own copy of the parser builder to handle it, so you won't find that in parser itself.

Probably if parser itself would support itblock, you would find it somewhere in the code you linked.

Side note: is it correct to say that there are actually four, not three block types

I guess that's true but since that can never have a body is is not relevant when compared to the other 3 types.

pirj · 2025-09-16T08:22:16Z

Understood, thanks for detailed explanation.

not relevant when compared to the other 3 types

But some cop like “a blank line around hooks” may want to consider the blockpass form of hooks, too?

Is there a good reason why there is no on_any_block at least for those blocks with body? Would rubocop-rspec at least benefit from having it?
We can define it in our own code, and delegate from on_block/on_numpass/on_itblock.
Or do those cops that you’ve fixed need to handle those flavours of blocks differently?

Earlopain · 2025-09-16T08:52:53Z

But some cop like “a blank line around hooks” may want to consider the blockpass form of hooks, too?

Hm, yeah. I see. Yes, I think that may be the case. I usually see on_send with RESTRICT_ON_SEND used so you don't even have to really consider all the different block types but since everything is so dynamic here that makes it a but more difficult.

Sharing the implementation with on_block etc. is not feasable as they are quite different in shape.

Is there a good reason why there is no on_any_block at least for those blocks with body?

I guess nobody really wanted it yet. Usually you can get away with reusing the same implementation for on_block/on_numblock/on_itblock but it's not always the case. Right now I aliases it 6 times and 2 times it has its own distinct but somewhat similar implementation.

I had the same though a few times as well. In rubocop itself this also happens repeatedly so it wouldn't make much sense to just add it it rubocop-rspec I think. Same also for send/csend. I guess eventually I'd like this to just be handled via some InternalAffairs cop.

All cops that handle numblock now also handle itblock. `itblock` is relatively new and the required `rubocop-ast` version is required via RuboCop 1.75

Earlopain requested a review from a team as a code owner April 11, 2025 10:31

Earlopain commented Apr 11, 2025

View reviewed changes

spec/spec_helper.rb Outdated Show resolved Hide resolved

pirj reviewed Apr 11, 2025

View reviewed changes

Earlopain force-pushed the itblock-support branch from e4a4818 to 3279266 Compare April 11, 2025 14:54

Earlopain mentioned this pull request Apr 14, 2025

Consider prism in coverage results #2079

Closed

Earlopain force-pushed the itblock-support branch 2 times, most recently from ba0f9df to 89a75bf Compare May 21, 2025 12:36

Earlopain force-pushed the itblock-support branch from 89a75bf to 1dfb00c Compare May 23, 2025 06:28

bquorning approved these changes Jul 30, 2025

View reviewed changes

bquorning reviewed Jul 30, 2025

View reviewed changes

CHANGELOG.md Outdated Show resolved Hide resolved

Earlopain force-pushed the itblock-support branch from 1dfb00c to c34a0c1 Compare July 30, 2025 10:10

Earlopain force-pushed the itblock-support branch from c34a0c1 to 7142126 Compare September 16, 2025 07:26

Support itblock

c0e8f4d

All cops that handle numblock now also handle itblock. `itblock` is relatively new and the required `rubocop-ast` version is required via RuboCop 1.75

Earlopain force-pushed the itblock-support branch from 7142126 to c0e8f4d Compare September 16, 2025 10:04

Uh oh!

Support itblock #2077

Are you sure you want to change the base?

Support itblock #2077

Uh oh!

Conversation

Earlopain commented Apr 11, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Earlopain commented Apr 11, 2025

Uh oh!

Uh oh!

Earlopain commented Apr 11, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Earlopain commented May 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Earlopain commented Jul 29, 2025

Uh oh!

Uh oh!

pirj commented Sep 15, 2025

Uh oh!

Earlopain commented Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pirj commented Sep 16, 2025

Uh oh!

Earlopain commented Sep 16, 2025

Uh oh!

Uh oh!

Support `itblock` #2077

Support `itblock` #2077

Earlopain commented May 21, 2025 •

edited

Loading

Earlopain commented Sep 16, 2025 •

edited

Loading