Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add hint to run rustup self when err desc is self #3901

Merged
merged 2 commits into from
Jun 26, 2024

Conversation

Xerxes-2
Copy link
Contributor

@Xerxes-2 Xerxes-2 commented Jun 24, 2024

Closes #3812.

src/dist/mod.rs Outdated
Comment on lines 323 to 327
let desc_string = desc.to_string();
if desc_string.as_str() == "self" {
info!("If you meant to modify rustup itself, try run `rustup self`");
}
Err(RustupError::InvalidToolchainName(desc_string).into())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be better to do this near the top of the method? We can just check for desc == "self" and return the error immediately, which would save a bunch of work trying to parse.

Copy link
Member

@rami3l rami3l Jun 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@djc My suggestion is that since FromStr is used in many places other than update and uninstall (such as install), this will cause many false positives, and instead we should modify the value_parser for these two commands only.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But self is still invalid in all those places, right -- worst case this will provide a clearer error message?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@djc I'm afraid that will make the error message less clear. rustup install self doesn't make sense and if the info leads the user to rustup self they won't find anything related to install there.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but users are presumably also much less likely to invoke rustup install self. I still think it would be better to embed this check inside the FromStr impl where it is implicitly used in any future code that wants to consume toolchain names instead of remembering that we have to add an extra check everywhere, we can make the error message slightly more generic to make sure it doesn't lose clarity.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@djc I still feel uneasy about adding side effects in conversions like FromStr... @ChrisDenton What do you think?

Copy link
Contributor

@djc djc Jun 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would argue that logging is pretty much "unobservable" as side effects go, so while I agree that in general side effects in something like a FromStr implementations could be a bit iffy, I think logging is an exception to this.

Would you have problems with adding logging to other kinds of "pure" functions?

Copy link
Member

@rami3l rami3l Jun 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@djc Actually... it's not about purity, it's about the fact that conversions can be used in various places across the codebase, many of which are not easily detectable via call hierarchy graph rust-analyzer gives us, and I'm afraid of this potentially adding a log line somewhere unexpected. Since the very nature of this feature is to add a hint, I guess it'd be better to get the hint only when we are explicitly expecting for it.

For example, rustup uninstall uses ResolvableToolchainName, and its conversions relies on the conversions defined for PartialToolchainDesc first, and that of CustomToolchainName as a fallback. Let's say we're still using a743b3a, and it so happens that there's a custom toolchain named self, then the first conversion will definitely fail. However, before the fallback happens, the log line is already printed out.

src/cli/rustup_mode.rs Outdated Show resolved Hide resolved
src/toolchain.rs Outdated Show resolved Hide resolved
Copy link
Member

@rami3l rami3l left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! IMHO there are two things left to do:

  1. Squash all the feature changes together, as rustup encourages atomic commits, and the current changes are seemingly small enough to be squash into a single commit.
  2. In a new commit, add some regression tests in tests/suite/cli_misc.rs to prevent future regressions.

@Xerxes-2
Copy link
Contributor Author

Xerxes-2 commented Jun 25, 2024

Thanks! IMHO there are two things left to do:

  1. Squash all the feature changes together, as rustup encourages atomic commits, and the current changes are seemingly small enough to be squash into a single commit.
  2. In a new commit, add some regression tests in tests/suite/cli_misc.rs to prevent future regressions.

Fine, I might do it later cuz I'm now in a holiday.

@Xerxes-2
Copy link
Contributor Author

@rami3l Can I close this PR and open a new one?

@rami3l
Copy link
Member

rami3l commented Jun 26, 2024

@rami3l Can I close this PR and open a new one?

@Xerxes-2 Yes, but why you'd want to do that instead of doing an interactive rebase directly on this one?

@Xerxes-2
Copy link
Contributor Author

@rami3l Can I close this PR and open a new one?

@Xerxes-2 Yes, but why you'd want to do that instead of doing an interactive rebase directly on this one?

Because I accidentally merged master into this branch, may not be able to squash together all the feature commits

@rami3l
Copy link
Member

rami3l commented Jun 26, 2024

@rami3l Can I close this PR and open a new one?

@Xerxes-2 Yes, but why you'd want to do that instead of doing an interactive rebase directly on this one?

Because I accidentally merged master into this branch, may not be able to squash together all the feature commits

@Xerxes-2 AFAIK merge commits will be automatically dropped when doing an interactive rebase. See https://stackoverflow.com/a/4784082.

Use original error instead of rewriting

avoid duplicate `.to_string()`

remove unnecessary `.as_str()`
@Xerxes-2 Xerxes-2 force-pushed the smart-guess-update-self branch from 9844106 to 4689949 Compare June 26, 2024 04:03
@Xerxes-2 Xerxes-2 requested a review from rami3l June 26, 2024 07:53
@rami3l rami3l added this pull request to the merge queue Jun 26, 2024
@rami3l
Copy link
Member

rami3l commented Jun 26, 2024

@Xerxes-2 Thanks again for helping out!

Merged via the queue into rust-lang:master with commit f48df22 Jun 26, 2024
27 checks passed
@Xerxes-2 Xerxes-2 deleted the smart-guess-update-self branch June 26, 2024 09:51
@rami3l rami3l mentioned this pull request Oct 6, 2024
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

rustup update self should suggest rustup self update
3 participants