Automatic code generation for formatter

[ematipico]

We should be able to create code automatically, every time we run the xtask syntax.

This task will be disruptive and will apply the following changes:

• cst.rs will be automatically generated, the whole file. If a new node is created, this file should have a new node created (and imported)
• the folder structure will change drastically and will have to follow the naming convention of the nodes. One file will have to implement one single AST node. No more, no less. This will be the golden rule that would allow us to generate nodes automatically.

This is my proposal:

Main folders

The root folder will be the language. For now we have all Js* nodes, they will live inside a js/ folder. Once we will introduce new languages, new folders will pop up:

• ts/ folder for Ts* nodes;
• jsx/ folder for Jsx* nodes;
• etc.

Sub folders

All our nodes contains a "concept" in their name: statement, expression, object member, binding, etc. We could use those concepts as sub folders of the main folders. If a AST node name contains Expression, it will be placed inside the expression/ folder, if it contains ObjectMember, it will be placed inside object_member/ folder. And so on.

Any* element, JsAnyArrayElement

1. the file will be inside the jsfolder
2. the file will be inside js/any/ folder because it contains the Any keyword
3. the file name will be array_element.rs and it will contain the following code:

use crate::{FormatElement, FormatResult, Formatter, ToFormatElement};
use rslint_parser::ast::JsAnyArrayElement;

impl ToFormatElement for JsAnyArrayElement {
    fn to_format_element(&self, formatter: &Formatter) -> FormatResult<FormatElement> {
        match self {
            JsAnyArrayElement::JsSpread(element) => element.to_format_element(formatter),
            JsAnyArrayElement::JsAnyExpression(element) => element.to_format_element(formatter),
            JsAnyArrayElement::JsArrayHole(element) => element.to_format_element(formatter),
        }
    }
}

Rest of elements

For the name of the file, I am a bit conflicted. I would personally leave the whole name.

• JsDoWhileStatement => js/statement/do_while_statement.rs
• JsReturnStatement => js/statement/return_statement.rs
• JsComputedMemberExpression => js/expression/computed_member_expression.rs

Ideally we could remove the "concept" from their name, but I'm not sure if it could create more issues.

The generated file will contain

use crate::{FormatElement, FormatResult, Formatter, ToFormatElement};
use rslint_parser::ast::JsAnyArrayElement;

impl ToFormatElement for JsComputedMemberExpression {
    fn to_format_element(&self, formatter: &Formatter) -> FormatResult<FormatElement> {
        Ok(formatter.format_verbatim(self.syntax()))
    }
}

[leops]

I opened an "RFC" draft PR that adds a tentative design for this in #1998

[ematipico]

I opened an "RFC" draft PR that adds a tentative design for this in #1998

Does it tackle the first bullet point of the task?

[leops]

It does so indirectly: cst.rs isn't autogenerated but calls a macros that is, to let this matching logic be reused across the codebase.

I haven't done anything to address the second part though, so in the meantime I still had to include a placeholder implementation of ToFormatElement on all the AstNodes that were missing one

[leops]

The match expression in cst.rs being complete is going to be a requirement for range formatting and format on type since the formatter needs to be able to start from any node in the tree, so I'll look into this next

[MichaReiser]

The new code-gen is neat. I've a few usability suggestions

• Automatically stage new generated files with git add (low)
• Add a new line ending at the end of the generated files. Clippy doesn't like rust files without.
• Delete outdated files. It's easy to end up with stale files when renaming a node because the old implementations are removed from the mod file and, therefore, the compiler won't generate any compile errors for the no-longer existing nodes.

[MichaReiser]

@leops is there more work you plan to do on the codegen side or can we close this for the time being?

[leops]

No there isn't any work I plan to do on the formatter codegen for now, I'll close this