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: fix no-octal-escape false negatives after \0 #12079

Merged
merged 4 commits into from Sep 13, 2019
Merged

Update: fix no-octal-escape false negatives after \0 #12079

merged 4 commits into from Sep 13, 2019

Conversation

mdjermanovic
Copy link
Member

@mdjermanovic mdjermanovic commented Aug 9, 2019

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

[X] Bug fix

This is a small bug fix, but it can produce more warnings.

Tell us about your environment

  • ESLint Version: 6.1.0
  • Node Version: 10.16.0
  • npm Version: 6.9.0

What parser (default, Babel-ESLint, etc.) are you using?

default

Please show your full configuration:

Configuration
module.exports = {
  parserOptions: {
    ecmaVersion: 2015,
  },
};

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

/*eslint no-octal-escape: "error"*/

"\0 \1"

Demo link

What did you expect to happen?

1 error

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

No errors.

What changes did you make? (Give an overview)

Modified regex to not capture \0 that isn't followed by an octal digit. The previous code was handling \0 by capturing and not reporting, which is okay for the \0 but it missed the rest of the string.

Also added messageId, I guess it's preferred way now.

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

  • Regex validity and performance.
  • The whole conditional (!== "0") is removed as it is no longer needed, but I'm not sure am I missing something with the other part of it, which is also removed now: match[3] !== "undefined". How was that ever true?
  • I believe that \0 should be reported as octal when it's in \08 and \09, I'll open an issue.
  • prefer-template has the same bug (looks like it was copy & paste from this rule and then simplified as it's for test only there), I'll fix it in another PR.
  • quotes does not check these cases at all when converting from string to template literals. I'll fix it after the PR for prefer-template (as it will share something in astUtils).

@eslint-deprecated eslint-deprecated bot added the triage An ESLint team member will look at this issue soon label Aug 9, 2019
@mdjermanovic
Copy link
Member Author

The false negative could be confirmed this way:

Demo Link 1 - The rule doesn't warn on "\0 \1"

Demo link 2 - Parser reports \1 in "\0 \1" as "octal literal" when strict mode is on (the message is wrong, though)

Copy link
Contributor

@GrayedFox GrayedFox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, minor non-blocking style note

tests/lib/rules/no-octal-escape.js Outdated Show resolved Hide resolved
@platinumazure
Copy link
Member

I agree, but before changing all tests (including the already existing ones) I must first ask for confirmation that id + data would be preferable over full messages (perhaps one or two should stay to test the message itself).

The team may feel differently, but when I designed the messageId feature, the intention was to let the messages be declarative in the rules, but the actual content of the messages would not matter as much because the messages could be localized/translated or otherwise changed. So I at least have no problem with messageId+data in tests.

@kaicataldo kaicataldo added enhancement This change enhances an existing feature of ESLint evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion rule Relates to ESLint's core rules and removed triage An ESLint team member will look at this issue soon labels Aug 18, 2019
@mdjermanovic
Copy link
Member Author

It's changed to messageId+data now, only one full message is left.

Thank you @GrayedFox for the suggestion!

@GrayedFox
Copy link
Contributor

It's changed to messageId+data now, only one full message is left.

Thank you @GrayedFox for the suggestion!

No worries, happy to help!

@mdjermanovic mdjermanovic added the bug ESLint is working incorrectly label Sep 2, 2019
@mysticatea mysticatea added accepted There is consensus among the team that this change meets the criteria for inclusion and removed evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion labels Sep 12, 2019
Copy link
Member

@mysticatea mysticatea left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you!

Copy link
Member

@kaicataldo kaicataldo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion bug ESLint is working incorrectly enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants