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
Report diagnostic for
field
andvalue
identifiers in property accessors where the meaning would change as contextual keywords #73570Report diagnostic for
field
andvalue
identifiers in property accessors where the meaning would change as contextual keywords #73570Changes from 5 commits
ecfc6e2
b5be7dc
4f1a7ad
9e573b2
5d56677
56cb218
f07918e
9802677
e8613d5
0161a97
564a13e
48a1fd0
d418943
9b05920
d829a41
435a126
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.
TBH i find hte approach taken in this pr extremely surprising. It's not how i would have expected this to be done.
Instead, i would expect us to treat his how we treat query-keywords or the await-keyword. Specifically, the parser should enter into a new contextual parsing state when we enter into these specific contexts.
Within that appropriate context, we then have the following behavior:
I think we also need this for incremental parsing to work properly. If we reinterpret the statements from an accessor into a different context (or vice-versa), then we need to reparse since
field/value
will change from keywords to identifiers.--
TLDR: as a contextual keyword, this should work the same way as async/await and query-keywords.
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.
Note: i was able to get us additional bits on NodeFlags. So we can store this info there as well for incremental parsing purposes. A
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 context from the parser might help, but the diagnostic may need to be reported in binding since we only want a diagnostic when the identifier would bind differently as a keyword.
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.
my approach supports that. these would be identifiers whose contextual kind would either be 'nothing' (which means it's a legal usage of
field/value
as an identifier), or it has a contextual kind of SyntaxKind.FieldKeyword or SyntaxKind.ValueKeyword. IN that case, in binding you report a warning saying this will change meaning.basically, the parser has the core logic for figuring out if it's an identifier or keyword. if it's a true identifier, great, you get an identifier and everything works as normal. If it's contextual keyword, then in C# 13 you get a keyword and the new semantics. In C# 12 you get an identifier, marked as being a contextual keyword, and the binder warns you.
Note: i don't actually see why it as to be the binder that needs to care. Sicne C# 13 will have these rules set up at the syntactic level, it feels fine for the parser to warn here for me. But i'm fine with it beign the binder if you prefer 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.
I think what Chuck is getting at is that, for example, there's no problem with using identifier 'value' to reference the setter value parameter. The parsing will technically change from C# 12 to 13, but it will still refer to the same thing in its keyword form.
So in order to know whether to give diagnostics, compiler needs to know whether 'value' is referring to that parameter, or referring to something else such as a 'value' local declared in a nested function.
FWIW, in the case I just described, I feel ok with saying you did something really weird and you don't get to have this warning. It's the .01% case.
Maybe we should only warn for use of identifier 'field' in property accessors and just do it in the parser.
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.
my approach would work for this afaict. the node indicates the information needed by the binder to warn.
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.