Grammar – Consistency & Cleanup 4

[Nigel-Ecma]

[Continues on from #1318 Grammar – Consistency & Cleanup 3]

This PR is the fourth in the series.

The targets here are namespace_or_type_name and unbound_type_name – two constructs which
are variants of each other.

The existing grammar from §7.8.1 & §12.8.18:

namespace_or_type_name
    : identifier type_argument_list?
    | namespace_or_type_name '.' identifier type_argument_list?
    | qualified_alias_member
    ;

unbound_type_name
    : identifier generic_dimension_specifier?
    | identifier '::' identifier generic_dimension_specifier?
    | unbound_type_name '.' identifier generic_dimension_specifier?
    ;

These are left-recursive definitions which would probably have used repetition if it had
been available at the time.

Note that despite the syntactic similarity a name, such as System.Collections.ArrayList,
is resolved at compiled time to reference a particular type, while a sequence of member
accesses, such as x.y.z, involves runtime code execution. While we describe the latter
using left recursion the latter is suited to repetition.

The revised grammar for these two is:

namespace_or_type_name
    : identifier type_argument_list? ('.' identifier type_argument_list?)*
    | qualified_alias_member ('.' identifier type_argument_list?)*
    ;

unbound_type_name
    : identifier generic_dimension_specifier? ('.' identifier generic_dimension_specifier?)*
    | unbound_qualified_alias_member ('.' identifier generic_dimension_specifier?)*
    ;

unbound_qualified_alias_member
    : identifier '::' identifier generic_dimension_specifier?
    ;

The production unbound_qualified_alias_member has been introduced to mirror qualified_alias_member
and is used only here.

Resolution of a namespace_or_type_name is currently a many branched nested if/otherwise,
with the revised grammar using repetition rather than left recursion this has been re-jigged
to match, including new subscripts! ;-)

Review Notes:

You only need to consider the changes to the *.md files in standard; the other files are machine-generated updates to parsing test samples describing the new expected parse for some samples. If you wish to see visualisations of the changes you may download the changed *.svg files in the PR and the current versions of them in draft-v8 and view them side-by-side (multiple monitors helps!)

[BillWagner]

Great work again @Nigel-Ecma

It took me a couple reads to ensure the semantics are the same. I like the transformation here.

Let's

[jskeet]

I'm planning to review this on Monday.

[jskeet]

A few nits, but I'm generally happy. It's entirely possible that I've missed something, of course.

[Nigel-Ecma]

A few nits, but I'm generally happy. It's entirely possible that I've missed something, of course.

Thanks for catching those Jon, all committed.

[jskeet]

Great - I'm happy to go with either merging now, or wait for others to review as well. Thoughts, @Nigel-Ecma and @BillWagner?

[jskeet]

After offline discussion, merging now - we can revisit aspects if we need to when the next PR is discussed.