rustup won't force-skip unavailable `rust-std` for targets specified through `rust-toolchain.toml`

[Pizza989]

Problem you are trying to solve

I have a no_std project that uses a custom target and the rust-toolchain.toml file. I have specified the custom target with the toolchain.targets key of the rust-toolchain.toml file. I have uninstalled all toolchains at this point so when i run cargo commands rustup tries installing one according to the config file, however this will always fail because rust-std doesn't exist for the custom target.

error: component 'rust-std' for target '<custom_target>' is unavailable for download for channel 'stable'
If you don't need the component, you could try a minimal installation with:

    rustup toolchain add stable --profile minimal

If you require these components, please install and use the latest successful build version,
which you can find at <https://rust-lang.github.io/rustup-components-history>.

After determining the correct date, install it with a command such as:

    rustup toolchain install nightly-2018-12-27

Then you can use the toolchain with commands such as:

    cargo +nightly-2018-12-27 build

The workaround for this is to install the toolchain for the host target first. Then, when running a cargo command, it will now say: warning: Force-skipping unavailable component 'rust-std-<custom_target> but proceed with the installation of i.e. extra components anyways. Finally it won't be an issue because it's a no_std environment anyways.

Solution you'd like

I would like a flag to disable the rust-std component from the rust-toolchain.toml file as in this particular use-case, human intervention might not be wanted if it runs as part of CI or similar.

Notes

If someone implements this enhancement i will suggest updating the hint it gives in the first error message i included where it tells you to set the profile to "minimal" since that will still include rust-std

[cachebag]

@rustbot claim

[rami3l]

@Pizza989 Thanks for reporting!

I am sorry, but I'm not completely clear about your use case.

What is this custom target to be precise? Why would you want to specify it in rust-toolchain.toml?

[tage64]

I had a similar usecase where I wanted to use the sparc-unknown-none-elf target for a project. It makes sence to specify it in rust-toolchain.toml because then the user doesn't have to add the toolchain with rustup manually.

[rami3l]

@tage64 Thanks! I'll have a deeper look at this to see if this is a bug in the codebase or an enhancement is required.

[rami3l]

@cachebag I think this can be considered a bug.

Could you find a way to port the force-skipping logic to the installation process directed by rust-toolchain.toml?

[cachebag]

@rami3l

I finished wiring up the skip_std path in ToolchainSection and propagated it through ensure_installed. I want to confirm the scope because I feel like I've touched a lot of places in the code base with this.

Do you want skip_std to completely bypass std component fetch/unpack or only prevent its auto-installation during profile resolution? Also, the way I initially wrote this, I dropped in skip_std to Cfg::ensure_installed which triggered Clippy (too_many_arguments).

I feel like I might have overthought this. Curious if you have any thoughts before I go any further.

[djc]

@cachebag suggest submitting a (draft) PR so we can look at the code a bit.

[rami3l]

Okay, so the root cause seems to be that we are throwing the RequestedComponentsUnavailable error as expected but we have caught it in one place but not in another. That explains the difference in behavior.

[rami3l]

@Pizza989 @djc @cachebag So the thing is, this behavior is controlled by the --force flag when running rustup toolchain install.

However, if RUSTUP_AUTO_INSTALL is enabled, there is no way to specify the value of this flag during auto installation which is turned off by default when using that setting. Of course this can be turned on by default instead, but that'll need some more discussions.

Also, it can be argued that the fact that @cachebag didn't find the flag in the first place has indicated insufficient documentation and so on. Any relevant effort to improve this situation is encouraged.

This can be another example against auto installation in #4211.