refactor(ast/estree): simplify serializing RegExpLiterals

[overlookmotel]

Similar to #9546. Acorn outputs RegExpLiteral's flags in same order as in source text. There is nothing wrong with this, but it makes our serialization/deserialization code more complex than it needs to be, just to match Acorn. I don't think we need to follow Acorn here - there's no particular "good" order for the flags.

Bump acorn-test262 to include commit oxc-project/estree-conformance@3d7013e, which reorders the flags in alphabetical order in Acorn's AST.

This allows simplifying serialization/deserialization code on our side.

[overlookmotel]

• perf(mangler): use shorter InlineString #9552
• refactor(ast/estree): simplify serializing RegExpLiterals #9551 👈 (View in Graphite)
• perf(ast, codegen, transformer): avoid allocations when converting RegExpFlags to string #9550
• feat(data_structures): move InlineString into oxc_data_structures crate #9549
• refactor(ast): RegExpFlags::to_string return flags in alphabetical order #9548
• feat(ast/estree): Property have consistent field order #9547
• feat(ast/estree): ESTree AST ExportNamedDeclaration always have attributes field #9546
• ci(benchmarks): benchmark NAPI parser #9519
• fix(ast/estree): raw transfer support showSemanticErrors option #9522
• test(ast/estree): speed up raw transfer tests #9521
• feat(ast/estree)!: option to return JS-only AST #9520
• feat(ast/estree): raw transfer (experimental) #9516
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codspeed-hq]

CodSpeed Performance Report

Merging #9551 will create unknown performance changes

_{Comparing 03-04-refactor_ast_estree_simplify_serializing_regexpliteral_s (c1a8cea) with main (734b6b6)}

Summary

🆕 39 new benchmarks

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
🆕	parser_napi[RadixUIAdoptionSection.jsx]	N/A	4.7 ms	N/A
🆕	parser_napi[pdf.mjs]	N/A	1.8 s	N/A
🆕	parser_napi_raw[RadixUIAdoptionSection.jsx]	N/A	1.3 ms	N/A
🆕	parser_napi_raw[cal.com.tsx]	N/A	700.5 ms	N/A
🆕	parser_napi_raw[checker.ts]	N/A	1.1 s	N/A
🆕	parser_napi_raw[pdf.mjs]	N/A	266 ms	N/A
🆕	codegen[checker.ts]	N/A	23.1 ms	N/A
🆕	codegen_sourcemap[checker.ts]	N/A	66.2 ms	N/A
🆕	isolated-declarations[vue-id.ts]	N/A	57.9 ms	N/A
🆕	lexer[RadixUIAdoptionSection.jsx]	N/A	20.8 µs	N/A
🆕	lexer[antd.js]	N/A	24.1 ms	N/A
🆕	lexer[cal.com.tsx]	N/A	5.7 ms	N/A
🆕	lexer[checker.ts]	N/A	14.5 ms	N/A
🆕	lexer[pdf.mjs]	N/A	3.8 ms	N/A
🆕	linter[RadixUIAdoptionSection.jsx]	N/A	2.7 ms	N/A
🆕	linter[cal.com.tsx]	N/A	1.2 s	N/A
🆕	linter[checker.ts]	N/A	2.9 s	N/A
🆕	mangler[antd.js]	N/A	16 ms	N/A
🆕	mangler[react.development.js]	N/A	296.8 µs	N/A
🆕	mangler[typescript.js]	N/A	39.7 ms	N/A
...	...	...	...	...

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

[camchenry]

Was the order potentially in frequency? I'm guessing "g" and "I" are used most frequently. But I don't think it really matters, I don't see why we shouldn't keep it consistent here, plus it makes it faster

[graphite-app]

Merge activity

• Mar 4, 9:04 PM EST: A user added this pull request to the Graphite merge queue.
• Mar 4, 9:48 PM EST: A user merged this pull request with the Graphite merge queue.