Explicitly handle switch expressions in parser#12500
Conversation
| LessThan;[<]; | ||
| Identifier;[span]; | ||
| GreaterThan;[>]; | ||
| Identifier;[some]; | ||
| Whitespace;[ ]; | ||
| LessThan;[<]; | ||
| Identifier;[i]; | ||
| GreaterThan;[>]; | ||
| Identifier;[html]; | ||
| LessThan;[<]; | ||
| CSharpOperator;[/]; | ||
| Identifier;[i]; | ||
| GreaterThan;[>]; | ||
| LessThan;[<]; | ||
| CSharpOperator;[/]; | ||
| Identifier;[span]; | ||
| GreaterThan;[>]; |
There was a problem hiding this comment.
Just to make sure, we're saying that this is interpreted as C#, not razor? That seems reasonable, but just wanted to make sure that's what was intended.
There was a problem hiding this comment.
Yes, once inside a switch expression everything is parsed as C# and you can't drop into HTML.
| Accept(in read); | ||
| return; | ||
| } | ||
| else if (At(SyntaxKind.Keyword)) |
There was a problem hiding this comment.
Not sure that ParseStatement will handle all possible locations here. What if it's an embedded expression inside a @(), for example?
There was a problem hiding this comment.
Huh, so I tried that and it actually just works. Because we don't allow you to drop to HTML inside an explicit expression, we don't have to do any special handling for it.
I added some tests to cover it too.
davidwengier
left a comment
davidwengier
left a comment
There was a problem hiding this comment.
As discussed early, this is valid in Razor files today:
@{
RenderFragment x = val switch
{
true => @<div></div>,
false => @<div></div>
};
}
Would be good to add a test, even if it's skipped for now, with what that looks like now, and what it looks like with a less than as the first character in the first arm
3 participants
Fixes #7230