Forward features from library/test

[workingjubilee]

Failing to do this breaks a bunch of build systems, so let's give them a few nights of overlap to migrate.

r? @ehuss

[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. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[jyn514]

Cargo is already fixing this in rust-lang/cargo#12088. Does it still make sense to land both changes?

[workingjubilee]

I think this would help smooth the migration for miscellaneous other users yeah. I don't feel strongly that we must land it if cargo has patched in a fix, as they're the big one to avoid breaking.

[jyn514]

r=me unless you want to wait for Ehuss

@bors delegate=workingjubilee p=1 (important to land this before next nightly if we're going to do it at all)

[bors]

✌️ @workingjubilee can now approve this pull request

[ehuss]

Does this essentially negate the benefits of #108865?

I'm concerned overall about the structural changes in #108865, since there will likely be other users of the std source component who will be affected. Is the intent to have them migrate to using sysroot, and then revert this PR some release in the future? What is the intended timeline here? If it is really just a few nights, then I probably wouldn't bother with this change.

[workingjubilee]

Ah, thanks for letting me know. If you no longer believe it is beneficial to make things easier for people to migrate, then I can just close this.

[workingjubilee]

I will note: my off-center view of time and my tendency to understatement means "a few nights" can mean anywhere between "3 nights" and "99 nights", for me. I am normally someone who does have reason to compile the stdlib using my own set of build instructions, so #108865 did affect me, but at the same time I don't update the compiler version often enough for this to be a serious concern.