feat(config)!: use unqualified names for default_toolchain - #4947
Conversation
Cfg::get_default_resolvable()default_toolchain
1d2c5c6 to
108ca96
Compare
This comment has been minimized.
This comment has been minimized.
37bfef2 to
8975942
Compare
This comment has been minimized.
This comment has been minimized.
8975942 to
bb5bf44
Compare
bb5bf44 to
9f1d12c
Compare
9f1d12c to
5616ba4
Compare
|
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. |
| Ok(Some(toolchain.resolve(&self.default_host_tuple()?)?)) | ||
| } | ||
|
|
||
| /// Gets the configured default toolchain. |
There was a problem hiding this comment.
Nit: documentation comment style.
Also, duplicating the documentation comment from get_default() seems pretty unhelpful. Ideally these documentation comments should tell a clear story about the difference and their interaction.
| CustomToolchainName, | ||
| ResolvableToolchainName, | ||
| ResolvableToolchainName::Custom | ||
| ); |
There was a problem hiding this comment.
I'm not a fan of these macros and have looked several times at cleaning them up. How about just writing them out (could inline macros with Rust-Analyzer I think)?
| Some(toolchain_name) | ||
| } | ||
| None => match cfg.get_default()? { | ||
| None => match cfg.get_default_resolvable()? { |
There was a problem hiding this comment.
Does get_default() go unused? Where is it still used after this?
Stacked on #4950, closes #4945.
The breakage should be minimal anyway because the default host tuple almost never changes.