Rust: no_std support

[nazar-pc]

I wanted to implement no_std support, but it turned out that working with the Rust crate is a bit inconvenient, so I did it more Rust-y first. bindings/rust/blst is a symlink, just like publishing code was creating, but now it is in the repo and doesn't require dirty flag for publishing which has an opportunity to include unwanted changes.

Commits are individually meaningful, they all compile and pass all CI checks. If you disagree with any of them, I can remove corresponding change.

In the end what we get is no_std support in Rust bindings. Let me know if you want me to bump patch version as well.

There is one breaking change though: print_bytes function that was not used anywhere was removed, but it was public, so if someone used it (highly unlikely) then their code will stop compiling.

[dot-asm]

Is it reasonable to provide limited interface in no-std build? Formally speaking it should be. As no-std platforms are customarily tailored for a specific task. For example a HSM would only need the signing operation. The reason I ask is obviously do-only-what-s-actually-necessary principle. With this in mind one can simply mask parallelized methods... Or in other words what is that it you need. One of the references mentions kzg, so ... point operations and MSM?

[nazar-pc]

Why provide limited interface instead of full if full is possible without any issues? I don't get it. Compiler with optimize unused code away automatically if that is a concern.

[dot-asm]

I'm taking slightly different approach in #153.

[nazar-pc]

Could you provide some description here or there what is the difference and why is it better than this? Because this PR provides too% of the API and is fully backwards compatible. #153 seems to just drop a disable a bunch of things that depend on standard library instead of making an effort to expose them (which is not difficult).

[nazar-pc]

BTW, would it be helpful if I extract first few commits into a separate PR? It is really inconvenient to deal with. Doesn't feel like Rust at all.

[ec2]

Hey @nazar-pc ! You're super close to actual no_std here! One thing left is to make sure that when building with no-thread that threadpool does not get pull in as a dependency in the Cargo.toml. In particular,

[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
threadpool = "^1.8.1"

still gets pulled in when building on non-wasm no_std.

[ec2]

Also would be great for when compiling to environments where target os is none, that you also add the -ffreestanding flag as well and not just for wasm

[nazar-pc]

I'd change how it is compiled for different targets completely, but Andy has a different opinion on how it should work. So far it doesn't seem very likely that we'll see it "just work" in the way Rust users expect crates in the ecosystem to work.

[ec2]

Hmm. Okay... Well just for context, with this PR, I can truly build for no_std now. I've tested it on mips32 baremetal. I don't have too much of an opinion of how no_std should be done here :)

[dot-asm]

it doesn't seem very likely that we'll see it "just work" in the way Rust users expect crates in the ecosystem to work.

I obviously disagree:-) #153 just works. The way it internally achieves the goal might not fulfill your specific expectations, but it doesn't mean that adding the dependency and building your project doesn't work(*). Ultimately it's about what we are willing to stand behind and support, which is about a) what is actually confirmed to work (no hypotheticals), b) the number of possible combinations (which we want to minimize).

[As for not being "like others." I for one am inclined to argue that wider adoption of build scripts would result in more projects not being "like others."]

(*) Modulo few missing functions for the time being.