Reduce complexity of ParseStatementNoDeclaration #40290
Conversation
|
Can we add a test that verifies the depth to which we can parse nested |
|
I think we should consider making the parser more resilient to stack limitations by moving the work to a new stack/thread when nearing the limit of the current one (when attempting to parse a statement). The downside of such a change is that we may still run out of stack space in a later compiler phase. |
|
I agree with @jaredpar that a test that prevents regression would be a very good idea... as a separate PR on master. #Resolved |
| @@ -6480,7 +6480,7 @@ private StatementSyntax ParseStatementNoDeclaration(bool allowAnyExpression) | |||
| } | |||
| else | |||
| { | |||
| return this.ParseLocalDeclarationStatement(parseAwaitKeyword()); | |||
| return this.ParseLocalDeclarationStatement(parseAwaitKeyword(MessageID.None)); | |||
There was a problem hiding this comment.
Interesting, so the optional parameter prevented this from being inlined?
There was a problem hiding this comment.
I suspected it was the conversions to Nullable<MessageID> rather than the optional parameter. I decided to make the parameter non-optional at the same time.
In reply to: 356841763 [](ancestors = 356841763)
No description provided.