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

Support autocorrection on Performance/RedundantMatch when receiver is a Regexp literal #297

Merged
merged 1 commit into from Jul 27, 2022

Conversation

r7kamura
Copy link
Contributor

I found the following pattern is treated as an offense but not autocorrected, so tried to support it.

# bad
something if /regexp/.match(string)

# good
something if /regexp/ =~ string

Before submitting the PR make sure the following are checked:

  • The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
  • Wrote good commit messages.
  • Commit message starts with [Fix #issue-number] (if the related issue exists).
  • Feature branch is up-to-date with master (if not - rebase it).
  • Squashed related commits together.
  • Added tests.
  • Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
  • Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

end
end

private

def autocorrect(corrector, node)
# Regexp#match can take a second argument, but this cop doesn't
# register an offense in that case
Copy link
Member

Choose a reason for hiding this comment

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

Can you leave the comment to node.first_argument.regexp_type??

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Roger.
Actually, I don't fully understand why this comment is necessary here. Why does this comment mention the second argument? String#match may also take a second argument, so does it need a similar comment?

Copy link
Member

Choose a reason for hiding this comment

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

It just keeps the status quo for future maintenance. No text updates would be needed.

Comment on lines 56 to 57
# @param [RuboCop::AST::SendNode] node
# @return [Boolean]
Copy link
Member

@koic koic Jul 27, 2022

Choose a reason for hiding this comment

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

In fact, this type comment is unneeded :-)

Suggested change
# @param [RuboCop::AST::SendNode] node
# @return [Boolean]

@@ -111,4 +111,15 @@ def method(str)
^^^^^^^^^^^^^^^^^^ Use `=~` in places where the `MatchData` returned by `#match` will not be used.
RUBY
end

it 'autocorrects Regexp#match to Regexp#=~' do
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
it 'autocorrects Regexp#match to Regexp#=~' do
it 'registers an offense when receiver is a Regexp literal' do

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it's a good to change about minor wording, but doesn't this completely lose the nuance of autocorrect support?
Or should we prefer that the message be ignorant as to whether autocorrect is supported or not?

Copy link
Member

Choose a reason for hiding this comment

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

it 'registers an offense and corrects when receiver is a Regexp literal' do, WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It sounds good and much clear 👍

Comment on lines 116 to 119
expect_offense(<<~TEXT)
something if /regex/.match(str)
^^^^^^^^^^^^^^^^^^ Use `=~` in places where the `MatchData` returned by `#match` will not be used.
TEXT
Copy link
Member

Choose a reason for hiding this comment

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

nits:

Suggested change
expect_offense(<<~TEXT)
something if /regex/.match(str)
^^^^^^^^^^^^^^^^^^ Use `=~` in places where the `MatchData` returned by `#match` will not be used.
TEXT
expect_offense(<<~RUBY)
something if /regex/.match(str)
^^^^^^^^^^^^^^^^^^ Use `=~` in places where the `MatchData` returned by `#match` will not be used.
RUBY

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm wondering if it's not a good idea to describe something that is not Ruby code as being "RUBY".

Modern editors (e.g. Visual Studio Code) recognize this heredoc delimiter as a language name and do syntax highlighting, but this heredoc includes ^^^... , which is clearly not Ruby code and therefore it fails to parse

image

then syntax highlighting for the rest of code will be broken.

Copy link
Member

Choose a reason for hiding this comment

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

I understand what you want to say. However, I think it's better to adapt to it because RUBY is used by convention.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay, certainly it is more important thing.
Thanks for having the courage to point this out 👍

@r7kamura r7kamura changed the title Support autocorrection on Performance/RedundantMatch when receiver is a Regexp Support autocorrection on Performance/RedundantMatch when receiver is a Regexp literal Jul 27, 2022
@koic
Copy link
Member

koic commented Jul 27, 2022

This looks good to me. Can you squash your commits into one?

@koic koic merged commit c2bdc1a into rubocop:master Jul 27, 2022
@koic
Copy link
Member

koic commented Jul 27, 2022

Thanks!

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

2 participants