After landing of this PR:
Rust std for WASI will be mostly libc-free. It's relatively easy to remove the remaining uses, but it will hurt interoperability with non-Rust code, so we will have to use a separate target if we want it (e.g. wasm32-wasi-rust, with target_env equal to rust). Introducing such target will allow us to minimize size of pure-Rust WASI applications by completely removing libc, also it may be a good test before introducing a hypothetical libc-free Linux target.
List of libc functions under question:
__wasilibc_find_relpath: uses a map of preopened fiel descriptors to their path which is kept by libc.
exit, abort: since WASI does not have a proper signal handling can be replaced by wasi::proc_exit.
Rather than making it completely bereft of any libc, what about implementing libc-compatible functions in Rust, so that other languages can interoperate?
I've seen proposals to do the same thing for the libc-free Linux target.
Shouldn't it be e.g. wasi-unknown-unknown and wasi-unknown-libc? (Or otherwise similarly; unknown-unknown knows and guarantees nothing about the platform.)
I know I'm definitely at least somewhat interested in pure-Rust wasi projects, which would then benefit from the removal of libc in terms of size and not hurt for it.
The vendor part was dropped in this PR. I guess correct names for WASI targets should be something like wasm32-wasi-libc (or wasm32-wasi-musl, since WASI libc is based on musl) and wasm32-wasi-rust.
While you could theoretically re-implement crt1.c, libpreopen, etc., in Rust and eliminate libc entirely, this is code which will very likely be evolving as WASI evolves, so with my WASI maintenance hat on, I'm concerned that this would increase the overhead of making changes right now.