no_std support in the Rust guest bindings.

[sunfishcode]

This adds no_std support in the Rust guest bindings. Mostly this involves using core and alloc instead of std, but it also involves adding extern crate alloc; in a few places, and also adding a "std" cargo feature to gen-guest-rust so that the impl std::error::Error can be made conditional.

This will eventually be useful for generating bindings from the WASI wit files for std itself to use. And, it's useful for experimenting with generating minimal bindings.

[alexcrichton]

I think this is reasonable to land for implementing the standard library itself but I'm wary about the "no_std support" moniker since that seems to equate to "I want to compile for embedded things which don't have access to libstd" which doesn't make sense for wasm since libstd is always there.

In terms of organization could most of the references to the alloc trait be pushed into the runtime crate? I'd rather not generate a lot of extern crate alloc; all over the place in the generated code an hygienically referring to alloc through the runtime crate seems beneficial anyway. Otherwise though referencing core::* items seems reasonable to me.

[sunfishcode]

I think this is reasonable to land for implementing the standard library itself but I'm wary about the "no_std support" moniker since that seems to equate to "I want to compile for embedded things which don't have access to libstd" which doesn't make sense for wasm since libstd is always there.

Right; the use cases I'm looking at are: ways to build highly specialized polyfills that don't work like regular modules, and eventually, building std.

In terms of organization could most of the references to the alloc trait be pushed into the runtime crate? I'd rather not generate a lot of extern crate alloc; all over the place in the generated code an hygienically referring to alloc through the runtime crate seems beneficial anyway. Otherwise though referencing core::* items seems reasonable to me.

I've now factored out all the extern crate alloc;s into the runtime crate.

[alexcrichton]

Reading over this again, I think a compile-time option may not be the best way to shoehorn this feature for the code generators. Could the print_typedef_enum method grow a gen_error: bool method perhaps which is threaded through? For the Wasmtime-host generator this would always pass true but for the Rust-guest generator I think it would be best to have this as a configurable Opts option which, in the proc-macro, would be configured based on a feature flag of the proc-macro itself.

[alexcrichton]

I think this would help cut down on the default-features = false traffic as well.

[sunfishcode]

Done; and yeah, it's a lot simpler that way.

[alexcrichton]

Could these move into mod rt since that's the "internal stuff exported for the macro" module? (and would also avoid the need to rename alloc to liballoc)

[sunfishcode]

Done.

[alexcrichton]

With my suggestion below it will remove the need to say default-features = false on the gen-guest-rust and gen-rust-lib crates, and with those changes is this still necessary?

I'll admit that I do wish that workspace = true, default-features = false would indeed turn off default features but alas. If that's the point of conflict you're running into I think it might be reasonable to, for that particular dependency line, avoid workspace = false

[sunfishcode]

Yes, that change got rid of all the default-features changes in this PR.