feat(coverage): enable regexp in test262

[Boshen]

@leaysgur This enables all test262 regexp tests, feel free to decide when's the right time to integrate.

It seems like we need to add some pointing spans on the diagnostics.

It's somewhat slow to run just c, so I always use just example parser for local development.

[IWANABETHATGUY]

Reparsing each regex eagerly in place sounds not reasonable, can we introduce another visit pass (enabled by a option) and reparse each regex then emit diagnostic at the end?

[IWANABETHATGUY]

Most downstream users of parser may not care about whether the regex semantic is correct or not like formater, bundler.

[leaysgur]

But actually, I'm also concerned about how to finish this PR.

With current code,

• oxc_parser parses RegExp and reports errors, but does not seem to hold the parsed results
• RegExp literals(/abc/) are checked, but RegExp object calls(new RegExp("abc")) are not checked

@Boshen What were your original plans?

[leaysgur]

I've thought about it a little, and to organize my thoughts..., I'll answer my own questions.

RegExp literals(/abc/) are checked, but RegExp object calls(new RegExp("abc")) are not checked

It's OK.
In the case of new RegExp("string"), the code is just parsed, and if there’s an error in RegExp, it will occur at runtime.

On the other hand, in the case of /string/, the syntax must satisfy the requirements of a literal, so it should produce an error during the parsing stage, before runtime.

console.log("START");
const a = new RegExp("a{", "u"); // <- Invalid
console.log("END");

This will log "START".

console.log("START");
const a = /a{/u; // <- Invalid
console.log("END");

This, however, will not log anything.

One thing that concerns me, though, is that if invalid literal is treated as error at the parser stage, it would make it impossible to implement rules like eslint/no-invalid-regexp?

How to reuse parsed result

Perhaps parse it again from Semantic, just like with JSDoc...?

[leaysgur]

FYI:

• The previous CodSpeed result was one where the entire source code(!) was passed to the regexp parser, not the regular expression part
• I have not yet been started parser perf improvements

---

Benchmark results have been updated now.

I don't think current approach is not the best solution, but the CI is green. 😅

[IWANABETHATGUY]

FYI:

• The previous CodSpeed result was one where the entire source code(!) was passed to the regexp parser, not the regular expression part
• I have not yet been started parser perf improvements

Thanks for your explanation

[Boshen]

Continue in #4998