kflash / seafox Goto Github PK

async function f() {   class x extends await y { }   }

Per spec: https://tc39.es/ecma262/#prod-ClassHeritage ClassHeritage should be a LeftHandSideExpression. If I am reading correctly, AwaitExpression is not a LeftHandSideExpression.

This is my private parser code made public. It strictly conforms to the standard ECMAScript® 2020 (ECMA-262 10th Edition) language specification, and can not be used as an drop-in replacement for other parsers.

The main reason for this is that all parsers uses a parse() method - Seafox uses either parseScript or parseModule.

Seafox focus only on performance, and if you are soft hearted and / or can't understand super low level code - this parser isn't for you :)

I would recommend to use the Meriyah parser instead of Seafox if you need a parser that behave like other public parsers, and also if you are in need of performance even the fact that Seafox is 15 - 25 % faster than the mentioned parser.

Seafox is build for performance, and this is the current benchmark results.

When parsing for loops with variable declarations, the type attribute is incorrectly set.

for (const x of y) {

}

AST Output:

{
  "type": "VariableDeclaration",
  "kind": 32,
  "declarations": [
    {
      "type": "VariableDeclarator",
      "id": {
        "type": "Identifier",
        "name": "x"
      },
      "init": null
    }
  ]
}

Expected:

{
  "type": "VariableDeclaration",
  "kind": "const",
  "declarations": [
    {
      "type": "VariableDeclarator",
      "id": {
        "type": "Identifier",
        "name": "x"
      },
      "init": null
    }
  ]
}
```

If no need for ESTree, Kataw (work in progress) is the fastest JS parser. See benchmark.

Kataw is an CST.

([(a) = []] = []) => {}
async ([(a) = []] = []) => {};
function f([(a) = []] = []) {};

should throw

The following two expressions produce unexpectedly different output structures. I'm confused why this might be the case, and (assuming it's not a bug) how I should logically understand the structure when it comes to rendering. It's not clear, based on the AST, exactly where the optional chain operator should go. Why is c optional in the second example but not the first? Why does a computed property affect the structure so much? Also why is there always a base property? Why not just an array of chaining members?

Note that I'm trying this with Seafox as I was previously trying to do it with Meriyah, but Meriyah was producing an even more confusing structure with a kind of weird backward-nested structure that seems to chain in reverse via nested base properties.

seafox.parse(`a?.b?.[c]`)
seafox.parse(`a?.b?.c`)

Relevant outputs:

{
  "type": "MemberExpression",
  "object": {
    "type": "ChainingExpression",
    "base": {
      "type": "Identifier",
      "name": "a"
    },
    "chain": [
      {
        "type": "MemberChain",
        "computed": false,
        "property": {
          "type": "Identifier",
          "name": "b"
        },
        "optional": true
      }
    ]
  },
  "computed": true,
  "property": {
    "type": "Identifier",
    "name": "c"
  }
}

{
  "type": "ChainingExpression",
  "base": {
    "type": "Identifier",
    "name": "a"
  },
  "chain": [
    {
      "type": "MemberChain",
      "computed": false,
      "property": {
        "type": "Identifier",
        "name": "b"
      },
      "optional": true
    },
    {
      "type": "MemberChain",
      "computed": false,
      "property": {
        "type": "Identifier",
        "name": "c"
      },
      "optional": true
    }
  ]
}

I was trying out the released version of seafox (1.6.9) and note that it appears to have shipped with lots of baked-in debug logging (via console.log()). I suspect that this was a mistake and wonder if a new release might be cut with those bits of logging removed.

I have a use-case where I need to perform semantic analysis in the browser and am looking for a combination of performance and bundle size. Seafox looks like a great candidate there!

I was browsing the source code and stumbled across a bit set that had a duplicate bit set ("set" being the verb here). Is this intentional?