build-std: second iteration

[davidtwco]

Supercedes #1. Intended for discussion with invited reviewers until we're happy enough to post publicly. Feel free to discuss on #project-goals/2025h1/build-std.

Please don't leave feedback on this unless you've been invited to. We'll invite more project members and teams to participate over time and eventually post this publicly for community feedback. With such a large proposal, this sort of staged rollout is the only way we can manage the feedback and evolve the document. If you aren't invited and post anyway, I reserve the right to just delete comments.

Rendered

[Kobzol]

I did some experiments with PGO:

1. You need the profiler_builtins std crate if you want to use PGO
2. If you don't compile it with -Zbuild-std, the prebuilt version from the sysroot will be used instead. This seems like a more general "issue" - if Cargo only recompiles a subset of libstd, but then the rest of the crates can still be looked up from the sysroot, we would combine crates from the prebuilt std and the local built std (which seems to happen today). But the --extern magic described in this RFC would hopefully solve that.
3. If you want to compile profiler_builtins with build-std, then you'll need LLVM sources to be available.

[thejpster]

I've left some pretty minor comments. In general, this was well structured and highly legible given the very technical nature. Excellent work!

[ehuss]

Just some minor comments on stage-1b.

[ehuss]

Comments on stage 2.

[ehuss]

I'm not quite following this row. Why would dev trigger a rebuild if it is always building the standard library with release settings? I would expect the pre-built to be sufficient if it isn't building std with debug settings.

[davidtwco]

This was just a mistake in the table that we hadn't fixed in the document yet - #2 (comment)

[ehuss]

I'm also not clear here. If the profile gains the ability to set target-modifiers, wouldn't cargo be able to directly compare those target modifier values?

[davidtwco]

This avoids Cargo needing to know which flags are target modifiers and which aren't (or looking in RUSTFLAGS for target modifiers) - Cargo can just pass every flag it would pass to the build to this compatibility check invocation and be told if it needs to rebuild the standard library or not. Elaborated on this in the RFC.

[ehuss]

I'm a little worried about the challenges here since cargo may not necessarily know where libcore.rlib is.

As a side note, this will need to be cached. I think our existing caching code might handle it, but I'm not sure.

[davidtwco]

rustc will always know where it is, so we could provide some alternative interface --compatibility-with=core or something like that if required

[ehuss]

I'm having difficulty understanding this sentence in combination with the sentence below about per-target profiles not being available.

Is this stage 2 implying that it will also be adding target modifiers to the profile? Or is that a hypothetical future? If that is a new proposal for this stage, there probably should be a relatively hefty section describing the addition of a new profile field.

Are target modifiers ignored on targets that don't support that modifier?

[davidtwco]

This assumes that target modifiers will eventually be exposed through Cargo's [profile] options, like any other codegen flag. It doesn't propose adding any of them to that today, they're all still unstable flags in rustc anyway.

Are target modifiers ignored on targets that don't support that modifier?

I think we normally decide this on a per-flag basis, not on the basis of whether a flag is a target modifier or not, so it depends.

[davidtwco]

As PR has gotten quite large again, so I've responded to all the feedback and incorporated it into the document, squashed all the changes and opened another PR that we can use for the final rounds of feedback before we open this in rust-lang/rfcs - see #4