allow build-std to be configured per-target in .cargo/config.toml

[fee1-dead]

What does this PR try to resolve?

-Zbuild-std has some issues with per-pkg-target and bindeps, as seen with #10444 and #9451.

At the same time, since these features essentially enable builds where crates with different targets can co-exist, some people may want to use build-std for one target (in my own project: amdgcn-amd-amdhsa, for OS dev people: x86_64-unknown-none) but not for another target where std is already shipped: #8733

This PR overhauls the way build-std interacts with targets and we're able to fix the issues described above by introducing an additional per-target config in .cargo/config.toml for build-std. Note that these configs co-exist with the global -Zbuild-std flag, and has different behavior whether or not the two are used together: if the global flag is enabled, then all targets will attempt to build their std crates, with per-target config as an override. If the global flag is not used, then only targets that are configured via per-target config will try to build std crates.

This supercedes my two previous attempts at resolving the same issue: #10330 and #11969

How to test and review this PR?

Use .cargo/config.toml:

[target.TARGET]
build-std = ['core']
build-std-features = ['default']

I've already included some essential tests in tests/testsuite/standard_lib.rs such as intersection with per-pkg-target and bindeps. Feel free to suggest additional test cases.

I haven't run the cross compile test locally as I don't know how to get an environment for it on NixOS, will (ab)use the CI for this I guess.

Some unresolved questions:

• Should we introduce and use [target.TARGET.unstable] instead?
• Is there a remaining use for the global flags or maybe we can consider removing the existing -Zbuild-std way of usage?
• How important is it that we gate target.TARGET.build-std = 'xxx' when TARGET isn't being built? (thus not parsed in the current state)

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[fee1-dead]

cc @phil-opp if you want to do some testing/review :)

[ehuss]

Thanks for the PR! However, I don't think this is something we want to move forward with at this time. We are currently working on the build-std design, and the design is in flux and may not go in this direction. We probably want to hold off on making design changes at this time. Also, generally we prefer to have designs approved before moving to the implementation. I'm going to go ahead and close this for now. After we have made more progress on getting agreement on the direction for build-std, we may revisit exactly how this may work.

[fee1-dead]

In that case, could you please keep this open in case this is the direction to go in?

cc @adamgemmell and @davidtwco

[fee1-dead]

Note that also it doesn't look like there was active design work in the area. Nor does it appear that there is a solution emerging from the previous discussions. I'm going to comment on the Zulip thread.