Can `rustc-dev` be made available for the `wasm32-unknown-unknown` target?

[thomaseizinger]

This is a follow-up issue of rust-lang/rustfmt#4845.

In summary: It was previously possible to compile rustfmt on wasm32-unknown-unknown. With the switch to rustfmt depending on rustc-dev instead of the ap-* crates from crates.io, this is no longer possible because the rustc-dev component is not available for wasm32-unknown-unknown.

Is it feasible to make rustc-dev available for wasm32-unknown-unknown? Rustfmt only consumes some of the crates available through rustc-dev:

extern crate rustc_ast;
extern crate rustc_ast_pretty;
extern crate rustc_data_structures;
extern crate rustc_errors;
extern crate rustc_expand;
extern crate rustc_parse;
extern crate rustc_session;

Unless a component needs to be fully supported on a platform in order to be shipped with rustup, we could conditionally expose only those crates that actually compile on wasm32-unknown-unknown.

I don't know what the best path forward is here. The overall motivation for compiling rustfmt to wasm32-unknown-unknown is to move the dprint plugin back from a process plugin to a wasm plugin that is properly sandboxed.

[inquisitivecrystal]

@rustbot label +O-wasm +T-compiler

[Mark-Simulacrum]

wasm32 is not a target we build the compiler toolchain currently. I am not sure it makes sense to do so, but if you would like to make a proposal to do so, the place to start is https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html (tier 2 with host tools). It is already a tier 2 target, but as it was previously existent at that tier, we should document the tier 3 and tier 2 requirements as well.

[thomaseizinger]

wasm32 is not a target we build the compiler toolchain currently. I am not sure it makes sense to do so, but if you would like to make a proposal to do so, the place to start is doc.rust-lang.org/nightly/rustc/target-tier-policy.html (tier 2 with host tools). It is already a tier 2 target, but as it was previously existent at that tier, we should document the tier 3 and tier 2 requirements as well.

Thanks, that is a good starting point! I will dig into that.

[HKalbasi]

rustc, rustfmt and clippy are useful in playgrounds and educational tools that are browser-based. It also can be useful to run rustc and tools in wasm based sandboxes such as cloudflare workers or fastly serverless for CI proposes. So I think it would meet the tier 2 with host tools criteria.

@thomaseizinger Are you still interested in this?
@Mark-Simulacrum Is there any example of such a proposal?

[thomaseizinger]

@thomaseizinger Are you still interested in this?

I am yes. My usecase is to allow https://github.com/dprint/dprint-plugin-rustfmt to be compiled to WASM again. At the moment, the plugin works by executing the native rustfmt binary although it would be much nicer if it would run in the WASM sandbox again.

That being said, it is not a blocker per se which is why I couldn't invest any resources so far.