-
Notifications
You must be signed in to change notification settings - Fork 952
Fix component remove error by component name with explicit target triple #3601
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
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.
LGTM, and really sorry for the long wait! I personally would like to get this into Rustup v1.28.0.
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.
Nice work :)
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.
Thanks a lot! I think this PR is good to go.
@djc @rbtcollins I guess we can ship this with v1.27.1 as well? As I see it, only |
Fix #3166
Follow by #3467, another approach to fix the error.
Rationale
The basic point of this PR is to improve the error message when Rustup somehow cannot recognize a component's full name by extracting the component name first from the manifest when parsing
rust-std-x-y-z
, so that at leastx-y-z
is intended to be a target triple. This prevents Rustup from falling back on the default target triple, producing an error message that is not very helpful (see the quote below).The direct cause of #3166 is that
wasm32-unknown-unknown
hasn't been hardcoded into our codebase:rustup/src/dist/triple.rs
Lines 7 to 37 in a6c9fae
... but that's another issue (later split into #3783), i.e. we really should not hardcode target triples in our artifact, as the complete list changes quite regularly.
The old
component_(add|remove)()
functions rely on thenew_with_target()
function; on the other hand, the new implementation of those two functions in this PR is based ondistributable
andfallback_target
, which relies on detecting the component names (fetched from the distributable manifest) first, so will be more robust implementation-wise.#3467 (comment)