[prefer-const] does not account for side effect in default argument

[yoursunny]

• I have tried restarting my IDE and the issue persists.
• I have updated to the latest version of the packages.
• I have read the FAQ and my problem is not listed.

Repro

package.json

{
  "private": true,
  "dependencies": {
    "@typescript-eslint/eslint-plugin": "^4.14.0",
    "@typescript-eslint/parser": "^4.14.0",
    "eslint": "^7.18.0",
    "typescript": "^4.1.3"
  },
  "eslintConfig": {
    "parser": "@typescript-eslint/parser",
    "plugins": [
      "@typescript-eslint"
    ],
    "extends": [
      "eslint:recommended",
      "plugin:@typescript-eslint/recommended"
    ]
  }
}

input.ts

let n = 0;

export class C {
  constructor(public readonly x = ++n) {
  }
}

tsconfig.json

{
  "compilerOptions": {
    "strict": true,
    "target": "ES2019"
  },
  "files": [
    "input.ts"
  ]
}

Expected Result

./node_modules/.bin/eslint input.js should give no error.

Actual Result

$ ./node_modules/.bin/eslint input.ts

C:\Users\sunny\Documents\code\eslint-bug-prefer-const\input.ts
  1:5  error  'n' is never reassigned. Use 'const' instead  prefer-const

✖ 1 problem (1 error, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

If I use --fix, the let would be changed to const, and TypeScript will report compilation error.

Additional Info

Compiled input.js

let n = 0;
export class C {
    constructor(x = ++n) {
        this.x = x;
    }
}

./node_modules/.bin/eslint input.js gives no error.

Versions

package	version
@typescript-eslint/eslint-plugin	4.14.0
@typescript-eslint/parser	4.14.0
TypeScript	4.1.3
ESLint	7.18.0
node	15.5.1

This issue did not occur 3 days ago (2021-01-17). All of typescript-eslint, TypeScript, and ESLint had upgrades during this period of time. Downgrading typescript-eslint to 4.13.0 (but not downgrading other packages) seem to solve this problem. Thus, this is a regression.

[bradzacher]

Same cause as #2941, #2942, #2945, #2947, #2950

Was fixed in #2943

[yoursunny]

Thanks. I can confirm that this issue does not occur in 4.14.1-alpha.2 version.