-
Notifications
You must be signed in to change notification settings - Fork 199
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
Add FindToken
to SyntaxNode
#8956
Conversation
This implements `SyntaxNode.FindToken`, as was discussed a couple of months ago. The basic semantics of the method are very similar to Roslyn's implementation, but with one significant difference: no attempt is made to ignore any trivia other than whitespace. To recap, this means the rules for `FindToken` are: 1. Find the SyntaxToken that covers the position requested. 2. Scan backwards until a non-whitespace token is encountered. If it's a newline, goto 3. Otherwise, return the token. 3. Scan forwards until a non-whitespace, non-newline token is encountered. Return this token. There's an additional complication here as well that Roslyn does not have to deal with: because SyntaxToken is a reference type and inherits SyntaxNode, it is possible to call FindToken on that token. If that token is itself a whitespace node, I've taken the opinion that we should not try and do any scanning; we will simply treat it as out of range of the request. I think this is fine for most consumers, as I don't expect there to be any reason for this particular combination of inputs to naturally occur; most calls to FindToken are on the tree root, or on a larger expression. We can adjust this if necessary, however.
@dotnet/razor-compiler for reviews of this please. @dotnet/razor-tooling folks, please look over the tests at the behavior of the API and let me know if you think this is a suitable replacement for |
src/Shared/Microsoft.AspNetCore.Razor.Utilities.Shared/PooledObjects/PooledArrayBuilder`1.cs
Show resolved
Hide resolved
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.
I welcome any and all test suggestions on this one. Feel free to get this over 1000 lines!
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.
Just looked at the tests and the methods XML doco, and this makes perfect sense as a FindToken api. Whether it breaks everything in tooling will be an interesting discovery process 😁
src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Syntax/FindTokenTests.cs
Show resolved
Hide resolved
src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Syntax/FindTokenTests.cs
Show resolved
Hide resolved
src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Syntax/FindTokenTests.cs
Show resolved
Hide resolved
src/Compiler/Microsoft.AspNetCore.Razor.Language/src/Syntax/SyntaxNode.cs
Outdated
Show resolved
Hide resolved
src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Syntax/FindTokenTests.cs
Show resolved
Hide resolved
src/Shared/Microsoft.AspNetCore.Razor.Utilities.Shared/PooledObjects/PooledArrayBuilder`1.cs
Show resolved
Hide resolved
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.
LGTM, a couple of small suggestions.
src/Compiler/Microsoft.AspNetCore.Razor.Language/src/Syntax/SyntaxNode.cs
Outdated
Show resolved
Hide resolved
src/Compiler/Microsoft.AspNetCore.Razor.Language/src/Syntax/SyntaxNode.cs
Outdated
Show resolved
Hide resolved
@chsienki and @DustinCampbell, minor code simplification in the latest commit, if you could take a quick look. I realized that the bottom element of the stack was completely unnecessary and it introduced more complex handling than was necessary. |
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.
LGTM
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.
Looks good to me!
This implements
SyntaxNode.FindToken
, as was discussed a couple of months ago. The basic semantics of the method are very similar to Roslyn's implementation, but with one significant difference: no attempt is made to ignore any trivia other than whitespace. To recap, this means the rules forFindToken
are:There's an additional complication here as well that Roslyn does not have to deal with: because SyntaxToken is a reference type and inherits SyntaxNode, it is possible to call FindToken on that token. If that token is itself a whitespace node, I've taken the opinion that we should not try and do any scanning; we will simply treat it as out of range of the request. I think this is fine for most consumers, as I don't expect there to be any reason for this particular combination of inputs to naturally occur; most calls to FindToken are on the tree root, or on a larger expression. We can adjust this if necessary, however.