-
Notifications
You must be signed in to change notification settings - Fork 1.6k
build-std: context #3873
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
base: master
Are you sure you want to change the base?
build-std: context #3873
Conversation
8c857a0 to
c8649ed
Compare
|
I'm going to propose to go ahead and merge this RFC. Although it doesn't really have a distinct set of changes being defined, it does lay out the scope and intention of the direction we are planning to go. I'd like to direct reviewers attention to the Motivation section as a key part of this RFC. It essentially outlines the key objectives and scope of this project. The following RFCs are explaining exactly how that will be achieved. The idea here is for us to agree that these are worthy goals and that we understand what's in and out of scope (in order to make this project tractable). Getting this merged also helps with the subsequent RFCs which are built on top of this. @rfcbot fcp merge compiler,cargo,crates-io,libs-api |
|
Team member @ehuss has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
| > automated testing ensures that each tier 1 target builds and passes tests | ||
| > after each change. | ||
|
|
||
| As an innate property of the target, not all targets can support the `std` crate |
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.
| As an innate property of the target, not all targets can support the `std` crate | |
| As an innate property of the target, not all targets can support the `std` crate. |
| - There is no stable mechanism for using the standard library on a tier | ||
| three target that does not ship a pre-built std | ||
|
|
||
| - While it is common for these targets to not support the standard library, |
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.
I think you mean "std" here and not "the standard library", though it is quite common for tier 3 targets to support std. When scrolling through the list, most have an operating system and have had a working std build at some point. They do often break of course, something that build-std focused on tier 3 targets would likely need to address. That would be worth pointing out here I think, since it would have a significant effect, as either fixes would need to be backported to beta in time or the target would be unavailable for an entire cycle.
I happen have a bunch of (all of it) data on tier 3 breakage and would be happy to share that with anyone that wants to work on that :)
|
|
||
| - Using miri requires building the standard library with specific compiler | ||
| flags that would not be appropriate for the pre-built standard library, so | ||
| is forced to require nightly and build its own sysroot |
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.
I don't think this is what stops Miri from being stable. As part of the toolchain, Miri could do its sysroot building on stable just fine. The reason Miri isn't available on stable is because Rust has no stable memory model, so stable Miri could give users the impression that its assessment is in any way "final" and based on a stable memory model. So I don't think this use case is relevant here.
While Rust's pre-built standard library has proven itself sufficient for the majority of use cases, there are a handful of use cases that are not well supported:
Proposals to solve these problems come broadly under the umbrella of "build-std" and date back over 10 years ago, though no complete solution has yet reached consensus.
This RFC does not propose any changes directly, only document the background, history and motivations for build-std. It is part of a series of build-std RFCs and later RFCs will reference this one. This RFC is part of the build-std project goal.
build-std="always"(build-std: always #3874)build-std="compatible"(RFC not opened yet)build-std="match-profile"(RFC not opened yet)There is also a Zulip channel where you can ask questions about any of the build-std RFCs. This series of RFCs was drafted over many months with the help of stakeholders from many Rust project teams, we thank them for their help!
Rendered