Razor fallback changes #73001
Razor fallback changes #73001
Conversation
…g as a single-line comment.
dotnet-issue-labeler
bot
added
Area-Compilers
untriaged
|
/azp run |
|
I'm going to proceed with these changes for now, and I've marked #73002 as blocking so that we cover it in our next API review session. @dotnet/roslyn-compiler @CyrusNajmabadi for review please. |
|
@dotnet/roslyn-compiler @CyrusNajmabadi for reviews please |
| @@ -526,6 +526,7 @@ public enum SyntaxKind : ushort | |||
| Utf8StringLiteralToken = 8520, | |||
| Utf8SingleLineRawStringLiteralToken = 8521, | |||
| Utf8MultiLineRawStringLiteralToken = 8522, | |||
| BadRazorContentToken = 8523, | |||
There was a problem hiding this comment.
do we want some sort of razor section?
There was a problem hiding this comment.
I don't think so? I think the single token should be fine.
There was a problem hiding this comment.
wfm. what i was imaginging though was that there might be a few types of razor kinds we detected. like razor comments, bad razor tokens. perhaps a couple different razor tokens.
--
Ah, i now see why i don't like this name. i want somethnig to indicate it's a @:. So perhaps BadRazorAtSignColonToken. Or perhaps BadRazorLineToken. Something that really conveys this is the token we produce when we see @: and go to the end of the line.
I feel moderately strongly :)
There was a problem hiding this comment.
See, I want exactly the opposite: I don't want to break out the various things we do for error recovery for razor. What if next year razor adds a new thing that we want to recover for, are we going to need to break that out separately? Or what if Razor removes the need for us to handle this? I'd rather it just be "this is something C# doesn't expect", with no further specificity.
There was a problem hiding this comment.
Or what if C# decides that @: is a cool syntax to use for something next year, so we add an AtColonToken, and now we have this vestigal BadRazorAtSignColonToken.
There was a problem hiding this comment.
i'll let you make the call here. but my gut tells me breaking things out would be valuable. especially as i can imagine you wanting ot have a particular error recovery strategy for a particular razor token in a particular position.
That said, this is nto blocking feedback. You make the call. Imagine if you do want specific error recovery, you can still get it, even with a single kind. Because you can always still examine the token to see the starting chars and whatnot. It just seems oogier. But if that's your preference, totally ok with me. My sign off still remains :)
There was a problem hiding this comment.
Razor is already in the business of inspecting characters, so that doesn't feel oogie to me 🙂. I'd prefer to keep the C# api flexible here.
| /// Parse the leading trivia of the next token from the input at the current position. This will advance the internal position of the | ||
| /// token parser to the end of the leading trivia of the next token. The returned result will have a token with <see cref="CSharpExtensions.Kind(SyntaxToken)"/> | ||
| /// of <see cref="SyntaxKind.None"/>, <see cref="SyntaxToken.IsMissing"/> set to <see langword="true"/>, and a parent of <see langword="null"/>. The | ||
| /// parsed trivia will be set as the <see cref="SyntaxToken.LeadingTrivia"/> of the token. |
There was a problem hiding this comment.
parser changes lgtm and work in a consistent way that i think fits roslyn's syntactic model.
still not 100% sure about how razor will be consuming this and if it will be sufficient for your needs.
Open question to consider: should we make this API "experiemntal" so that if we discover we need to make tweaks in teh short term, we can do so more easily without leaving cruft behind.
* upstream/main: (1047 commits) Ensure source paths are comparable with editorconfig directory paths (dotnet#73100) Lower drop retention from 10 years to 3 months (dotnet#73190) Move fix restore code remove simplify simplify Move off of map Simplify tests Simplify tests Simplify tests Simplify tests Simplify tests simplify finish Simplify Fix Finish Remove dispose support ...
src/Compilers/CSharp/Test/Syntax/LexicalAndXml/SyntaxTokenParserTests.cs
Show resolved
Hide resolved
Co-authored-by: Jan Jones <[email protected]>
This adds a couple of new APIs to deal with edge cases that Razor needs to care about:
ParseLeadingTriviaandParseTrailingTriviamethods to theSyntaxTokenParser, which will allow Razor to handle trivia sections before a@:correctly.BadRazorContentToken. We don't want to use a genericBadTokenfor this becauseBadTokencan cause parsing loops to fail upward, under the assumption that an outer scope may better be able to handle it. We don't to negatively affect mainline C# parsing here, so we add a generic token for this scenario that the parser will always convert into skipped tokens later.