-
Notifications
You must be signed in to change notification settings - Fork 4.1k
Extended Keyword Parsing to cover member lookup expressions. #29233
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
Conversation
…ee if it is a qualifier token. If it is then treat the keyword as an identifier (with an attached diagnostic) thus considering it member lookup expression. This allows Interpolation String to "correctly" parse this form as an expression, thus the rest is parsed as part of the string interpolation and not treat the expression as text.
225815c
to
577c6f0
Compare
@@ -9,7 +9,7 @@ Imports InternalSyntaxFactory = Microsoft.CodeAnalysis.VisualBasic.Syntax.Intern | |||
|
|||
Namespace Microsoft.CodeAnalysis.VisualBasic.Syntax.InternalSyntax | |||
|
|||
Friend Partial Class Parser | |||
Partial Friend Class 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.
Please revert
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.
@@ -46,7 +46,8 @@ Namespace Microsoft.CodeAnalysis.VisualBasic.Syntax.InternalSyntax | |||
' bool BailIfFirstTokenRejected // bail (return NULL) if the first token isn't a valid expression-starter, rather than reporting an error or setting ErrorInConstruct | |||
Private Function ParseExpressionCore( | |||
Optional pendingPrecedence As OperatorPrecedence = OperatorPrecedence.PrecedenceNone, | |||
Optional bailIfFirstTokenRejected As Boolean = False | |||
Optional bailIfFirstTokenRejected As Boolean = False, | |||
Optional PrevTerm As ExpressionSyntax = Nothing |
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.
Please use camelCased names.
@@ -10,10 +10,10 @@ Imports InternalSyntaxFactory = Microsoft.CodeAnalysis.VisualBasic.Syntax.Intern | |||
|
|||
Namespace Microsoft.CodeAnalysis.VisualBasic.Syntax.InternalSyntax | |||
|
|||
Friend Partial Class Parser | |||
Partial Friend Class 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.
Please revert.
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.
See Issue #27893
This PR does not follow our coding style in pretty much every change. Please correct this. |
Else | ||
MissingExpression: |
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.
a goto here seems unnecessary. why not just replace the else with an "End If"?
result.AssertTheseDiagnostics( | ||
<expected> | ||
BC30183: Keyword is not valid as an identifier. | ||
Return $"{End.ToString()})" |
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 have a lot more tests than this? we'll need tests of keywords in many different areas followed by any allowable delimiter. We should also have specific tree and diagnostics tests
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 also affects far more than interpolated strings. i would expect a lot of statement/expression parsing tests.
+ Revert inadvertent changes + Use camelCase + Remove GoTo by using nested `If Then` rather that `Else If`
End If | ||
End If | ||
|
||
End If |
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.
extra newline unnecessary. though you can potentially put a comment there saying it is intentional that you are falling through.
If nextToken.Kind = SyntaxKind.DotToken OrElse nextToken.Kind = SyntaxKind.QuestionToken Then | ||
Dim keywordAsIdentifier = ParseSimpleNameExpressionAllowingKeywordAndTypeArguments() | ||
keywordAsIdentifier = ReportSyntaxError(keywordAsIdentifier, ERRID.ERR_InvalidUseOfKeyword) | ||
Dim _InvocationExpression_ = ParseExpressionCore(prevTerm:=keywordAsIdentifier) |
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.
Foo is not our naming pattern for locals.
Dim keywordAsIdentifier = ParseSimpleNameExpressionAllowingKeywordAndTypeArguments() | ||
keywordAsIdentifier = ReportSyntaxError(keywordAsIdentifier, ERRID.ERR_InvalidUseOfKeyword) | ||
Dim _InvocationExpression_ = ParseExpressionCore(prevTerm:=keywordAsIdentifier) | ||
If _InvocationExpression_.Kind = SyntaxKind.InvocationExpression Then |
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 are you only allowing invocation expressions. this won't help if you did something like $"{End.Prop}"
@@ -332,4 +332,4 @@ Namespace Microsoft.CodeAnalysis.VisualBasic.Syntax.InternalSyntax | |||
|
|||
End Class | |||
|
|||
End Namespace | |||
End Namespace |
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.
please undo this.
+ Revert inadvertent changes + Additional unit tests + Use `prevTerm` when constructing `ConditionalAccessExpression`
@AdamSpeight2008 Please do not 'format document' in the compiler codebase. If/when the compiler wants to format things, they would do it as an entirely independent PR. |
@CyrusNajmabadi Formatting changes are partially due to Issue #27893. (WIP Fix #27943) |
@AdamSpeight2008 Your change is unrelated to interpolated string parsing. I would keep around the tests you have. But you need more general tests showing a variety of keywords followed by delimiters in a variety of different circumstances. I would check with other compiler devs to see waht else they would want. If this was C# i know it would be good to have tests that validate the tree shape. a-la: roslyn/src/Compilers/CSharp/Test/Syntax/Parsing/AsyncParsingTests.cs Lines 42 to 49 in 4cd7d5e
But i don't know if VB has anything equivalent. We'd likely also want some semantic and IOperation tests to make sure this doesn't cause anything downstream to crash. |
Closing as this PR has gotten stale at this point. |
Fix for #29231
Extend the parsing for keywords, to look ahead at the next token to ee if it is a qualifier token.
If it is then treat the keyword as an identifier (with an attached diagnostic) thus considering it member lookup expression.
This allows Interpolation String to "correctly" parse this form as an expression, thus the rest is parsed as part of the string interpolation and not treat the expression as text.