Skip to content

Unified: Get rid of all $children fields#21841

Draft
tausbn wants to merge 23 commits into
mainfrom
tausbn/unified-swift-named-body-fields
Draft

Unified: Get rid of all $children fields#21841
tausbn wants to merge 23 commits into
mainfrom
tausbn/unified-swift-named-body-fields

Conversation

@tausbn
Copy link
Copy Markdown
Contributor

@tausbn tausbn commented May 12, 2026

A grab bag of changes, mostly making nodes named, or adding fields, and in a few cases doing some more advanced rewrites. Can be reviewed commit-by-commit.

tausbn added 23 commits May 12, 2026 12:57
Part 1 of N of "getting rid of $children" in node-types.yml

Note: in one of the cases the affected node still has the $children
field present. This is because there's some weirdness about recording
multiline comments as class member separators that I did not want to
figure out how to address right now.
I ended up also aliasing `_async_keyword` to a named node to make it
more consistent with the other node kinds that can be in this field (as
it would be awkward to have two named types and a token here).

Elsewhere in the node types, we'll still have `async?: "async"`, and I
think that's okay.
A lot of changes, but for the most part these are just adding named
fields in places where they make sense.

After this, there are still ~20 instances of unnamed children appearing.
This required a change in a different place, due to aliasing.
Some nodes with a single child (arguably redundant to do, but I think
it's nice to have the types be consistent), and also an instance of
ensuring that all branches of a `choice` expose consistent field names.
Not entirely happy about the mixed nature of the `kind` filed (having
both tokens and the named node `throw_keyword` in there), but that's a
problem for a different time.
Doing this involved materialising a lot of previously anonymous nodes,
and I'm not entirely sure it's the best solution, but the node types
look decent enough.
Of note: this involved un-inlining where_clause.
Not entirely sure about the `binding?` field on `pattern`, but it looks
like that might actually be useful.
Mostly by materialising a bunch of (useful) intermediate nodes.
I'm not entirely happy about this solution, but it seemed to be the most
straightforward way of avoiding various kinds of token bleeding.
This named node (which is in fact emitted by the scanner as an
`external`) was appearing as a child of `class_body` because of inlining
via `_class_member_separator`. This, in itself, appears to be somewhat
of a hack, to handle cases where a multiline comment signals the end of
a class member.

To fix this, we make the external node _unnamed_, but keep the `extras`
node _named_ (so we can still extract it from the parse tree), and we
add a new rule `multiline_comment` that mediates between the two. That
way, the use inside `_class_member_separator` can use the unnamed
variant, and no node is pushed into $children.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant