Hint that a new Rust release may be available#4869
Open
FranciscoTGouveia wants to merge 2 commits into
Open
Conversation
rami3l
reviewed
May 24, 2026
rami3l
reviewed
May 24, 2026
0679b12 to
f9a9d91
Compare
djc
reviewed
Jun 1, 2026
This comment has been minimized.
This comment has been minimized.
f9a9d91 to
bebc2bf
Compare
djc
reviewed
Jun 23, 2026
rami3l
reviewed
Jun 23, 2026
b64ea36 to
33eae97
Compare
rami3l
reviewed
Jun 30, 2026
| if !utils::is_file(&self.path) { | ||
| return Ok(State::default()); | ||
| } | ||
| let content = utils::read_file("state", &self.path)?; |
Member
There was a problem hiding this comment.
Note: Pre-existing and not directly related to this new feature, but we might need to introduce File::lock*() in this pattern, otherwise this file risks getting corrupted and if that happens, rustup will get crazy.
This doesn't happen yet because the update of settings.toml is not automatic yet.
rami3l
reviewed
Jun 30, 2026
33eae97 to
58ad136
Compare
djc
reviewed
Jul 1, 2026
58ad136 to
b9afdd1
Compare
This comment has been minimized.
This comment has been minimized.
52c7878 to
4400790
Compare
4400790 to
b4a55d1
Compare
Collaborator
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
b4a55d1 to
a3e9eb0
Compare
djc
approved these changes
Jul 3, 2026
| #[cfg(unix)] | ||
| pub(crate) const UNIX_FALLBACK_SETTINGS: &str = "/etc/rustup/settings.toml"; | ||
|
|
||
| /// Contrary to `settings.toml`, this file is not intended to be user-facing |
Contributor
There was a problem hiding this comment.
Nit: top-down style, this should go below Cfg.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #4846.
After a rustup command completes (excluding proxy commands), rustup checks whether a new Rust release is available.
To avoid introducing any additional overhead, this feature does not communicate with the release server.
Instead, it checks whether the stable toolchain manifest date is more than six weeks old.
Since Rust follows a regular and predictable release cadence, this should provide a sufficiently accurate indication that a new release is available.
When an outdated stable toolchain is detected, rustup prints a hint suggesting that the user may update their stable toolchain; this hint is shown at most once per day.
Users who prefer not to receive these hints can opt out by setting the
RUSTUP_NO_RELEASE_HINTenvironment variable.I have run some benchmarks (100 iterations) for the
rustup showcommand and observed no significant slowdown (1.1x) when we do not show the hint.However, due to manifest parsing, there is a 1.4x slowdown when the hint is shown (once per day).
Feedback is appreciated on: