**Description:**
This adds the ability to not include `ahash` with swc_common, which
caused some issues for me compiling dprint-plugin-typescript to Wasm
because of:
```
Compiling ahash v0.8.3
Compiling getrandom v0.2.10
error: the wasm*-unknown-unknown targets are not supported by default, you may need to enable the "js" feature. For more information see: https://docs.rs/getrandom/#webassembly-support
--> C:\Users\david\.cargo\registry\src\index.crates.io-6f17d22bba15001f\getrandom-0.2.10\src\lib.rs:285:9
|
285 | / compile_error!("the wasm*-unknown-unknown targets are not supported by \
286 | | default, you may need to enable the \"js\" feature. \
287 | | For more information see: \
288 | | https://docs.rs/getrandom/#webassembly-support");
| |________________________________________________________________________^
```
(I can't enable the JS feature because it's running the wasm file in
Wasmer and also I don't support Wasi in dprint plugins)
**BREAKING CHANGE:**
This removes swc_common's "perf" feature and makes it the default, then
adds an `ahash` feature instead. An alternative would be to make the
`ahash` dep optional and part of the default features, then do
`default-features = false` in the downstream crates (I think, but I'm
not sure), but I figure most people will be using the perf default
anyway? I'm not sure what's preferable.
**Related issue:**
- Closes#7729.
**Description:**
For crates using both `rkyv` and `swc`, where ast nodes from
`swc_ecma_ast` are included in data that's serialized with `rkyv`, it's
difficult to access the archived data from the archived ast nodes since
the types are private.
More context in the issue.
**Related issue:**
- Closes#7810.
**Description:**
Second attempt to enable bytecheck. This PR does not have versioned struct yet, just enabling bytecheck wherever possible. Also, it is for the ast only yet, so transform metadata and others might need this later.
PR seems to be passing all the ci, but as we've experienced before, there might be some unexpected outcomes with the release. Maybe better to hold this until clear https://github.com/swc-project/swc/issues/7238, then land as a separate release.
**Description:**
Attempt to workaround #7238.
Originally I thought this is related with oom or memory layout, then realized actual deserialization error occurs in weird position - it tries to deserialize BytePos (which is obvious type) and it fails. It made me think maybe a property next to the struct layout have some unexpected behavior, notably Arc<String>.
PR applies same workaround as Atom does, and it seems to at least pass swc-coverage-instrument's usecases. May need bit more verification with other plugins to see if we can call this out as reliable workaround.
