Page MenuHomePhabricator

[Syntax] Tablegen Sequence classes. NFC

Authored by sammccall on Nov 2 2020, 6:25 PM.



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.

Diff Detail

Event Timeline

sammccall created this revision.Nov 2 2020, 6:25 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 2 2020, 6:25 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
sammccall requested review of this revision.Nov 2 2020, 6:25 PM

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

gribozavr2 accepted this revision.Nov 4 2020, 3:16 AM
gribozavr2 added inline comments.

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.

This revision is now accepted and ready to land.Nov 4 2020, 3:16 AM
sammccall added inline comments.Nov 11 2020, 7:29 AM

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.


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.

This revision was landed with ongoing or failed builds.Nov 11 2020, 7:29 AM
This revision was automatically updated to reflect the committed changes.