Fail early when trying to build for an unavailable target

[rivnakm]

Problem

If trying to build for a target, wasm32-unknown-unknown, for example, and the target is not installed with rustup, cargo will still attempt to build and throw lots of errors which don't have an obvious cause. These are rustc mostly being unable to find items from the standard library.

Proposed Solution

It would be helpful for cargo to check that the correct target toolchain is available and provide and appropriate error message.

Notes

I imagine this isn't an issue for no_std crates, but since that is resolved at the crate level beforehand it should be feasible for cargo to make that determination.

[rivnakm]

Also, specifying a target in the rust-toolchain.toml file will automatically download the target when you run cargo build so perhaps cargo could do the same when specifying a target via the command line.

[weihanglo]

On a vacation so the reply may be quite shallow.

Also, specifying a target in the rust-toolchain.toml file will automatically download the target when you run cargo build so perhaps cargo could do the same when specifying a target via the command line.

In this case, the download is done by rustup. cargo being called is actually a wrapper (aka proxy) provided by rustup, and then rustup delegates to the real cargo binary. On this point, Cargo doesn't know whether a platform target is available or not.

Even if a target is installed and available, it can still fail during the compilation when some system tools are missing. For example, rustc can build wasm32-unknown-emscripten very well until it needs emcc to link to other C libs. Checking the availbility of a target is not sufficient to ensure a platform target to build.

I don't have a good idea for now, but always welcome any improvement in error messages.

[epage]

When you add a target, that just means rust-std is installed. We still call into the same compiler. So this likely being discovered late in the build process when it sees you using features and can't find what to link against. I suspect that improving the error message would be something rustc would have to do, if it can even do it.

As for cargo vs rustup, something to add to the above is all of this needs to work without rustup as that is an optional package. Even if we made it required there are restrictions on what we could do within certain environments the Rust project targets that we would have to carefully evaluate.

[rivnakm]

Thank you for your responses. I think minimally it would be nice to have the rustup cargo proxy handle the --target option the same as it does for targets in rust-toolchain.toml. As for a warning in the build process yeah it seems like that would just be a rustc thing then, and a special case for rust-std.