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 273 #294

Open
wants to merge 4 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@JLHwung
Copy link

commented May 2, 2019

This PR addresses issue and feature request in #273. I've made separate commit on this.

Although the owner suggested using https://github.com/mysticatea/regexpp, I decide not to use it for performance considerations -- There would be many regular expression in a mature codebase and we can not afford the extra regular expression parse + replace cycle only to find whether there is any escapable sequence.

The original escapeWithLowercase pattern should work good enough on regular expression under most situation. I have minimally modified the code to support slightly difference escape syntax between string literal and RegExp literal/objects.

Fix `escape-case` transforming `\c` in string literal
`\c` is not related to control characters in strings.
@futpib

This comment has been minimized.

Copy link
Collaborator

commented May 3, 2019

A slightly off-topic nitpick.

Although the owner suggested using mysticatea/regexpp, I decide not to use it for performance considerations -- There would be many regular expression in a mature codebase and we can not afford the extra regular expression parse + replace cycle only to find whether there is any escapable sequence.

Would it really be that slow? We could eventually cache the result and reuse it in other regexp-related rules (or maybe even across projects). Even if it were substantially slower, we may value correctness and maintainability over speed, especially for a linter (unless it was really slow).

Also a mature codebase with a lot of unique regular expressions sounds like a nightmare.

I'm not saying this PR should not be accepted, only that the argument against regexpp is not convincing.

@MrHen

This comment has been minimized.

Copy link
Contributor

commented May 3, 2019

I agree with @futpib. Performance issues should be addressed once they have been confirmed. Does the slower approach add 0.5 seconds for every 1,000 regex statements? 1 minute for every 10 regex statements?

@JLHwung

This comment has been minimized.

Copy link
Author

commented May 4, 2019

we may value correctness and maintainability over speed, especially for a linter (unless it was really slow).

Make sense, I can spare some time to try on the regexpp approach.

JLHwung added some commits May 7, 2019

@JLHwung JLHwung force-pushed the JLHwung:fix-273 branch from c739302 to 5e690ea May 8, 2019

@JLHwung

This comment has been minimized.

Copy link
Author

commented May 8, 2019

@futpib Upgraded the branch. The new lowercase detection approach is

  1. use regexpp to parse regular expression literal
  2. tap on onCharacterLeave handler, check if it is the first occurrence of escaped lowercase sequence
  3. report if invalid

The fixer approach is

  1. use regexpp to parse regular expression literal
  2. tap on onCharacterLeave handler, check if it is the first occurrence of lowercase sequence, record the position of escaped sequence in the regular expression
  3. replace the original escaped sequence with the one applied with the string escape fixer
  4. return the replaced string as the fixed regular expression literal
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.