With Rust 2018 Edition, the `mod std` trick to alias `core` names to `std` no longer works, so switch to just having the code use `core` explicitly. So instead, switch to just using `core::*` for things that in core. This is more consistent with other Rust no_std code. And it allows us to enable `no_std` mode unconditionally in the crates that support it, which makes testing a little easier. There actually three cases: - For things in std and also in core, like `cmp`: Just use them via `core::*`. - For things in std and also in alloc, like `Vec`: Import alloc as std, as use them from std. This allows them to work on both stable (which doesn't provide alloc, but we don't support no_std mode anyway) and nightly. - For HashMap and similar which are not in core or alloc, import them in the top-level lib.rs files from either std or the third-party hashmap_core crate, and then have the code use super::hashmap_core. Also, no_std support continues to be "best effort" at this time and not something most people need to be testing.
This crate provides module-level functionality, which allow multiple functions and data to be emitted with Cranelift and then linked together.
This crate is structured as an optional layer on top of cranelift-codegen. It provides additional functionality, such as linking, however users that require greater flexibility don't need to use it.
A Module is a collection of functions and data objects that are linked
together. Backend is a trait that defines an interface for backends
that compile modules into various forms. Most users will use one of the
following Backend implementations:
SimpleJITBackend, provided by cranelift-simplejit, which JITs code to memory for direct execution.FaerieBackend, provided by cranelift-faerie, which emits native object files.