Add RSpec.current_scope method to replace currently_executing_a_context_hook? and self.inspect hack

[odinhb]

fixes #2893

[pirj]

Nice.
Actually, now when I look at it, it seems to me there is yet another scope, but I don't have a good term to describe it.

RSpec.describe Thing, :type => :model do

  # scope: example_group, context: example group class
  fixtures :things
  things(:one) # BOOM
  let_it_be(:stuff) { ... }
  stuff # BOOM

  before(:context) do
    # scope: example_group_hook, context: example group instance?
    things(:one) # BOOM
    stuff # BOOM    
  end

  it "fixture method defined" do
    # scope: example, context: example group instance
    # same as inside `before(:example)` for the needs of this PR
    things(:one) # OK
    stuff # OK
  end
end

We need to differentiate between the latter two, is that correct?

[JonRowe]

The correct names for hooks are :example :context and :suite, they are aliased to :each and :all but are not the main names, so that should reflect that.

I also feel we shouldn't be restoring previous states but explicitly setting the state we are moving to, otherwise a bug will persist through that stack

[odinhb]

The correct names for hooks are :example :context and :suite, they are aliased to :each and :all but are not the main names, so that should reflect that.

I also feel we shouldn't be restoring previous states but explicitly setting the state we are moving to, otherwise a bug will persist through that stack

Fixed and fixed. Turns out the prev_scope thing was unnecessary anyway.

[odinhb]

Did another iteration on this and I'm starting to feel satisfied with the implementation. Let me know if I missed anything else.

[odinhb]

I'm having some real trouble with rubocop here. Pipeline says "74 files inspected, 1 offense detected", but my local install says "74 files inspected, 94 offenses detected". I can't figure out the difference between our setups.

[pirj]

Looks great!
A couple of cosmetic notes.

[pirj]

Ruby 2.7 on Windows failure is unrelated, fails in other builds, too:

An error occurred while loading spec_helper.
Failure/Error: require 'aruba/api'

TypeError:
  unable to resolve type 'intptr_t'
# ./vendor/bundle/ruby/2.7.0/gems/ffi-1.12.2-x64-mingw32/lib/ffi/types.rb:69:in `find_type'

ruby-head fails with RuboCop/psych arity mismatch, seems completely unrelated:

bin/rubocop lib
wrong number of arguments (given 5, expected 1)
/home/runner/.rubies/ruby-head/lib/ruby/3.1.0/psych.rb:323:in `safe_load'

PS JRuby 1.7 failure is unrelated, fails in other builds as well.

Otherwise looks green. @JonRowe, what do you think?

[odinhb]

Is there anything else you want me to do?

Should I fixup the fixup! Adjust feature title commit into Update features/metadata/current_scope.feature?

[pirj]

@odinhb No, it's all good. Thanks a lot for your contribution. 🙌

@JonRowe Do you want to take another look?

[pirj]

@odinhb CI is green. Would you like to send a PR against rspec-rails's main that would make use of this new method?
main tracks the ongoing development of 5.x of rspec-rails, and it's set to depend on 4.x rspec-core that would include this new method.
I suggest you to tweak those dependency declarations to point to this PR's branch.

That might be the last drop needed to convince @JonRowe

Good job!

[odinhb]

@odinhb CI is green. Would you like to send a PR against rspec-rails's main that would make use of this new method?

I can do that. I can't start until after the weekend however.

[pirj]

until after the weekend however

This is fine.
I was going to wrap up a few remaining things for 3.99 this weekend, and it may take a while to code review and bring them to a desired shape. There's still time before 4.0 is cut.

[pirj]

Thanks!

@JonRowe This is the only open PR I can think of that it makes sense to merge before we proceed with 4.0 release plan.

[JonRowe]

Some documentation changes mainly, and a request to remove a deprecation

Proposed changes accepted. Thanks!

[pirj]

All green. Since there were no objections to the approach, and all amendments were considered, I'll go ahead and merge.
I intend to cherry-pick this to 4-0-dev and also remove currently_executing_a_context_hook?. For 3.99 a deprecation warning has been added.

@odinhb Thanks for the contribution!