rustup should use the configured profile as fallback when the key is not present in `rust-toolchain.toml` about rustup HOT 5 OPEN

@polarathene Thanks for your in-depth investigation! I believe this is covered by #3483 as you've already found out, and no, that design is not intentional; I even believe my #3492 has fixed it.

Unfortunately, the inclusion of that patch hasn't been moving forward for a very specific reason: hierarchical config will introduce new attack vectors if one or serveral rust-toolchain.toml files can't be trusted. Due to the limited bandwidth of the Rustup team, all relevant work is suspended until we come up with a solution to that issue before pushing the hierarchical config proposal forward again. At this point I'm as sad as you are, sorry 🙇

from rustup.

If the contribution doesn't sound too troublesome and would get approval, I can give it a shot?

@polarathene Wait, you reminded me of something. Maybe my #3492 can be carefully cherry-picked into two parts. I do remember some commits are related to rust-toolchain.toml while others aren't.

So in theory you can use (or get inspired from) half of my PR (so without the rust-toolchain.toml filesystem walk hierarchy part), make sure that the default toolchain (incl. profile, channel, etc.) is working as you'd expect, add a bunch of smoke tests, adjust the docs accordingly (mentioning the limitations) and call it a day. The rest of that PR will be merged later...

As long as @rbtcollins agrees with that plan.

Anyway, that PR is on our v1.28 milestone (meaning we have to at least react to it in some way), so I'm not going anywhere.

from rustup.

The rustup docs imply that it should be using the configured minimal profile as fallback:

Note that if not specified, the default profile is not necessarily used, as a different default profile might have been set with rustup set profile.

from rustup.

@polarathene OTOH I'm open to doc improvements, although I'm not sure if we're documenting a bug. Maybe calling it a limitation would be better.

If you can come up with a PR, I'll be glad to review it 🙏

from rustup.

TL;DR: I could adjust the docs.. however fixing the regression introduced (specifically to profile support) instead may be fairly simple AFAIK? If that'd be acceptable, I don't mind contributing that instead?

Unfortunately, the inclusion of that patch hasn't been moving forward for a very specific reason: hierarchical config will introduce new attack vectors if one or serveral rust-toolchain.toml files can't be trusted

So to clarify:

• bug: Despite the current documentation for rust-toolchain.toml support with rustup, the setting profile configured for rustup is ignored when this file is present and a toolchain is installed?
• This rust-toolchain.toml feature appears to have broken the global behaviour (as described in the original feature request), so this is technically a regression.
• Fixing this bug requires a more complicated PR with wider impact to be approved and merged, but is blocked due to security concerns that imposes, and the limited bandwidth available from maintainers for the foreseeable future to tackle that PR?

Is it not possible to fix the regression introduced specifically with profile?

• If my rustup has a profile configured globally as minimal, it should respect that when it's not present in rust-toolchain.toml, as it previously did.
• Since the referenced PR with it's improvements that could fix this concern introduces too much friction, perhaps this specific use-case can be resolved separately?

I'd rather address that than correct the docs with the existing gotcha. If the contribution doesn't sound too troublesome and would get approval, I can give it a shot?

• Presumably when profile is None after parsing rust-toolchain.toml, it just needs to additionally check for a profile key in ~/.rustup/settings.toml as a fallback?
• This would prevent the mishap of excessive disk usage (and network bandwidth wasted for both parties involved) which sounds like a win. I don't see any security concerns with allowing to fallback to the expected profile configured for rustup?

from rustup.