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

Update: use regexpp's default ecmaVersion in no-control-regex #13969

Merged
merged 1 commit into from Jan 1, 2021

Conversation

@mdjermanovic
Copy link
Member

@mdjermanovic mdjermanovic commented Dec 30, 2020

Prerequisites checklist

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[x] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

Tell us about your environment

  • ESLint Version: v7.16.0
  • Node Version: v12.18.4
  • npm Version: v6.14.6

What parser (default, @babel/eslint-parser, @typescript-eslint/parser, etc.) are you using?

default

Please show your full configuration:

Configuration
module.exports = {
  parserOptions: {
    ecmaVersion: 2020
  }
};

What did you do? Please include the actual source code causing the issue.

Online Demo

/* eslint no-control-regex: error */

/(?<\u{1d49c}>.)\x1f/

What did you expect to happen?

1 error, since the regex is valid in ES2020 and there's an escape sequence for a control character.

When we flip the sequence and the group, the rule does report an error, as in this demo.

What actually happened? Please include the actual, raw output from ESLint.

no errors

What changes did you make? (Give an overview)

Changed the no-control-regex rule to use regexpp's default ecmaVersion (currently 2020), instead of the hard-coded 2018.

It's similar to #13968, but for this rule the change means more errors as there are fewer parsing errors (this rule reports control characters until the first parsing failure).

Is there anything you'd like reviewers to focus on?

  • This rule doesn't pass the "u" flag, so it doesn't report \u{1f} and there are also false negatives like /\u{0}*\x1f/u. I'll open an issue for that.
  • It's interesting that both rules that use regexpp.RegExpValidator had hard-coded ecmaVersion 2018, but neither of rules that use regexpp.RegExpParser did.
nzakas
nzakas approved these changes Jan 1, 2021
@mdjermanovic mdjermanovic merged commit 535fe47 into master Jan 1, 2021
13 checks passed
Loading
@mdjermanovic mdjermanovic deleted the nocontrolregex-ecmaversion branch Jan 1, 2021
@eslint-github-bot eslint-github-bot bot locked and limited conversation to collaborators Jul 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants