Fix a few param-nullchecking parsing bugs#58644
Fix a few param-nullchecking parsing bugs#58644RikkiGibson merged 18 commits intodotnet:release/dev17.1from
Conversation
| && this.PeekToken(3).Kind == SyntaxKind.ExclamationToken | ||
| && after.GetTrailingTriviaWidth() == 0 | ||
| && this.PeekToken(3).GetLeadingTriviaWidth() == 0 | ||
| && token3.Kind == SyntaxKind.ExclamationToken |
There was a problem hiding this comment.
intentionally removed this restriction.
There was a problem hiding this comment.
here we are accepting this during scanning so we can give a better parse with errors, right?
There was a problem hiding this comment.
correct! it also means there's uniform 'token handling' that goes in before calling the helper. none of these scanners (or hte helper) care about having this requirement. it means they're all resilient to accidental spaces happening as you edit.
| && this.PeekToken(1).Kind == SyntaxKind.ExclamationToken | ||
| && this.CurrentToken.GetTrailingTriviaWidth() == 0 | ||
| && this.PeekToken(1).GetLeadingTriviaWidth() == 0) | ||
| && this.PeekToken(1).Kind == SyntaxKind.ExclamationToken) |
There was a problem hiding this comment.
intentionally removed this restriction.
src/Compilers/CSharp/Test/Syntax/Parsing/DeclarationParsingTests.cs
Outdated
Show resolved
Hide resolved
| && this.PeekToken(3).Kind == SyntaxKind.ExclamationToken | ||
| && after.GetTrailingTriviaWidth() == 0 | ||
| && this.PeekToken(3).GetLeadingTriviaWidth() == 0 | ||
| && token3.Kind == SyntaxKind.ExclamationToken |
There was a problem hiding this comment.
here we are accepting this during scanning so we can give a better parse with errors, right?
| && this.PeekToken(3).Kind == SyntaxKind.GreaterThanToken) | ||
| if (token1.Kind == SyntaxKind.ExclamationToken | ||
| && token2.Kind == SyntaxKind.ExclamationEqualsToken | ||
| && token3.Kind == SyntaxKind.GreaterThanToken) |
There was a problem hiding this comment.
It's not necessary to change it but I wonder if this if and the preceding ifs would combine nicely as a pattern switch statement, or even something like
if ((token1.Kind, token2.Kind, token3.Kind) is ('!', '!', '=>') or ('!=', '>', _) or ('!', '!=', '>')) return true;except with the proper use of SyntaxKind enum and proper indenting of course.
There was a problem hiding this comment.
yup. i def like that!
| UsingDeclaration("Func<string[], string> func0 = (x[]) => x;", options: TestOptions.RegularPreview, | ||
| // (1,36): error CS1001: Identifier expected | ||
| // Func<string[], string> func0 = (x[]) => x; | ||
| Diagnostic(ErrorCode.ERR_IdentifierExpected, ")").WithLocation(1, 36)); N(SyntaxKind.FieldDeclaration); |
There was a problem hiding this comment.
I don't mind this parse, but I was confused that it expected an identifier instead of ).
There was a problem hiding this comment.
good point. let me look into that!
| UsingDeclaration("Func<string, string> func0 = (y, x = null) => x;", options: TestOptions.RegularPreview, | ||
| // (1,44): error CS1003: Syntax error, ',' expected | ||
| // Func<string, string> func0 = (y, x = null) => x; | ||
| Diagnostic(ErrorCode.ERR_SyntaxError, "=>").WithArguments(",", "=>").WithLocation(1, 44)); N(SyntaxKind.FieldDeclaration); |
There was a problem hiding this comment.
does make me wonder if there is more room to unify on parameter lists in parenthesized lambdas and non-lambdas, and if we could simplify the parser and move some errors like these to binding in the process.
There was a problem hiding this comment.
this is definitely possible. the IsPossibleLambda will have to do much more speculative parsing to handle the = null places whatnot. I put these tests in though so we could see the improvement if we do that.
i'm open to doing more in this PR if you've like!
There was a problem hiding this comment.
I think we should consider it a "design debt" issue to address in the future.
src/Compilers/CSharp/Test/Syntax/Parsing/LambdaParameterParsingTests.cs
Outdated
Show resolved
Hide resolved
|
The test failure in Unix is due to a whitespace/line ending difference. Haven't quite figured out how to hammer it down. edit: resolved by eliminating the problematic test scenario. I don't think the scenario is valuable enough to warrant further effort working around the cross-plat/test framework issue. |
Co-authored-by: Charles Stoner <10732005+cston@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
Co-authored-by: Charles Stoner <10732005+cston@users.noreply.github.com>
| @@ -129,59 +129,49 @@ public void NullCheckedBadSyntax() | |||
| #pragma warning disable CS8893 | |||
There was a problem hiding this comment.
sigh yes, some renumbering must have broken it. I feel it's simpler to use a literal string here, so if you don't object I'd like to keep it as it is in this PR. But I will delete the pragma.
Closes #58585
Thanks to Cyrus for the greater part of the work here.
Relates to test plan #36024