-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
refactor(ast): Introduce flexible serialization encoding for ast #11100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
c9d0a01
to
de8261b
Compare
CodSpeed Performance ReportMerging #11100 will not alter performanceComparing Summary
Footnotes |
de8261b
to
bc125dc
Compare
Warning Review the following alerts detected in dependencies. According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.
|
1b60f1d
to
c5fab18
Compare
4da0e40
to
815343f
Compare
815343f
to
1babf03
Compare
**Description:** This is the split of #11100. Since we need to add unknown variants to the ast enum, this requires a lot of code changes to handle non-exhaustive matches. I'm doing this in a separate PR for review.
1babf03
to
9d04340
Compare
This also requires a serialization test, include unknown variants. Since I'm busy with other work, it will be a little slower. |
c736814
to
46b5ab6
Compare
46b5ab6
to
1e3d7b1
Compare
1e3d7b1
to
4a0d775
Compare
move to ast_node make encoding-impl optional fix fmt make css_ast fix tuple fix unknown fix fmt make html_ast make xml_ast make jsdoc fix fmt fix unit tag update visit fix parser make regexp_ast no unknown fix snap fix arbitrary encoding: ignore unknown field fix cfg
4a0d775
to
041a36d
Compare
Description:
Following our previous discussion, I am trying to introduce a self-describing serialization encoding for ast to replace #11069 .
Since
serde
is currently used for json serialization, it is hard to modify serde to support both json and binary encodings (due to theuntagged
andflatten
attr). So I made our ownEncode
andDecode
proc macro, which also facilitate unknown variant support.I've done some simple benchmarks with a modified swc ast, and I believe we don't have an unacceptable performance loss relative to
rkyv
.I'm using
cbor4ii
here, which I developed, so I'd prefer it if there's no performance difference. but it's easy to migrate tobincode
or other scheme.This also introduces an
unknown
feature forecma_ast
crate, which should only be enabled by the wasm plugin to ensure that old plugins can decode new AST.BREAKING CHANGE:
This PR itself only introduces new encoding and will not cause any breakage. However, it may cause breakage when switch the wasm plugin communication scheme in future.
Related issue (if exists):