Tolerant parsing: continue parsing when a Glimmer syntax is invalid

[BlueCutOfficial]

This PR is far from ready, it simply aims at starting a discussion.

Context

When using ember-template-lint, any syntax error found throws a GlimmerSyntaxError and makes the result of the lint process invalid. On a project I've been working on with @mansona, we would have needed some sort of "tolerant mode", a way to be notified about errors without blocking the linter.

The current state of this PR is just a start, and aims at gathering feedbacks about the direction it should take:

• It takes the PartialStatement as an example and doesn't throw when a Handlebars partial is found, and the resulting AST template simply doesn't contain the node.
• The next step would be to build some kind of error node that would have a representation in the resulting AST template.
• Using a new class field for the Parser seemed cleaner and less intrusive to me than trying to implement it as parse function's argument.

[NullVoxPopuli]

feedbacks about the direction it should take:

1. It takes the PartialStatement as an example and doesn't throw when a Handlebars partial is > found, and the resulting AST template simply doesn't contain the node.
2. The next step would be to build some kind of error node that would have a representation in > the resulting AST template.
3. Using a new class field for the Parser seemed cleaner and less intrusive to me than trying to implement it as parse function's argument.

I think we should only focus on # 2 here. As a parser, we don't really want to have varying APIs as we churn through version numbers (as we normally would in post-1.0 packages). This is slightly constrained by the VM still being pre 1.0 (and package-managers treating pre-1.0 semver differently 🫠 ), but also, fault tolerance is something all our parsing tools want:

• Glint
• Eslint
• Prettier

As when we can correctly parse and recover from errors we can provide more helpful information to the user to aid them in fixing their syntax errors.

For example, here is what tree-sitter does (error nodes):

Screen.Recording.2024-11-20.at.10.38.45.AM.mov

(sorry for potato quality -- I need to see if quicktime has an option to not compress so hard (inefficiently, too!))

Even within an error node, it tries to recover immediately, which also keeps syntax highlighting nice, but this also has the benefit of allowing in-progress intellisense, such as this more realistic example:

[BlueCutOfficial]

I think we should only focus on #2 here.

I started to work on the Error node thing. I hope I can post one more commit tomorrow, and you'll tell me if I am doing this right or wrong. Thanks for the first answer and recordings 👍

[BlueCutOfficial]

Here is the result template I have so far for the "continue parsing after an error" test:

Please let me know your thought about the code and what you think is missing to get this PR ready. I would prefer to have a first approval about the approach ahead of implementing it for the other invalid syntaxes (and I am a bit in discovery mode here, I don't have personal opinions to defend).

[NullVoxPopuli]

yea, for partials, that's that a very nice output!

[BlueCutOfficial]

@NullVoxPopuli I moved a bit forward on my locale machine, and I would like to have your opinion on something.

If I have this piece of code: let t = <div {{mymodifier}}></div>

Parsing t results to the following structure ⬇️

{
      "attributes": [],
      "blockParams": [],
      "children": [],
      "comments": [],
      "modifiers": [
        {
          "hash": {
            "pairs": [],
            "type": "Hash"
          },
          "params": [],
          "path": {
            "head": {
              "name": "mymodifier",
              "original": "mymodifier",
              "type": "VarHead"
            },
            "original": "mymodifier",
            "tail": [],
            "type": "PathExpression"
          },
          "type": "ElementModifierStatement"
        }
      ],
      "params": [],
      "path": {
        "head": {
          "name": "div",
          "original": "div",
          "type": "VarHead"
        },
        "original": "div",
        "tail": [],
        "type": "PathExpression"
      },
      "selfClosing": false,
      "tag": "div",
      "type": "ElementNode"
    }

Now if I have something invalid: let t = <div {{...attributes}}></div>.

Where do you think the error node should go in the structure? Would it belong to 1. the list of modifiers, or 2. a list "errors" to be added to ElementNode fields.

[reteps]

Hi there -- I'm thinking this PR would be a first step for prettier to support some handlebars variants. Ideally, I would love if when Glimmer fails to parse the AST of a node, it can expose enough information that the the rest of the document can be parsed and formatted. For example if <div {{mymodifier}}></div> fails, information like an ErrorNode="<div {{mymodifier}}></div>".

There are currently a couple prettier issues with handlebars templates, so making the parser more tolerant would support those cases. The ones I am aware of are:

prettier/prettier#14834
prettier/prettier#14090
prettier/prettier#11834

[NullVoxPopuli]

aye, we have some of that work happening over here: #1690

which has lead to vastly improved error reporting 🎉