Fix top level logical assignment leak#40536
Conversation
|
Ci failed but not my fault. |
|
@typescript-bot pack this. |
|
Hey @Kingwl, I've packed this into an installable tgz. You can install it for testing by referencing it in your and then running There is also a playground for this build. |
|
Emmm.... It's better to merge before 4.1 IMO |
|
UUUP |
|
Emmmm.. Friendly Ping again |
|
Sorry. Are there anything else to do for this fix?.... |
sandersn
left a comment
There was a problem hiding this comment.
I don't understand why this is the correct fix.
| node = node.parent; | ||
| } | ||
| return !isStatementCondition(node) && | ||
| !isLogicalAssignmentExpression(node.parent) && |
There was a problem hiding this comment.
This function is called when node was a LogicalAssignmentOperator. But from the tests, I guess that the failing case was when node was a LogicalOperator and node.parent was a LogicalAssignmentOperator. I don't understand why the control flow doesn't get created when the parent LogicalAssignmentOperator is node.
Also, are there now more control flow nodes created for other nodes besides LogicalAssignmentOperators? I'll run the perf tests.
There was a problem hiding this comment.
Much later: I was wrong. It is called when node is a QuestionQuestionToken and node.parent is a LogicalAssignmentExpression. From the new test, when node is x in d ??= x ?? "string", and node.parent is ??=.
I guess the deleted line was added because ??= is a logical expression...but it's also an assignment expression.
|
@typescript-bot perf test this |
|
Heya @sandersn, I've started to run the perf test suite on this PR at 5582f6a. You can monitor the build here. Update: The results are in! |
|
@sandersn Here they are:Comparison Report - master..40536
System
Hosts
Scenarios
Developer Information: |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Sorry, I'm a little unsure. If I'm correct, Logical assignment operator will use the existed control flow for below code, but logical operator create new one to limit the control flow changes inside the expression. So The function |
|
That sounds like a more accurate name from my reading of the code too. But I still don't understand why the deleted code checks that |
|
We only check a node is a "top level logical expression" if the node is a logical expression. If a node is "top level", the parent node should not be an logical expression. Otherwise the parent node is the top level. Seems reasonable doesn't it?.😂 |
sandersn
left a comment
There was a problem hiding this comment.
Based on my understanding of control flow (which isn't great here), and the fact that this doesn't hurt performance in projects that don't use ??=, I think this is good to go.
| node = node.parent; | ||
| } | ||
| return !isStatementCondition(node) && | ||
| !isLogicalAssignmentExpression(node.parent) && |
There was a problem hiding this comment.
Much later: I was wrong. It is called when node is a QuestionQuestionToken and node.parent is a LogicalAssignmentExpression. From the new test, when node is x in d ??= x ?? "string", and node.parent is ??=.
I guess the deleted line was added because ??= is a logical expression...but it's also an assignment expression.
Fixes #40494
Fixes #41153