-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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(rust): Option to display toolchain names by qryxip #3414
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't look at this in depth yet, but I have a few comments
3e37d23
to
11bc895
Compare
Rebased with squash to reduce the commit set (and strip out a few commits that were made in pure confusion) |
11bc895
to
6fce47f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Beyond my comment, the changes look reasonable, but I might have missed something.
6fce47f
to
a9fe0ec
Compare
Okay. I'll let this sit another few days and then try to do a self-review, since I think it's been long enough that I can come at it with a (relatively) clean slate. |
src/modules/rust.rs
Outdated
fn lookup_override(&self, cwd: &Path) -> Option<String> { | ||
self.overrides | ||
.iter() | ||
.find(|(dir, _)| cwd.starts_with(dir)) | ||
.map(|(_, name)| name.to_owned()) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick comment: nightly toolchains are suffixed with -nightly. It would be nice if this module doesn't display "nightly" twice (I presume it currently does). |
If you take a look at the screenshot in the issue description, you can see the proposed output for nightly toolchains. "nightly" is only shown once. |
Ah, nice. This module looks really good by the way! |
I think |
Ah, I was of the impression that we were changing the default config for the Rust module. Probably something we should clear up. My thinking is that the updated format shouldn't constitute a breaking change because the same data is being presented in an easier-to-read format. Imo, breaking the semantic meaning of the prompt should be breaking (e.g. changing a symbol), or changing what information can be presented. Nevertheless, we do have breaking changes lined up for the next major bump. Perhaps we can update the config group this change as part of them, just to be safe? How do you feel about changing the default format? |
If we can agree on whether this should be released as a breaking or non-breaking change, I think it's ready to be merged. I'd personally vote to make it non-breaking: |
It might be nice to handle this first before merging, but that could also be done later. |
I think this should be fine to treat as a non breaking change. |
Okay. I'll need to pull in the changes as mentioned in this comment, and then this will probably be ready for final review. EDIT: And also this one |
523f493
to
a9819d1
Compare
a244e4d
to
1837486
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait, I just noticed toolchain
resolves to stable-aarch64-apple-darwin
on my mac, which is too long and doesn't match the documentation.
I've figured out why this happens: the existing code, along with all tests, assumes that the I've pulled in EDIT: I think long-term, the solution will be to move these methods into the RustupSettings struct, then use something like |
14dea80
to
5162e4d
Compare
src/modules/rust.rs
Outdated
let default_host_triple = rust_env_info | ||
.get_rustup_settings(context) | ||
.default_host_triple() | ||
.or_else(|| guess_host_triple()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.or_else(|| guess_host_triple()); | |
.or_else(guess_host_triple); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Somehow, there's a lifetime error that happens when you do that. I don't have the motivation to debug lifetime issues on chained methods at the moment, which is why I have this weird set of assignments in the current commit, but that's definitely something to tackle later.
This is an actualization of PR starship#559 as originally envisioned by qryxip. Adds the ability to display toolchain versions, either as extracted from environment/settings files or by getting the host triple. As part of this, several other major changes were needed: - Many of the smaller functions within the code have been fused, moved, or dropped. - The Rustup environmental info is now initialized lazily using OnceCells. This will hopefully lead to a performance increase. - New configuration variables (`toolchain` and `numver`) have been added to allow finer-grained configuration. - Override information is no longer read from `rustup` output. Instead, it is parsed from the same files that rustup would use to determine this info. Co-authored-by: qryxip <qryxip@gmail.com>
5162e4d
to
87802e4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the way, I don't think you added commit credit for @qryxip yet. If you had trouble figuring out emails/the syntax, the GitHub desktop application works quite nicely for this.
No it looks fine, I must have missed it. |
@davidkna Thanks so much for putting time into reviewing this and catching my mistakes on multiple occasions! Same to @matchai, @andytom, and @segevfiner for commenting, and of course, a huge thanks to @qryxip for proposing and writing most of the logic for this in the first place. Now to deal with the aftermath, I have some things I'd like to fix in #3967. Work is never done :) |
Description
#559 was approved and then sat around waiting to be merged for over 18 months. I'm not sure what happened, but I want to extend my sincerest apologies to for @qryxip for the state of that PR. We clearly should have merged it before things got this bad.
I attempted to rebase this PR onto master several times, but to no avail: the PR comes from before the format strings change, so there were some incompatibilities with how it was structured.
This PR is an attempt to make things right: I have manually ported over the changes made by @qryxip in #559. Because they would have potentially constituted breaking changes (I'm not sure what we consider breaking right now), I have segmented off two code paths. The old codepath uses exactly the same code as is present on master. The new code path, based on #559, exposes two new format variables, named
numver
andtoolchain
. Enabling the behavior intended by #559 involve simply settingformat = "via [$symbol($numver)\\(($toolchain)\\) ]($style)"
in starship.toml.Because so many codepaths potentially create performance issues, I have also created a module-level external command cache, known as
RustToolingEnvironmentInfo
. This usesOnceCell
to cache the results of reading data from the environment. As a result, this version of the module is about twice as fast as master, though I have had not had time to do thorough benchmarks.Motivation and Context
Closes #559
Closes #555
Screenshots (if appropriate):
I can replicate the behavior as shown in this comment on #559
TODOs
Add styling options for(REJECTED)$numver
and$toolchain
.Questions Moving Forward
I have these questions for the rest of Starship Command: