From 2b951cbe895001aebced5b50adeea7cd1c0f64da Mon Sep 17 00:00:00 2001 From: Brandon Mills Date: Sun, 18 Oct 2020 00:57:26 -0400 Subject: [PATCH 1/2] Update: Fix && vs || short-circuiting false negatives (fixes #13634) When `constructor-super`, `no-throw-literal`, and `prefer-promise-reject-errors` are looking for plausible constructor or error values, they fail to consider the short-circuiting behavior differences between the `&&` and `||` operators. This results in a false negative where these rules allow `foo && 42` when that expression cannot be a constructor or error. If the left side is falsy, the expression short-circuits with the falsy value. If the left side is truthy, the result of the expression is the right side value. All three rules already report the right side value in isolation but currently incorrectly allow it when on the right side of an `&&` expression. When @mdjermanovic added support for logical assignment operators, we decided to ship with the corrected behavior for `&&=` by only checking the right side of the expression, accepting that treatment of `&&=` would be inconsistent with existing treatment of `&&`. This PR then fixes the `&&` treatment in what we believe can be a semver-minor bug fix. A future improvement could detect statically falsy values on the left side of `&&` expressions and report those as well. Such a change could also update the `||` treatment to ignore plausibly-(constructor|error) values on the right side if the left side is statically truthy but not plausibly a constructor or error, so `42 || foo` should fail. --- lib/rules/constructor-super.js | 11 +++++++++++ lib/rules/utils/ast-utils.js | 11 +++++++++++ tests/lib/rules/constructor-super.js | 8 +++++++- tests/lib/rules/no-throw-literal.js | 7 +++++++ tests/lib/rules/prefer-promise-reject-errors.js | 1 + tests/lib/rules/utils/ast-utils.js | 5 ++++- 6 files changed, 41 insertions(+), 2 deletions(-) diff --git a/lib/rules/constructor-super.js b/lib/rules/constructor-super.js index 8787fc569a4..5d428995409 100644 --- a/lib/rules/constructor-super.js +++ b/lib/rules/constructor-super.js @@ -79,6 +79,17 @@ function isPossibleConstructor(node) { return false; case "LogicalExpression": + + /* + * If the && operator shortcuts, the left side was falsy and therefore not a constructor, and if + * it doesn't shortcut, it takes the value from the right side, so the right side must always be a + * possible constructor. A future improvement could verify that the left side could be truthy by + * excluding falsy literals. + */ + if (node.operator === "&&") { + return isPossibleConstructor(node.right); + } + return ( isPossibleConstructor(node.left) || isPossibleConstructor(node.right) diff --git a/lib/rules/utils/ast-utils.js b/lib/rules/utils/ast-utils.js index fb8beb25211..80551e72502 100644 --- a/lib/rules/utils/ast-utils.js +++ b/lib/rules/utils/ast-utils.js @@ -1611,6 +1611,17 @@ module.exports = { } case "LogicalExpression": + + /* + * If the && operator shortcuts, the left side was falsy and therefore not an error, and if it + * doesn't shortcut, it takes the value from the right side, so the right side must always be + * a plausible error. A future improvement could verify that the left side could be truthy by + * excluding falsy literals. + */ + if (node.operator === "&&") { + return module.exports.couldBeError(node.right); + } + return module.exports.couldBeError(node.left) || module.exports.couldBeError(node.right); case "ConditionalExpression": diff --git a/tests/lib/rules/constructor-super.js b/tests/lib/rules/constructor-super.js index bfde6a85508..85e4471acc8 100644 --- a/tests/lib/rules/constructor-super.js +++ b/tests/lib/rules/constructor-super.js @@ -43,8 +43,10 @@ ruleTester.run("constructor-super", rule, { "class A extends (B ||= 5) { constructor() { super(); } }", "class A extends (B ??= 5) { constructor() { super(); } }", "class A extends (B || C) { constructor() { super(); } }", - "class A extends (B && 5) { constructor() { super(); } }", "class A extends (5 && B) { constructor() { super(); } }", + + // A future improvement could detect the left side as statically falsy, making this invalid. + "class A extends (false && B) { constructor() { super(); } }", "class A extends (B || 5) { constructor() { super(); } }", "class A extends (B ?? 5) { constructor() { super(); } }", @@ -126,6 +128,10 @@ ruleTester.run("constructor-super", rule, { code: "class A extends (B = 5) { constructor() { super(); } }", errors: [{ messageId: "badSuper", type: "CallExpression" }] }, + { + code: "class A extends (B && 5) { constructor() { super(); } }", + errors: [{ messageId: "badSuper", type: "CallExpression" }] + }, { // `B &&= 5` evaluates either to a falsy value of `B` (which, then, cannot be a constructor), or to '5' diff --git a/tests/lib/rules/no-throw-literal.js b/tests/lib/rules/no-throw-literal.js index 745044abe47..3855b58fdfb 100644 --- a/tests/lib/rules/no-throw-literal.js +++ b/tests/lib/rules/no-throw-literal.js @@ -152,6 +152,13 @@ ruleTester.run("no-throw-literal", rule, { type: "ThrowStatement" }] }, + { + code: "throw foo && 'literal'", // evaluates either to a falsy value of `foo` (which, then, cannot be an Error object), or to 'literal' + errors: [{ + messageId: "object", + type: "ThrowStatement" + }] + }, // ConditionalExpression { diff --git a/tests/lib/rules/prefer-promise-reject-errors.js b/tests/lib/rules/prefer-promise-reject-errors.js index 23e299bc983..b31ec33622b 100644 --- a/tests/lib/rules/prefer-promise-reject-errors.js +++ b/tests/lib/rules/prefer-promise-reject-errors.js @@ -117,6 +117,7 @@ ruleTester.run("prefer-promise-reject-errors", rule, { "Promise.reject(foo &= new Error())", // evaluates either to a falsy value of `foo` (which, then, cannot be an Error object), or to `5` + "Promise.reject(foo && 5)", "Promise.reject(foo &&= 5)" ].map(invalidCase => { diff --git a/tests/lib/rules/utils/ast-utils.js b/tests/lib/rules/utils/ast-utils.js index 8d60a11d70c..fb38dc9ccfb 100644 --- a/tests/lib/rules/utils/ast-utils.js +++ b/tests/lib/rules/utils/ast-utils.js @@ -1099,7 +1099,10 @@ describe("ast-utils", () => { "(1, 2, foo)": true, "1 && 2": false, "1 && foo": true, - "foo && 2": true, + "foo && 2": false, + + // A future improvement could detect the left side as statically falsy, making this false. + "false && foo": true, "foo &&= 2": false, "foo.bar ??= 2": true, "foo[bar] ||= 2": true, From a14b800a13b883675e1e9cbf7449f2211fc76485 Mon Sep 17 00:00:00 2001 From: Brandon Mills Date: Wed, 21 Oct 2020 23:28:14 -0400 Subject: [PATCH 2/2] Use correct short-circuit term Co-authored-by: Nicholas C. Zakas --- lib/rules/constructor-super.js | 4 ++-- lib/rules/utils/ast-utils.js | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/rules/constructor-super.js b/lib/rules/constructor-super.js index 5d428995409..dfec18fb65a 100644 --- a/lib/rules/constructor-super.js +++ b/lib/rules/constructor-super.js @@ -81,8 +81,8 @@ function isPossibleConstructor(node) { case "LogicalExpression": /* - * If the && operator shortcuts, the left side was falsy and therefore not a constructor, and if - * it doesn't shortcut, it takes the value from the right side, so the right side must always be a + * If the && operator short-circuits, the left side was falsy and therefore not a constructor, and if + * it doesn't short-circuit, it takes the value from the right side, so the right side must always be a * possible constructor. A future improvement could verify that the left side could be truthy by * excluding falsy literals. */ diff --git a/lib/rules/utils/ast-utils.js b/lib/rules/utils/ast-utils.js index 80551e72502..cff5a1ec693 100644 --- a/lib/rules/utils/ast-utils.js +++ b/lib/rules/utils/ast-utils.js @@ -1613,8 +1613,8 @@ module.exports = { case "LogicalExpression": /* - * If the && operator shortcuts, the left side was falsy and therefore not an error, and if it - * doesn't shortcut, it takes the value from the right side, so the right side must always be + * If the && operator short-circuits, the left side was falsy and therefore not an error, and if it + * doesn't short-circuit, it takes the value from the right side, so the right side must always be * a plausible error. A future improvement could verify that the left side could be truthy by * excluding falsy literals. */