search

dotnet / csharpstandard

Working space for ECMA-TC49-TG2, the C# standard committee.
Creative Commons Attribution 4.0 International
706 stars 84 forks source link

Grammar ambiguities #1115

Open logeshkumars0604 opened 3 months ago

logeshkumars0604 commented 3 months ago

Type of issue

Other (describe below)

Description

In the Grammar ambiguities section mentioned below,

If a sequence of tokens can be parsed (in context) as a _simplename, _memberaccess, or _pointer_memberaccess ending with a _type_argumentlist, the token immediately following the closing > token is examined, to see if it is:

... One of the relational operators < > <= >= is as; ...

If the following token is among this list, or an identifier in such a context, then the _type_argumentlist is retained as part of the _simplename, _memberaccess or _pointermember-access and any other possible parse of the sequence of tokens is discarded. Otherwise, the _type_argumentlist is not considered to be part of the _simplename, _memberaccess or _pointer_memberaccess, even if there is no other possible parse of the sequence of tokens.

The statements

F(G<A, B>7);
F(G<A, B>>7);

will each be interpreted as a call to F with two arguments.

it is mentioned that if the token following the > token in a simple name / member access / pointer member access is one of the relational operators (< > <= >= is as), the simple name / member access / pointer member access will be interpreted with type argument list.

But in the mentioned example, F(G<A, B>>7), the token > is followed by the token >. Need help to understand why it is not being interpreted with type argument list.

Page URL

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/lexical-structure

Content source URL

https://github.com/dotnet/csharpstandard/blob/draft-v8/standard/lexical-structure.md

Nigel-Ecma commented 3 months ago

@logeshkumars0604 – Thanks for spotting this. The token > should not be in that list and needs to be removed. If you wish to submit a PR that removes it please do so, you can put me down as a reviewer.

Note there is a more complex disambiguation rule possible where > might be used, it is likely this error stems from that – but as the rest of that rule is not mentioned simply removing the errant > is a valid fix until, and if, that more complex rule is added to the Standard.