Support profile overrides for -Z build-std

[maurer]

Pass both the main package graph and the build-std package graph to the verifier so that e.g. [profile.dev.package.core] is not rejected and ignored if core is being built.

What does this PR try to resolve?

Currently, [profile.dev.package.my_std_crate_here] will not be respected when -Z build-std=my_std_crate_here is passed, because profile overrides are verified on a package graph that does not include the build-std package graph.

This is important to support because many users of -Z build-std are targeting embedded environments where image space may be at a premium. This means that while they may be able to support a more relaxed dev build for their own code, they'd like to build standard libraries with optimizations and fewer assertions to shrink things down.

The default behavior without -Z build-std is to use prebuilt stdlibs, so you will get an optimized stdlib and a dev-profile version of your project. This configurability allows developers to opt back in to a similar configuration with -Z build-std by setting profile flags for core/compiler_builtins/alloc/std as appropriate.

How to test and review this PR?

cargo test should test it - I've added a new test which ensures both that:

• No warning is emitted when a stdlib is specified in a profile clause and -Z build-std is used
• The adjustment to the profile affects the requested crate
• The adjustment to the profile does not affect another crate in the graph

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
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

[weihanglo]

Similar to #15772 (comment) and #15670 (comment), build-std's design is in flux. We might want to hold off on making design changes at this momemnt. Also, we generally prefer to have a design discussed and approved before proceeding to implementation.

See also rust-lang/wg-cargo-std-aware#2 for the relevant build-std profile overrides.

[maurer]

I did not believe a design was required because I was not adding any new features, just fixing a bug (that when an override is set for core, and core is being built, we don't use the override).

Those overrides don't allow you to set core to be built with debug-assertions disabled while building the rest of the world with debug-assertions enabled, so they don't address the issue. Should I file a bug instead? This is preventing me from enabling BTI and PAC for a firmware project.

[bjm9991]

I am now hitting this in a similar use-case. @weihanglo - could you please consider addressing maurer's response here?

From a cursory look here, it indeed looks more like a fixup to what's included in the package graph as opposed to a large overhaul of build-std.

[weihanglo]

While it looks like as simple as a fix, we do have a series of ongoing RFC around the design of profiles. The current direction of it is not exposing per-crate profile (See https://github.com/rust-lang/rfcs/blob/23e7a345f3c01e3408942243f4701687981fb935/text/3874-build-std-always.md#why-does-always-rebuild-in-release-profile). And there were concerns around exposing too many std implementaion details. I feel like this feature is kinda on the opposite side of the RFC series.

Can people share the use case of only overriding certain crates like core but not other std crates in either rust-lang/wg-cargo-std-aware#2 or <#project-goals/build-std>?

cc @ehuss, you know the overall std goal more than me.

[rustbot]

☔ The latest upstream changes (possibly 4a930ce) made this pull request unmergeable. Please resolve the merge conflicts.