Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Support condition always true in prefix unary expression #60068
base: main
Are you sure you want to change the base?
[WIP] Support condition always true in prefix unary expression #60068
Changes from all commits
7942777
41eb788
72c3c8b
5eb8478
1274b62
9630147
16ae8dc
8f8b45c
70b70fb
fcb0c21
7a14b9d
4e47c53
5099e88
75f941d
de99724
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another thing to consider (and probably add a test) is that we can have an expression that flips between the negative and positive case, if we have nested negation expressions, e.g.:
if (a && !(b || !c)) ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah 🙈
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there's really any special handling needed here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this was a bug before? It's an optimisation to not need to call
checkExpression
to get thetype
and use the providedcondType
, if the location still matched the providedcondExpr
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we call
isSymbolUsedInConditionBody
withlocation
instead ofcondExpr
, in the first case?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For some reason without this it wouldn't detect
if (!something)
, but still detectif (!something.else)
. Didn't dig much into why yetThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it probably should be
location
and before was a potential bug?For the
inverted
case andif (!someVar)
we need to pass in the resolvedsomeVar
not!someVar
so that it passesisIdentifier(expr)
and does the// If the test was a simple identifier, the above check is sufficient
check.
Otherwise it's treating it as a nested object, which will fail