False negatives in 3 rules when right side of && expression is a literal

[btmills]

Tell us about your environment

• ESLint Version: 7.7.0
• Node Version: 14.9.0
• npm Version: 6.14.7

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, as well as the command that you used to run ESLint.

/* eslint constructor-super: "error",
   no-throw-literal: "error",
   prefer-promise-reject-errors: "error"
 */
let anything;

// If anything is a constructor, it'll be truthy, we'll evaluate the
// right side of the &&, and we'll extend 42.
class Subclass extends (anything && 42) {
    constructor() {
        super();
    }
}

// If anything is an Error instance, it'll be truthy, we'll evaluate
// the right side of the &&, and we'll throw 42.
throw anything && 42;

// If anything is an Error instance, it'll be truthy, we'll evaluate
// the right side of the &&, and we'll reject with 42.
Promise.reject(anything && 5);

Demo

What did you expect to happen?

We should report errors in each of the above cases. All three are looking for a specific type of truthy value from the expression. Because the expression uses &&, any possibly-valid value would evaluate to the right side of the expression, which would not be a valid value in these examples.

This was originally discovered in #13618 (comment). Because it relates to existing behavior that existed prior to that pull request, we decided to split it into its own issue that can be fixed after the pull request is merged. This bug is a false negative in the 3 rules above, and fixing it would cause them to report more errors. Does anyone object to fixing this in a semver-minor change as allowed by our semver policy?

The fix would update both astUtils.couldBeError() and constructor-super's isPossibleConstructor() to only check the right side of && LogicalExpressions.

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

No errors are reported.

Are you willing to submit a pull request to fix this bug?

Yes, if @mdjermanovic doesn't get to it first.

[mdjermanovic]

I support fixing this in a semver-minor change.