Add Style/RedundantRegexpEscape cop

[owst]

This cop checks for redundant escapes inside Regexp literals.

      # @example
      #   # bad
      #   %r{foo\/bar}
      #
      #   # good
      #   %r{foo/bar}
      #
      #   # good
      #   /foo\/bar/
      #
      #   # good
      #   %r/foo\/bar/
      #
      #   # bad
      #   /a\-b/
      #
      #   # good
      #   /a-b/
      #
      #   # bad
      #   /[\+\-]\d/
      #
      #   # good
      #   /[+\-]\d/

This would have been a good use of #7868 (which I really like the sound of @marcandre - 👍) - but instead I used the workaround he listed of "redoing the detection work" again.

---

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.

[jonas054]

I suggest this functionality be placed in a separate new cop. It's reasonable for a user to not care about which delimiters are used, and thus disable Style/RegexpLiteral, but still want to get rid of unnecessary escaping.

[jonas054]

offenses is the spelling we use.

[owst]

Thanks for the review @jonas054 and good suggestion for the separate cop - I've made the change, which allowed me to also catch a lot of other unnecessary escapes, when you have a chance, let me know what you think 👍

[jonas054]

This is much better! I had some questions and comments.

[jonas054]

I'm not sure why the space character is always allowed to escape. Is it when you use the x flag?

[owst]

Yes, exactly. I could add another explicit message that said "Unnecessary escape of space, when not using free-spacing (x) mode."?

[jonas054]

You can always put a dash at the beginning or end of a character class and not have to escape it, right? It would require more logic in the cop, though.

[owst]

Yes, that's true - it's similar to how ^ only needs to be escaped if it is the first character of a character class.

My two reasons for not flagging/removing such escapes is that it would involve more logic as you say, and make the resulting character classes slightly more "fragile" to changes over time - either by adding another character or by reordering the elements of the character class, e.g.:

[a-] => [a-b]
[-a] => [b-a]
[ab-] => [a-b]
[a^] => [^a]

would all change the meaning of the character class. The refactorings may not be common, but I think I fall down on allowing escapes of ^ and - even though they are technically redundant. What do you think? I can take a look at the implementation would be if you think it's worth flagging such cases.

[jonas054]

I'm not sure if the next version will be 0.85, or if it will be 1.0. @bbatsov knows.

[bbatsov]

Seems it will be 0.85. Too much development happening recently. I want to give @marcandre time to finish the things he has in progress.

[jonas054]

Looks like the file needs to be generated again, looking at the "version added".

[owst]

Oops, yes, good catch, I missed this after I merged master and bumped the VersionAdded you noted above - I'll regenerate now and can change again when @bbatsov advises about the next version number

[jonas054]

Both your remaining questions are about false negatives. Things we could warn about but don't. I think that's OK, and can be improved later. Everything looks good to me.

[bbatsov]

Great work!