Support no_std in the wasmparser crate
#1493
Conversation
|
I really like this direction! One thing that I did in the The biggest downside is that the |
|
I filled out a bit more information about hashers at bytecodealliance/wasmtime#8341 (comment) inspired by your comment, thanks for bringing it up! If possible I'd prefer to keep hash maps as foundational data structures and avoid switching data structures just based on no-std. I think that the utilities provided by |
|
I've updated this to be a landable version for bytecodealliance/wasmtime#8341. This now includes CI checks and a bit more documentation. |
This commit adds a `std` feature to the `wasmparser` crate, enables it by default, and then enables building the crate when the feature is disabled. This works by switching imports of `wasmparser` from `std` to either the `core` or `alloc` crates which are available in the `no_std` context. The main change made in this PR is that maps used by `wasmparser`, e.g. `HashMap` and `IndexMap`, are now abstracted with type aliases in `wasmparser` which unconditionally customize a hash algorithm parameter. When the `std` feature is enabled this parameter is implemented using the standard library's default hashing algorithm. When `std` is disabled then this uses the `ahash` crate internally. This commit additionally updates CI to both check that wasmparser builds when the `std` feature is disabled and that it builds on a target without `std`.
| // When the `std` feature is NOT active then rely on `ahash::RandomState`. That | ||
| // relies on ASLR by default for randomness. | ||
| #[derive(Default, Clone, Debug)] | ||
| #[cfg(not(feature = "std"))] | ||
| struct RandomStateImpl; | ||
|
|
||
| #[cfg(not(feature = "std"))] | ||
| impl BuildHasher for RandomStateImpl { | ||
| type Hasher = ahash::AHasher; | ||
|
|
||
| #[inline] | ||
| fn build_hasher(&self) -> ahash::AHasher { | ||
| ahash::RandomState::new().build_hasher() | ||
| } | ||
| } |
There was a problem hiding this comment.
Does it make sense expose a method for manually setting the random state for nostd users that happen to have some source of randomness we don't (and can't) know about?
There was a problem hiding this comment.
This is sort of already handled by the ahash crate itself although that's not quite the same as providing it through wasmparser itself. My thinking is given that this is going to be shared across Wasmtime and wasmparser it might be best to leave this to ahash for now and add it here if necessary in the future
This commit adds a
stdfeature to thewasmparsercrate, enables itby default, and then enables building the crate when the feature is
disabled. This works by switching imports of
wasmparserfromstdtoeither the
coreoralloccrates which are available in theno_stdcontext. The main change made in this PR is that maps used by
wasmparser, e.g.HashMapandIndexMap, are now abstracted withtype aliases in
wasmparserwhich unconditionally customize a hashalgorithm parameter. When the
stdfeature is enabled this parameter isimplemented using the standard library's default hashing algorithm. When
stdis disabled then this uses theahashcrate internally.This commit additionally updates CI to both check that wasmparser builds
when the
stdfeature is disabled and that it builds on a targetwithout
std.