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
Mark Style/FrozenStringLiteralComment
as Safe
, but with unsafe auto-correction.
#8529
Conversation
2ccf43a
to
b352926
Compare
First of all thank you for opening a good question. In conclusion, I think this cop will be As far as I understand, the following could be
I think that On the other hand, it is about unsafe auto-correction (e.g.: If users want to safely correct will have to manually handcraft. In this case, users may change using safe navigation operator if needed. So, Anyway, I'm also interested in @bbatsov's opinion :-) Thank you! |
I'm sorry if I missed your point, but manually one can prefix all needed string literals in the source with a # before
str = 'hello'
str << ' world'
def name
'Marc-André'
end
# after
# frozen_string_literal: true
str = +'hello'
str << ' world'
def name
+'Marc-André'
end That is my whole point... |
Thank you for understanding the explanation! Surely both are On the other hand, I thought again about
It's difficult to say which is user-friendly definition of |
Btw, after our original conversation I've documented the safety definitions here https://docs.rubocop.org/rubocop/0.89/usage/auto_correct.html#safe-auto-correct I wouldn't make any changes that are not aligned with those (unless we also update the definition of safety).
I agree. |
CHANGELOG.md
Outdated
@@ -7,6 +7,7 @@ | |||
* [#8362](https://github.com/rubocop-hq/rubocop/issues/8362): Add numbers of correctable offenses to summary. ([@nguyenquangminh0711][]) | |||
* [#8513](https://github.com/rubocop-hq/rubocop/pull/8513): Clarify the ruby warning mentioned in the `Lint/ShadowingOuterLocalVariable` documentation. ([@chocolateboy][]) | |||
* [#8517](https://github.com/rubocop-hq/rubocop/pull/8517): Make `Style/HashTransformKeys` and `Style/HashTransformValues` aware of `to_h` with block. ([@eugeneius][]) | |||
* [#x](https://github.com/rubocop-hq/rubocop/pulls/x): Mark `Lint/FrozenStringLiteralComment` as `Safe`, but with unsafe auto-correction. ([@marcandre][]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you forgot to update the links. :-)
Ah... I overlooked this nice document. I understand the safety definition, thank you! |
b352926
to
947fda8
Compare
947fda8
to
11ea5e5
Compare
Follow rubocop/rubocop#8529 and rubocop#320. This PR changes the mark of `Rails/UniqBeforePluck` from `Safe: false` to `SafeAutoCorrect: false`. False positives to detection are not a concern. Only worry about incompatibilities with auto-correction. Below is an excerpt from the official document. > * Safe (true/false) - indicates whether the cop can yield false > positives (by design) or not. > > *SafeAutoCorrect (true/false) - indicates whether the auto-correct a cop > does is safe (equivalent) by design. If a cop is unsafe its auto-correct > automatically becomes unsafe as well. https://docs.rubocop.org/rubocop/0.89/usage/auto_correct.html#safe-auto-correct
Follow rubocop#320 and rubocop/rubocop#8529. This PR changes the mark of `Rails/UniqBeforePluck` from `Safe: false` to `SafeAutoCorrect: false`. False positives to detection are not a concern. Only worry about incompatibilities with auto-correction. Below is an excerpt from the official document. > * Safe (true/false) - indicates whether the cop can yield false > positives (by design) or not. > > * SafeAutoCorrect (true/false) - indicates whether the auto-correct a cop > does is safe (equivalent) by design. If a cop is unsafe its auto-correct > automatically becomes unsafe as well. https://docs.rubocop.org/rubocop/0.89/usage/auto_correct.html#safe-auto-correct
Note: This PR title appears be incorrect, it's |
Lint/FrozenStringLiteralComment
as Safe
, but with unsafe auto-correction.Style/FrozenStringLiteralComment
as Safe
, but with unsafe auto-correction.
Good catch @andyw8, Changelog & PR title fixed, thanks 👍 |
Follow rubocop#8529. `Style/MutableConstant` is the same as `Style/FrozenStringLiteralComment`, freezing object is unsafe auto-correction.
Follow #8529. `Style/MutableConstant` is the same as `Style/FrozenStringLiteralComment`, freezing object is unsafe auto-correction.
@bbatsov wrote:
I would propose a different definition. Unsafe for a cop means that it yields false positives and that's it. (e.g. "don't use
dig
with single argument" is unsafe, as it could be a custom method in a gem dependency and thus perfectly o.k. and without another alternative). TheLint/FrozenStringLiteral
cop is a good example where the fact that we can't reliably auto-correct a source doesn't mean it can't or shouldn't be done. Since any source can modified to have a frozen string literal comment, that all sources should be modified, and that the cop will always correctly detect if there is a frozen string literal comment, I believe this cop is safe, only its auto-correction is potentially unsafe.