-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Parse unchecked
gracefully in operators
#61309
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
@CyrusNajmabadi, is this an example of an error you'd prefer to see done in binding, or is parsing ok for a misplaced token error?
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.
Or maybe we can use the existing
ERR_SyntaxError
error?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.
Unfortunately, this needs to be in the parser in the current form. The reason for that is that the syntax model itself is restrictive here. e.g. it requires a
SyntaxToken CheckedKeyword
. As such, we cannot fit the user code into the syntax model, and we have to make a correction at the parsing level, which means having a diagnostic at the parser level.My overall preference (if we had time/motivation) would be to relax the syntax model so that both of checked/unchecked were legal from the model's perspective, and then have it be the binder that checks and states taht 'unchecked' is not actually allowed semantically.
But this is also not a big deal for me (given how rare these will be) so keeping the status quo (and taking this PR) seems totally reasonable to me.
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 tried relaxing the syntax model to allow either
checked
orunchecked
keywords, but ran into an unfortunate issue with public APIs...The
syntax.xml
change updates the APIOperatorMemberCref(SyntaxToken operatorToken, CrefParameterListSyntax? parameters)
toOperatorMemberCrefSyntax OperatorMemberCref(SyntaxToken checkedKeyword, SyntaxToken operatorToken, CrefParameterListSyntax? parameters)
.But that conflicts with existing manually defined public API:
OperatorMemberCref(SyntaxToken operatorKeyword, SyntaxToken operatorToken, CrefParameterListSyntax? parameters)
.@333fred Given that, I think we should keep the parser-level handling.
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.
Yeah, we could likely only do this if we haven't publicly shipped the 'checked operator' work yet. if it isn't shipped, then we can revise. otehrwise, we're locked in.
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
checked operator
feature is still in preview. But the public API that is causing a conflict predates that (doesn't involvedchecked
at all). So I think we're stuck.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.
@333fred ptal