Update: Fix && vs || short-circuiting false negatives (fixes #13634) (#…

…13769)

* 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.

* Use correct short-circuit term

Co-authored-by: Nicholas C. Zakas <nicholas@nczconsulting.com>

Co-authored-by: Nicholas C. Zakas <nicholas@nczconsulting.com>

lib/rules/constructor-super.js

@@ -79,6 +79,17 @@ function isPossibleConstructor(node) {
             return false;
 
         case "LogicalExpression":
+
+            /*
+             * 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.
+             */
+            if (node.operator === "&&") {
+                return isPossibleConstructor(node.right);
+            }
+
             return (
                 isPossibleConstructor(node.left) ||
                 isPossibleConstructor(node.right)

lib/rules/utils/ast-utils.js

@@ -1611,6 +1611,17 @@ module.exports = {
             }
 
             case "LogicalExpression":
+
+                /*
+                 * 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.
+                 */
+                if (node.operator === "&&") {
+                    return module.exports.couldBeError(node.right);
+                }
+
                 return module.exports.couldBeError(node.left) || module.exports.couldBeError(node.right);
 
             case "ConditionalExpression":

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'

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
         {

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 => {

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,