39e57e3e9a
* Migrate back to `std::` stylistically This commit moves away from idioms such as `alloc::` and `core::` as imports of standard data structures and types. Instead it migrates all crates to uniformly use `std::` for importing standard data structures and types. This also removes the `std` and `core` features from all crates to and removes any conditional checking for `feature = "std"` All of this support was previously added in #407 in an effort to make wasmtime/cranelift "`no_std` compatible". Unfortunately though this change comes at a cost: * The usage of `alloc` and `core` isn't idiomatic. Especially trying to dual between types like `HashMap` from `std` as well as from `hashbrown` causes imports to be surprising in some cases. * Unfortunately there was no CI check that crates were `no_std`, so none of them actually were. Many crates still imported from `std` or depended on crates that used `std`. It's important to note, however, that **this does not mean that wasmtime will not run in embedded environments**. The style of the code today and idioms aren't ready in Rust to support this degree of multiplexing and makes it somewhat difficult to keep up with the style of `wasmtime`. Instead it's intended that embedded runtime support will be added as necessary. Currently only `std` is necessary to build `wasmtime`, and platforms that natively need to execute `wasmtime` will need to use a Rust target that supports `std`. Note though that not all of `std` needs to be supported, but instead much of it could be configured off to return errors, and `wasmtime` would be configured to gracefully handle errors. The goal of this PR is to move `wasmtime` back to idiomatic usage of features/`std`/imports/etc and help development in the short-term. Long-term when platform concerns arise (if any) they can be addressed by moving back to `no_std` crates (but fixing the issues mentioned above) or ensuring that the target in Rust has `std` available. * Start filling out platform support doc
47 lines
1.4 KiB
Rust
47 lines
1.4 KiB
Rust
//! The core WebAssembly spec does not specify how imports are to be resolved
|
|
//! to exports. This file provides one possible way to manage multiple instances
|
|
//! and resolve imports to exports among them.
|
|
|
|
use crate::resolver::Resolver;
|
|
use std::collections::HashMap;
|
|
use wasmtime_runtime::{Export, InstanceHandle};
|
|
|
|
/// A namespace containing instances keyed by name.
|
|
///
|
|
/// Note that `Namespace` implements the `Resolver` trait, so it can resolve
|
|
/// imports using defined exports.
|
|
pub struct Namespace {
|
|
/// Mapping from identifiers to indices in `self.instances`.
|
|
names: HashMap<String, InstanceHandle>,
|
|
}
|
|
|
|
impl Namespace {
|
|
/// Construct a new `Namespace`.
|
|
pub fn new() -> Self {
|
|
Self {
|
|
names: HashMap::new(),
|
|
}
|
|
}
|
|
|
|
/// Install a new `InstanceHandle` in this `Namespace`, optionally with the
|
|
/// given name.
|
|
pub fn name_instance(&mut self, name: String, instance: InstanceHandle) {
|
|
self.names.insert(name, instance);
|
|
}
|
|
|
|
/// Get the instance registered with the given `instance_name`.
|
|
pub fn get_instance(&mut self, name: &str) -> Option<&mut InstanceHandle> {
|
|
self.names.get_mut(name)
|
|
}
|
|
}
|
|
|
|
impl Resolver for Namespace {
|
|
fn resolve(&mut self, name: &str, field: &str) -> Option<Export> {
|
|
if let Some(instance) = self.names.get_mut(name) {
|
|
instance.lookup(field)
|
|
} else {
|
|
None
|
|
}
|
|
}
|
|
}
|