rules_rust VS wg-allocators

The same reason Bazel builds avoid using Cargo when building Rust software, so I'll describe why Bazel would do this:

- Bazel wants to cache remote resources, like each respective crate's source files.

- Bazel then wants to build each crate in a sandbox, and cache the build artifacts

This is an established practice, and Nix wants to drive the build for the same reasons.

See:

- https://github.com/bazelbuild/rules_rust

- https://github.com/google/cargo-raze

To answer your question, I don't know if Soong or Bazel can reuse the files produced by an incremental Rust compilation. I tried searching the rules_rust repository and found some discussions, but nothing that clearly told me "Yes, this is supported".

Bazel doesn't allow targeting a lot of platforms (especially embedded) from Rust, even when the Rust ecosystem supports these targets. Something is off with its design if new work needs to be done for every platform that's already available behind an interface that's as consistent as what rustc gives.

What is supported needs to be inferred from this file, as far as I can tell: https://github.com/bazelbuild/rules_rust/blob/main/rust/plat...

You might be overjoyed to learn that you can use a build tool that forces you to manually write out the dependencies between each file.

I am using rules_rust and have the VS Code Bazel plugin installed, but I am still not getting autocomplete.

Other than that, the performance of both for builds should be determined exactly by the organization of code into separate crates and the rustc invocations. Bazel generally encourages smaller crates, but that's very subtle. There is at least 1 case I can think of where rustc is overfit to cargo, in a way that is not easily replicable by bazel, which is the metadata/rlib pipelining https://github.com/bazelbuild/rules_rust/issues/228

Rust integrates pretty seamlessly into Bazel projects via rules_rust (https://github.com/bazelbuild/rules_rust). The existing rules even allow for c calling rust and rust calling c. Example: https://github.com/bazelbuild/rules_rust/blob/main/examples/...

With any compiled language you can use the compiler and vendor your dependencies instead of using the language's conventional package manager. For example, nothing prevents skipping Cargo and building Rust directly with rustc the way Bazel does.

https://github.com/bazelbuild/rules_rust

Tracking issue for Storages, and a TLDR on what it is

I must have gotten confused, since from your brief discussion with CAD97 it seemed like there was a way for the concepts to live separately and that Storage could complicate things in comparison. But if implementing Allocator in terms of Storage is basically equivalent and Storage is flexible enough that I could write one to pass memory out to unsafe code, that works just as well.

https://rust-lang.github.io/rfcs/1974-global-allocators.html was the original RFC.

My vague understanding is that there's a working group https://github.com/rust-lang/wg-allocators

The further I get from working on Rust day to day, the less I know about these things, so that's all I've got for you.

If you self-reference using pointers and guarantee the struct will never move, you don't even need unsafe. If you self-reference using offsets from the struct's base pointer, you need a splash of unsafe but your struct can be freely moved without invalidating its self-referential "pointers".

Per-struct allocators are a work in progress (see https://github.com/rust-lang/wg-allocators/issues/48).

Not sure what "non thread local addresses" means, but in my experience Rust is pretty good at sending data between threads (without moving it).

Besides that allocation is not really a problem for no_std. It's resolved by using alloc crate directly, so anything usable with custom allocators is supported. Example in dasp sources - https://github.com/RustAudio/dasp/blob/master/dasp_slice/src/boxed.rs#L14-L19 . Also worth looking at this issue to check what is usable already - https://github.com/rust-lang/wg-allocators/issues/7

But that's on track for rust as well: https://github.com/rust-lang/wg-allocators/issues/7

Here: https://github.com/rust-lang/rfcs/pull/1398. there is also a working group for this: https://github.com/rust-lang/wg-allocators.

It's unstable. wg-allocators contains discussions about design and a tracking issue for collections that need an allocator https://github.com/rust-lang/wg-allocators/issues/7