@@ -74,11 +74,10 @@ raised about `#![no_std]`:
74
74
WebAssembly runtime than switching a few crates, however. Maintaining a
75
75
` #![no_std] ` library over time has a number of costs associated with it:
76
76
77
- * There needs to be CI to ensure that when compiled with the right flags the
78
- library does not actually use the Rust standard library. Currently there is
79
- no stable way to do this in Rust, meaning that although a library may be
80
- ` #![no_std] ` at one point in time it's easy to add a dependency that
81
- accidentally sneaks in the ` std ` crate later.
77
+ * Rust has no stable way to diagnose ` no_std ` errors in an otherwise ` std `
78
+ build, which means that to supoprt this feature it must be tested on CI with
79
+ a ` no_std ` target. This is costly in terms of CI time, CI maintenance, and
80
+ developers having to do extra builds to avoid CI errors.
82
81
83
82
* Idioms in ` #![no_std] ` are quite different than normal Rust code. You'll
84
83
import from different crates (` core ` instead of ` std ` ) and data structures
@@ -103,9 +102,7 @@ raised about `#![no_std]`:
103
102
are very much aware of this! Wasmtime is intended to be configurable where
104
103
many of these features are compile-time or runtime options. For example caches
105
104
can be disabled, JITs can be removed and replaced with interpreters, or users
106
- could provide a callback to allocate memory instead of using the OS. The
107
- ambitious goals of Wasmtime take time and energy to implement, however, so we
108
- need help from others in order to prioritize what's most important to tackle.
105
+ could provide a callback to allocate memory instead of using the OS.
109
106
This is sort of a long-winded way of saying that Wasmtime on the surface may
110
107
today look like it won't support ` #![no_std] ` , but this is almost always
111
108
simply a matter of time and development priorities rather than a fundamental
0 commit comments