github/cranelift - cranelift - Gitea: Git with home nas server

Author	SHA1	Message	Date
Alex Crichton	39ea64140f	Expand doc section about "what about `#![no_std]`?" (#2024 ) * Expand doc section about "what about `#![no_std]`?" This commit expands the `#![no_std]` section of the documentation with an FAQ-style set of words which explains in more detail about why we don't support `#![no_std]` at this time, and how we can support it in the future. * Review comments * Add some more words about -Zbuild-std	4 years ago
Alex Crichton	806d197472	Update platform support docs (#2023 ) Be sure to mention Linux AArch64 as a supported platform of Wasmtime now.	4 years ago
Alex Crichton	39e57e3e9a	Migrate back to `std::` stylistically (#554 ) * 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	5 years ago
Alex Crichton	bf526b62d3	Add book documentation skeleton and auto-publish from CI (#435 ) This commit adds the skeleton of a new set of documentation for `wasmtime` in the existing `docs` directory. This documentation is organized and compiled with [mdbook] which the Rust project uses for most of its own documentation as well. At a previous meeting we brainstormed a rough skeleton of what the documentation in this book would look like, and I've transcribed that here for an example of how this is rendered and how it can be laid out. No actual documentation is written yet. This commit also additionally adds necessary support to auto-publish both this book documentation and API documentation every time a commit is pushed to the `master` branch. All HTML will be automatically pushed to the `gh-pages` branch so long as the CI passes, and this should get deployed to https://cranestation.github.io/wasmtime. I've done a few dry-runs and I think this'll all work, but we'll likely tweak a few things here and there after running this through CI to make sure everything looks just as we'd like. My hope though is that after this lands we can start actually filling out all the documentation and being able to review it as well. [mdbook]: https://crates.io/crates/mdbook	5 years ago