Fix collection literal parsing at the state of a statement expression. #68737
Conversation
ghost
added
Area-Compilers
untriaged
Co-authored-by: Charles Stoner <[email protected]>
src/Compilers/CSharp/Test/Syntax/Parsing/CollectionLiteralParsingTests.cs
Show resolved
Hide resolved
|
@RikkiGibson ptal. |
Co-authored-by: Charles Stoner <[email protected]>
|
@RikkiGibson ptal. This unblocks Chuck from being able to send his PR that renames everything. |
|
@RikkiGibson please review ASAP. Note, I can add any additional tests into the follow-up pr which fixes the breaking change in parsing ternary vs nullable-index expressions |
|
|
||
| // See if we should treat this as a collection expression. At the top-level or statement-level, this should | ||
| // only be considered a collection if followed by a `.`, `?` or `!` (indicating it's a value, not an | ||
| // attribute). |
There was a problem hiding this comment.
Let's make sure to test at some point that in the typing scenario, the tooling doesn't fight us about doing collection literal-ey things, when it thinks we're in an attribute list.
There was a problem hiding this comment.
Right. It likely will need special IDE support here to do well given this ambiguity. But this is very normal for the IDE> For example, we have to do all sort of special work inside of (... since it could be casts, parenthesized-exprs, lambdas, etc. PITA, but in our wheelhouse :)
| ParseBracketedArgumentList(); | ||
|
|
||
| // Check the next token to see if it indicates the `[...]` sequence we have is a term or not. | ||
| var isCollectionExpression = this.CurrentToken.Kind is SyntaxKind.DotToken or SyntaxKind.QuestionToken or SyntaxKind.ExclamationToken; |
There was a problem hiding this comment.
It feels like this should be scanning for either a member modifier or something that could be a type: if it finds one of those, it must be an attribute. Otherwise, it must be a collection initializer. Consider [] + new List<int>(), or [] == new List<int>(), or number of other possible scenarios like them. A hardcoded list of allowable tokens feels too fragile.
There was a problem hiding this comment.
so those don't work here fro the same reason that:
a + b; is not a legal statement. Will discuss more offline.
There was a problem hiding this comment.
Further offline discussion has revealed missing cases such as [() => {}][0](); or [0]++;. Cyrus will file a tracking issue.
4 participants
No description provided.