Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Deal cleanly with malformed default-host #1578
It is better to report errors cleanly rather than panic. If the
This PR will, when complete, add in some appropriate checks for default-host
So far, all I've done is to change the
If this approach seems sane, I'd appreciate any pointers possible on where to add appropriate checks, and in addition, where to add appropriate tests.
At this point, I've added a
My next steps will be to try and improve the situation by suggesting the build triple and the 'stable' channel if these errors come up.
It is better to report errors cleanly rather than panic. If the default-host is set badly then we can end up panicking because we're unable to parse it. Since default-host is user input, it's better we don't panic.
In order to have useful early error messages when the configuration is unusably broken, allow the Cfg struct to smoke-test itself during `Cfg::from_env()`
It can be useful to debug rustup's operation. This comit adds a debug macro using BRIGHT_BLUE which only displays if RUSTUP_DEBUG is in the environment
When rustup-init is running, we need to verify that the provided host triple and toolchain channel can be used together to determine a full toolchain triple (quadruple?). If we can't do this during the sanity checks, error out early.