rustup-init creates a new settings.toml file then warns about it existing

[ChrisDenton]

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue and found no duplicates.
• I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

Not sure how I missed this in the betas (warning blindness?) but on a fresh install of rustup, rustup-init shows the following:

warn: It looks like you have an existing rustup settings file at:
warn: C:\Users\UtilityAccount\.rustup\settings.toml
warn: Rustup will install the default toolchain as specified in the settings file,
warn: instead of the one inferred from the default host triple.

Steps

1. create a clean environment with no rustup directories
2. run rustup-init

Possible Solution(s)

No response

Notes

This happens because of:

rustup/src/cli/setup_mode.rs

Lines 133 to 134 in c43b0e7

	let mut cfg = Cfg::from_env(current_dir, quiet, process)?;
	self_update::install(no_prompt, opts, &mut cfg).await

We ensure a cfg exists and then run the install, which checks for an existing cfg.

Rustup version

rustup-init 1.29.0 (28d1352db 2026-03-05)

Installed toolchains

n/a

OS version

Windows 11

[rami3l]

@ChrisDenton Yeah I remember this one, old behavior from #4064.

I think this was allowed but worth notifying, given that the original context was to reinstall rustup after migrating from x64 macOS to ARM64, so the old one clearly doesn't (and shouldn't) count.

Should we be stricter/clearer/providing a choice?

[ChrisDenton]

I think the idea of the check is ok. If you're reinstalling then chances are you want the defaults again (e.g. maybe recovering from a bad install) but it is worth highlighting this. In interactive mode the user will be override anyway.

I only take issue with printing a warning when it didn't exist before the install.

[ChrisDenton]

Though thinking about it, maybe it could check if the toolchain in settings.toml is the same as what would have been inferred anyway and skip the warning in that case.

[rami3l]

Though thinking about it, maybe it could check if the toolchain in settings.toml is the same as what would have been inferred anyway and skip the warning in that case.

@ChrisDenton Good catch! What fish-shell does in such occasions is that (in our terms) it renames the old file to say settings.toml.bak and then regenerates the new stuff at the old place. I think that'd make more sense in our case in addition to your small optimization, combined with proper logging adjustments of course...

@FranciscoTGouveia What do you think?

[FranciscoTGouveia]

I believe there are two main things to do here, although I may be overlooking something.

Refrain from printing the warning if:

1. There is no settings.toml file prior to rustup-init.
2. The default toolchain specified in settings.toml is the same that would have been inferred.

If we adopted fish's strategy, what would happen to the .bak file after running rustup-init?
Would it be left there so the user can copy it to settings.toml to restore their defaults?

[ChrisDenton]

I believe there are two main things to do here, although I may be overlooking something.

Refrain from printing the warning if:

1. There is no settings.toml file prior to rustup-init.
2. The default toolchain specified in settings.toml is the same that would have been inferred.

That sounds right to me; I don't think you're missing anything. To be extremely pedantic there's also the case where settings.toml exists but doesn't specify a toolchain at all. But that's essentially a special case of 2.

If we adopted fish's strategy, what would happen to the .bak file after running rustup-init?
Would it be left there so the user can copy it to settings.toml to restore their defaults?

I think that's @rami3l's intent. And there's also the case of what happens when a settings.bak file already exists (we could either overwrite it or add a counter or datetime to the filename).