Code path segments start outside of a class and end in a class instance field initializer. #14317
Labels
archived due to age
This issue has been archived; please open a new issue for any further discussion
bug
ESLint is working incorrectly
experimental syntax
This change is related to experimental syntax (stage 3 or below)
repro:needed
Projects
Tell us about your environment
What parser are you using?
Example below uses
babel-eslint
; The issue is parser-independent, same holds for typescript-eslint.Please show your full configuration:
Configuration
These are the used dependencies:The example below is not concerned with any specific rule; a minimal configuration is included directly in the code snippet.
What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.
This is an excerpt from this repository with a full reproducible example. It defines a single rule that simply prints out all the node- and codePath-related events emitted by ESLint:
Command used to run the example (see Readme in the linked repo):
node index.js 2 # See linked repository for the full example
What did you expect to happen?
I expected that the initializer of the class field
p
is processed after theconstructor
is entered, and beforeconstructor
is exited. In particular, I expected that the control flow constructs inside of the initializer do not interfere with control flow constructs outside of the class. The expected sequence of events should look somewhat like this (the position of the steps in bold is crucial):marker_03
andmarker_04
...)What actually happened? Please copy-paste the actual, raw output from ESLint.
These are the events emitted by ESLint, indented for legibility, commented at the crucial points:
The problem is that the initializer of the property
p
is processed before theconstructor
is entered. Instead of modifying the control flow inside of the constructor, the ternary expression interferes with the code path segments1_1
, which shouldn't even be on the same codePath.Steps to reproduce this issue:
Using the linked repo with MCVE
npm install
node index.js 2 # Or "1" for another example
What I've attempted to solve the issue
I've attempted to modify the AST before the control flow analysis phase.
More specifically:
constructor
, if there was oneconstructor
, I attempted to find asuper(...)
-call within itconstructor
, I generated a synthetic one.super
-call (approximately as described here).This was partially successful (the blocks looked a bit better, the initializers did not interfere with code path segments outside of the constructor), but it caused some unexpected changes during execution of other rules.
Are you willing to submit a pull request to fix this bug?
Yes*
(* Assuming that the above approach has a chance of not leading to any unexpected consequences)
The text was updated successfully, but these errors were encountered: