Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't spend CPU finding the same node twice #960

Merged
merged 2 commits into from Jul 15, 2020

Conversation

bquorning
Copy link
Collaborator

As mentioned in #955 (comment)


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).

@bquorning bquorning mentioned this pull request Jul 10, 2020
6 tasks
RuboCop::RSpec::Corrector::MoveNode.new(
node, corrector, processed_source
).move_before(first_node)
).move_before(sibling)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder does it change autocorrect with multiple offending nodes, or the first_offending_node was recalculated after each autocorrelation?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t think I understand your question. Could you add an example?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RSpec.describe User do
        let(:params) { foo } # first_offsending_node
        let(:bar) { baz } # sibling

        subject { described_class.new }
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Declare `subject` above any other `let` declarations.
      end

Previously it would always move before the first offending node. Now in each iteration, it would move before the current offending node. Unless those are re-evaluated. I added the test and it's not broken.
And the reason for this is that we break after the first offending node, so sibling and first_offending_node are always the same. I missed that detail in the review

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps the readability of the method could be improved as well

         def check_previous_nodes(node)
-          node.parent.each_child_node do |sibling|
-            if offending?(sibling)
-              msg = format(MSG, offending: sibling.method_name)
-              add_offense(node, message: msg) do |corrector|
-                autocorrect(corrector, node, sibling)
-              end
+          offending_node(node) do |offender|
+            msg = format(MSG, offending: offender.method_name)
+            add_offense(node, message: msg) do |corrector|
+              autocorrect(corrector, node, offender)
             end
-
-            break if offending?(sibling) || sibling.equal?(node)
           end
         end
 
+        def offending_node(node)
+          node.parent.each_child_node.find do |sibling|
+            break if sibling.equal?(node)
+
+            yield sibling if offending?(sibling)
+          end
+        end
+

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like where this is going.

I tried replacing the last block body with

break if sibling.equal?(node)
break unless offending?(sibling)

yield sibling

and all tests still pass. if feels wrong. Do we need another test case, or is it ok to rewrite yield sibling if offending?(sibling)?

Copy link
Member

@Darhazer Darhazer Jul 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be some def or any other ruby code actually that goes before the subject

Edit: I see @pirj actually already answered. Should read all my mails before replying

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fyi @pirj calling each_child_node(:block) fails for the spec containing let(:user, &args[:build_user]).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I remember, you can pass multiple node types, like each_child_node(:block, :blockpass)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried that but didn’t make it work :-)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, the block_pass is an argument, and the node itself is a send.

s(:send, nil, :let,
  s(:sym, :user),
  s(:block_pass,
    s(:send,
      s(:send, nil, :args), :[],
      s(:sym, :build_user))))

You can do each_child_node(:block, :send). Not sure if is worthy

Copy link
Member

@pirj pirj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please feel free to ignore my observation notes, they don't relate to the subject (no pun intended) directly.
I'll file a tech ticket - we can address separately.

Merge when you see fit, looks good.

def find_first_offending_node(node)
node.parent.children.find { |sibling| offending?(sibling) }
end

def in_spec_block?(node)
node.each_ancestor(:block).any? do |ancestor|
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Observation:
any? it feels weird. first should work just fine. Can't imagine subject(...) { } being defined in an iterator, neither I'm aware of any special syntax to wrap subject, e.g. isolated { subject(...) { } }. first should work fine for most cases.

RuboCop::RSpec::Corrector::MoveNode.new(
node, corrector, processed_source
).move_before(first_node)
).move_before(sibling)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it's break unless offending? doing a bad job. Shouldn't it be next?
Still, it's something worth adding a red spec. Maybe something like:

describe do
  def helper_method # `break unless offending?(sibling) would break here and skip subsequent offences
  end

  it { } # offence!

  subject(:lost_in_space) { ... }
end

RuboCop::RSpec::Corrector::MoveNode.new(
node, corrector, processed_source
).move_before(first_node)
).move_before(sibling)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

node.parent.each_child_node

👍

Observation:
Wondering if each_child_node accepts a type (each_child_node(:block)), we could narrow down our search to only let/hooks/examples.

RuboCop::RSpec::Corrector::MoveNode.new(
node, corrector, processed_source
).move_before(first_node)
).move_before(sibling)
end

def offending?(node)
let?(node) || hook?(node) || example?(node)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Observation:
Shouldn't || example_group?(node) be added here?
I can think of:

describe do
  describe do
    ...
  end

  subject(:i_am_offended_by_a_preceeding_example_group_where_i_am_a_full_fledged_subject) { ... }
end

@bquorning bquorning merged commit 5d4a1be into master Jul 15, 2020
@bquorning bquorning deleted the optimize-leading-subject branch July 15, 2020 14:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants