Adjust the way parser handles line-If termination. #14822
Conversation
| GoTo EndBlock | ||
|
|
||
| Case Else | ||
| Throw ExceptionUtilities.UnexpectedValue(token.Kind) |
There was a problem hiding this comment.
Am I right in assuming this fail safe would've caught this case and prevented a successful compilation?
There was a problem hiding this comment.
Yes, before the change we were allowing all kinds of things to pass through the Case Else.
| ' if there is a line-If without Else up the block context chain, or | ||
| ' if we are inside a single-line statement lambda and the 'Else' terminates the lambda. | ||
| Debug.Assert(BlockKind = SyntaxKind.SingleLineElseClause) | ||
| Debug.Assert(PrevBlock.BlockKind = SyntaxKind.SingleLineIfStatement) |
There was a problem hiding this comment.
It feels wrong to have a property which can only be contextually invoked.
There was a problem hiding this comment.
The property can always be invoked, this asserts an invariant in the way block contexts are nested for line-if. They are always nested this way.
|
@dotnet/roslyn-compiler Please review. |
|
@AlekseyTs Could you provide some short code examples of what was allowed and now isn't? |
The issue referenced at the top, #14761, has short example. I also added a bunch of unit-tests, you can compare compiler's behavior for them for before and after the change. |
|
LGTM |
5 participants
Fixes #14761.
@dotnet/roslyn-compiler Please review.