[Syntax] Tablegen Sequence classes. NFC

[sammccall]

Summary

Similar to the previous patch, this doesn't convert *all* the classes that
could be converted. It also doesn't enforce any new invariants etc.

It *does* include some data we don't use yet: specific token types that are
allowed and optional/required status of sequence items. (Similar to Dmitri's
prototype). I think these are easier to add as we go than later, and serve
a useful documentation purpose.

[sammccall]

Again, the generated code is identical to the code being deleted apart from formatting and the fact that methods are defined inline.

[gribozavr2]

clang/include/clang/Tooling/Syntax/Nodes.td

123

The reason why in my prototype the grammar rules are separate is to allow expressing rules that depend on each other in a circular fashion. Seems like you avoided the problem right now by removing the need for Expression to refer to all subclasses, but it would come back, in, for example, LambdaExpression -- which is an expression that needs to refer to CompoundStatement that is defined later in this file, while CompoundStatement will need to refer to Expression. Maybe there is also a way to break circularity there by careful ordering -- but we would be mixing the order of expressions and statements.

clang/include/clang/Tooling/Syntax/Syntax.td

73

[sammccall]

clang/include/clang/Tooling/Syntax/Nodes.td

123

In the current setup, there's a simple solution to the ordering constraints: define all the Alternatives first. It's not ideal, but I think less confusing than having separate defs for rule vs nodes.

OTOH if we want Alternatives to have down-edges later (which I think would make sense if we use variants rather than subclassing) then we'll definitely run into cycles and will need to break them by splitting out the rules.
(Or if we have cycles that don't involve Alternatives, and don't want to introduce artificial ones).

I think we probably will hit this case, but would like to punt on it a little to see whether it makes sense to break loops only where needed or fully separate declaration/definition.

clang/include/clang/Tooling/Syntax/Syntax.td

73

Hmm, I don't like swapping the order here - the role is both more important and written first.
I think the issue is the scope of "unique" is ambiguous, I'll try to fix that.