Add a sysroot crate to represent the standard library crates

[Zoxc]

This adds a dummy crate named sysroot to represent the standard library target instead of using the test crate. This allows the removal of proc_macro as a dependency of test allowing these 2 crates to build in parallel saving around 9 seconds locally.

[rustbot]

r? @m-ou-se

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

These commits modify the Cargo.lock file. Random changes to Cargo.lock can be introduced when switching branches and rebasing PRs.
This was probably unintentional and should be reverted before this PR is merged.

If this was intentional then you can ignore this comment.

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[jyn514]

I don't understand why this change is necessary. Why not just run cargo build -p proc_macro -p test? Where does the requirement for a single crate come from?

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

These commits modify the Cargo.lock file. Random changes to Cargo.lock can be introduced when switching branches and rebasing PRs.
This was probably unintentional and should be reverted before this PR is merged.

If this was intentional then you can ignore this comment.

[Zoxc]

I don't think cargo supports specifying features per crate. There may be some other reason I don't know about also.

[jyn514]

I don't think that's true, but even if so, the features are additive between test and proc_macro, it shouldn't hurt anything. library/library just seems confusing, and will also break x build library (which today is an alias for "build all crates under library/").

[albertlarsan68]

Maybe name it rustlibs?

[Zoxc]

@jyn514 It seems that cargo doc only supports a single crate. Not sure how to solve that in #108871.

sysroot could be an alternative crate name?

[jyn514]

I don't think that's what's going on in that PR. Here's the error message:

RUSTDOCFLAGS=--document-private-items --document-hidden-items python3 ../x.py doc --stage 0 library/test
Documenting {test} stage0 library (x86_64-unknown-linux-gnu) in HTML format
error: none of the selected packages contains these features: backtrace, compiler-builtins-c, panic-unwind

library/test is telling bootstrap to only document test and its dependencies. I think if you change the shell scripts to use library instead it will work fine. (We should probably also support documenting just test, that will likely need changes to std_features, but you should be able to test your changes before fixing that.)

[Zoxc]

Given that is is more of a bootstrap change, r? @jyn514

[jyn514]

@bors r+

See #108871 (comment) for why we ended up not taking that approach.

[bors]

📌 Commit fd4c81f has been approved by jyn514

It is now in the queue for this repository.

[ehuss]

This is going to cause a lot of breakage (build-std, cargo, miri, anyone who builds std manually, etc.). I kindly ask that in the future if there is a major change like this that you let people know ahead of time so that they can prepare, or perhaps provide suggestions to maintain compatibility to prevent this kind of situation.

I'm going to mark this with relnotes for a suggestion to add it to the compatibility section.

[Zoxc]

I did fail to release that this would break build-std, etc. Is build-std tested only on cargo CI? Do we not gate nightly on cargo CI passing with the rustc components that will be shipped?

[ehuss]

Is build-std tested only on cargo CI? Do we not gate nightly on cargo CI passing with the rustc components that will be shipped?

Cargo's nightly features are not tested in the rust-lang/rust CI because of the cyclical nature of trying to change unstable interfaces.