Is there a way to update the trivia of the first token of an arbitrary (non-const) syntax node ?

[suzizecat]

Hi everyone !

In my effort of making a slang-based formatter, I stumble quite frequently on an issue that seems easy to handle but cause me quite a lot of trouble.

I do have a function, let's call it Token setSpacing(const Token tok, unsigned int nbSpaces) that, given a token, re-generate a list of trivia which would match my spacing needs, attach it to a copy of the original token and return the token.

The result is that I virtually need to handle the specificity of each available kind of syntax node to set the new token appropriately.

As far as I know, the only way to access this first token on a generic SyntaxNode is through getFirstToken(). Note that there are no equivalent setFirstToken().
Those function would work great if they could return a reference to the stored token, but they actually return a copy of the token, so I can't update the trivia of the original token.

Therefore, my question is: Is there a generic way to change(/update) the trivia of the first token of an arbitrary SyntaxNode (without using its SyntaxKind) ?

[MikePopoloski]

There is not currently, but it's doable to add a childToken() overload (and perhaps corresponding overloads for getFirst / getLast) that returns a mutable reference for non-const syntax nodes. In general I don't add methods until there's a use for them, so the fact that they're missing doesn't necessarily mean it was a design intention. I'm happy to accept a PR if you want to add it, or you can wait until I get around to it.

[suzizecat]

I got a look into slang to try to implement this. I would just like to confirm what I understood.

The getChild() is the function to edit as it serves as a base for all other child related functions.

However, SyntaxNode::getChild() actually does nothing by itself, but its implementation depends on the actual SyntaxNode kind, through the visitor. So, if I were to implement a ReferenceTokenOrSyntax SyntaxNode::getChild() (which would contain my Token&), I should then actually implement it in more or less all SyntaxNode derivatives ?

[MikePopoloski]

Yes, all syntax node derived classes need to add it. The syntax_gen.py script generates the code for the vast majority of syntax nodes so there are only a handful you have to write yourself.

[suzizecat]

Neat ! I'll open an actual issue to track this.