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

[Fix #7929] Accept frozen_string_literal anywhere in leading comment lines #7939

Merged
merged 1 commit into from May 8, 2020

Conversation

jeffcarbs
Copy link
Contributor

@jeffcarbs jeffcarbs commented May 7, 2020

Fixes #7929

The frozen_string_literal comment can exist anywhere in the "leading comment lines" (i.e. before the first line of ruby code). If it appears after any ruby code it is ignored which does not cause any errors but could cause the absence of an expected error which is bad.

The previous implementation was checking if this comment was one of the first three comments which had two issues:

  • The comments it was checking could be anywhere, even after ruby code
  • Since it was only checking three comments, it's possible that you can have an appropriate frozen_string_literal but this cop would show an error.

This commit updates the logic to look at all leading comment lines, which may be more or less than three depending on where the first non-comment token is.


Before submitting the PR make sure the following are checked:

  • 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.
  • Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
  • The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
  • Run bundle exec rake default. It executes all tests and RuboCop for itself, and generates the documentation.

…omment lines

The frozen_string_literal comment can exist anywhere in the
"leading comment lines" (i.e. before the first line of ruby
code). If it appears after any ruby code it is ignored which
does not cause an errors but could cause the absence of an
expected error which is bad.

The previous implementation was checking if this comment was
one of the first three comments which had two issues:
- The comments it was checking could be anywhere, even after
  ruby code
- Since it was only checking three comments, it's possible
  that you can have an appropriate frozen_string_literal but
  this cop would show an error.

This commit updates the logic to look at all leading comment
lines, which may be more or less than three depending on where
the first non-comment token is.

# Since we're only looking at the leading comments, a
# `frozen_string_literal` comment elsewhere in the code is invisible
# to this cop so the autocorrect won't remove it.
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 would be happy to take a stab at implementing this, but I'm hesitant since the autocorrect method takes a specific node and we'd have to update it to "correct" code elsewhere in the source outside of that node.

Copy link
Member

Choose a reason for hiding this comment

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

I think this case does not need to be taken care of. Because a frozen string magic comment written other than the reading comments may be an intended content in the source code comments.

Copy link
Member

@koic koic left a comment

Choose a reason for hiding this comment

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

This looks good 🌟

@koic koic merged commit c2f6f95 into rubocop:master May 8, 2020
@koic
Copy link
Member

koic commented May 8, 2020

Thank you!

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.

Bug in Style/FrozenStringLiteralComment where comment can exist anywhere in file
2 participants