Grammar – Consistency & Cleanup 2

[Nigel-Ecma]

[Continues on from #1290 Grammar – Consistency & Cleanup]

This PR removes type_parameter_constraints_clauses orphaned during the v5 -> v6 transition.

In v5 this rule was present in a number of places, e.g.:

class-declaration:
   attributes_opt class-modifiers_opt partial_opt class identifier type-parameter-list_opt
   class-base_opt type-parameter-constraints-clauses_opt class-body ;_opt

Where ever it occurred it was optional. The rule itself was defined as:

type-parameter-constraints-clauses:
   type-parameter-constraints-clause
   type-parameter-constraints-clauses type-parameter-constraints-clause

which is one or more type-parameter-constraints-clause specified using left-recursion.

Combining “optional” with “one or more” produces “zero or more” – which the ANTLR notation provides directly using *, so in v6 the clauses using type-parameter-constraints-clauses all changed to using type-parameter-constraints-clause zero or more times, e.g.:

class_declaration
    : attributes? class_modifier* 'partial'? 'class' identifier
        type_parameter_list? class_base? type_parameter_constraints_clause*
        class_body ';'?
    ;

along with all in-text references to type_parameter_constraints_clauses being changed to type_parameter_constraints_clauses (trailing 's' not in italics).

Job done…

Well not quite type_parameter_constraints_clauses was not deleted but orphaned, and a few of those in-text references were missed and/or the English grammar around them not fixed up.

This PR simply completes the job.

(And there is a little trailing whitespace cleanup done as my check-in “lint” action barfs at them.)

[jskeet]

Again we've got removal of trailing whitespace... @BillWagner is that something we can lint for? It would be good to remove it in a single PR and then make sure it doesn't creep in again. (I'm fine to keep the changes in this PR for simplicity.)

[jskeet]

Again, I'm pretty confident I understand this one...

[BillWagner]

This also LGTM. Let's at our next meeting.

[BillWagner]

Again we've got removal of trailing whitespace... @BillWagner is that something we can lint for? It would be good to remove it in a single PR and then make sure it doesn't creep in again. (I'm fine to keep the changes in this PR for simplicity.)

TL;DR; Instead of doing all the work to automate whitespace removal, I suggest that if we create a PR with a lot of whitespace cleanup, that PR author should recommend reviewers "hide whitespace".

Here's why: Markdown lint will flag a single trailing whitespace character. However, 2 whitespace characters creates a line break. I agree with the cited author that it's hard to see, so use a blank line instead. So, removing all whitespace likely changes the rendered output.

Instead, let's just keep updating as the tools point out concerns.

[Nigel-Ecma]

Here's why: Markdown lint will flag a single trailing whitespace character. However, 2 whitespace characters creates a line break. I agree with the cited author that it's hard to see, so use a blank line instead. So, removing all whitespace likely changes the rendered output.

As many of you know I find Markdown one of the most beautiful languages ever developed and now I learn the face of it been scared by this carbuncle?!? (/s, just in case)

Across the Standard’s md files there are currently 68 occurences of two or more spaces at the end of lines (the Google flavoured markdown trigger for a hard break). A brief glance at just a few showed they had no effect due to other formatting, but an exhaustive check would be required to see if they all could be clobbered.

If a hard break is required a line can be ended with a backslash, which at least is visible. I suggest we make that a Standard requirement and then look at clobbering all current trailing whitespace and flagging it after that (https://github.com/updownpress/markdown-lint/blob/master/rules/009-no-trailing-spaces.md)