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
Remove unnecessary casting for record field set #41917
Remove unnecessary casting for record field set #41917
Changes from all commits
be6452b
2e0f804
9ce1b3b
d4d10ae
6dfae92
6551fb8
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.
When doing the
checkExpr
, we set theimpConversionExpr
at the same time. With this logic, what we did is we set it and then reset it with the use ofresetImpConversionExpr
. IMO, it is not correct, and we should avoid the setting ofimpConversionExpr
for scenarios which don't need.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.
The reason why I decided to do this was because
data.typeChecker.checkExpr
uses the expected type for doing 2 things in the end here,When it comes to optional field assignments for 1 it must treat expected type for a field type
T
asT?
and for 2 it must treat it as justT
. But since we are type checking theexpr
part of the assignment, which don't have information about what it is being used for currently, and there for we can't distinguish between these expected types. I think there are 2 ways to actually fix this,checkType
, or pass the informatio usingAnalyzerData
by giving a anther API to be used in case of optional field access similar tocheckExpr
. This would still means each expression node must do the right thing by either calling an appropriately modified version ofcheckType
or passing on this information tocheckType
by modifying the public API.I feel 2 is the "correct" solution but given the way our code is structured this means a very large modification. Option 1 (and setting and resetting the
implConversionExpr
) both require minimal changes but are "incorrect" in different ways. I am not sure which of these 3 possible options is the best. WDYT?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 we need
field != null
check? As this is afield based access
expression field cannot be null.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.
Added this because I got the field as null when trying to build the Ballerina langlib. Will investigate and create a issue for that.
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.
Can we get rid of this now?
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.
It seems a new regression has been introduced since #41998, while trying to desugar this query expression. Will try to find a simple reproducible case and make a separate issue
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.
This is caused by a preexisting bug in query de-sugar. Recent changes has surfaced it. Created #42479