Fix: false positive about ES2018 RegExp enhancements (fixes #9893) #10062
Conversation
This was referenced Mar 16, 2018
This was referenced Mar 16, 2018
This was referenced Mar 22, 2018
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
What is the purpose of this pull request? (put an "X" next to item)
[X] Bug fix (template)
Fixes #9893.
What changes did you make? (Give an overview)
This PR fixes false positives/negatives about ES2018 RegExp enhancements.
no-control-regex
... it didn't work if the platform doesn't support ES2018 natively. And I fixed some tests such as`var regex = ${/\\\x1f\\x1e/}`
since\\x1e
is not a control character. It's four characters\
x
1
e
, but the rule had reported it as a control character\x1e
.no-empty-character-class
... it didn't work a RegExp literal hass
flag.no-invalid-regexp
... This rule had super confusion. Native ES2018 support had changed the rule's behavior because the rule had depended on nativeRegExp
constructor. The rule had depended oncontext.parserOptions
andespree
, so it was confusing if it uses a custom parser. RegExp has many differences on syntax between withu
flag and withoutu
flag, but the rule didn't recognize it. I remove the access tocontext.parserOptions
, so the rule validates RegExp with the latest syntax always. I thinkallowConstructorFlags
option is no longer necessary. If the rule ignores flags which change syntax such asu
flag, the rule cannot validate RegExp syntax properly.no-unexpected-multiline
... it didn't work a RegExp literal hass
flag.no-useless-escape
... it had some false positives about Named Capturing Groups and Unicode Property Escapes.no-irregular-whitespace
... it hadnode.value instanceof RegExp
, but it doesn't work intentionally becausenode.value
can be null if the platform doesn't support ES2018 natively.Is there anything you'd like reviewers to focus on?
no-control-regex
rule reports\x0A
but doesn't report\n
. The original implementation looks to intend to report invisible characters. I wonder if I should remove the check of escape sequences from theno-control-regexp
rule.