build-std: explicit dependencies

[davidtwco]

Allow users to add explicit dependencies on standard library crates in the Cargo.toml. This enables Cargo to determine which standard library crates are required by the crate graph without build-std-crates being set and for different crates to require different standard library crates.

This RFC is is part of the build-std project goal and a series of build-std RFCs:

1. build-std context (build-std: context #3873)
2. build-std="always" (build-std: always #3874)
3. Explicit standard library dependencies (this RFC)
4. build-std="compatible" (RFC not opened yet)
5. build-std="match-profile" (RFC not opened yet)

There is also a Zulip channel where you can ask questions about any of the build-std RFCs. This series of RFCs was drafted over many months with the help of stakeholders from many Rust project teams, we thank them for their help!

There are some details that have been noted as being worth mentioning in any eventual tracking issues:

• build-std: explicit dependencies #3875 (comment)

Rendered

[clarfonthey]

While I think this is a sensible default, I think there should be a warn-by-default lint if this ever occurs for a crate annotated with #![no_std], since we should be pushing people toward adding an alloc or core dependency instead.

[davidtwco]

To clarify, a lint in the compiler if we end up passing --extern std=... to rustc but with a #![no_std] crate? That makes sense to me but the part of the document you've commented on is about public/private dependencies which seems unrelated, so wanted to double check.

[clarfonthey]

Basically, if:

1. Cargo.toml doesn't have any std/alloc/core dependencies
2. The crate is no_std

It may require explicit support from Cargo to do this.

[clarfonthey]

While it is an unstable feature, I think it's worth commenting on how this interacts with the no_core feature: will crates using this still have to specify the core dependency, or will it be allowed to be omitted in those cases? Additionally, would this require an additional cargo feature or would just the feature on the crate be enough?

[davidtwco]

I haven't considered no_core because it's perma-unstable. I don't see us ever stabilising it unless we're comfortable with alternative core crates having no stability guarantees (otherwise we can't add new required language items, which is very useful). Given that there is no path to or interest in stabilising this feature, I don't think it is worth mentioning in the RFC - a proposal to stabilise no_core can mention interactions with build-std rather than this RFC anticipating it.

[clarfonthey]

I think that it might be worth mentioning the concept of lints here to make this less annoying of a requirement.

Right now, we have the concept of cargo lints, but we don't have any lints that let you autofix Cargo.toml, which I think would be a much-appreciated addition here. I feel like it makes a substantial difference toward this being a reasonable requirement if, instead of a hard error, this were a warn-by-default lint (implicitly adding the core dependency anyway) and that crates like this simply could not be published to crates.io.

In particular, it would be quite annoying if this issue completely prevented rust-analyzer from operating on code until it were fixed.

[davidtwco]

I'm not convinced this is that annoying a requirement. Users will only hit this after adding an explicit optional dependency on the alloc or std and immediately notice the error and need to fix it. I don't see the value in having a lint that would allow you to delay fixing this but would force you to fix it eventually when you want to publish the crate.

[epage]

I suspect this will be something people don't fully understand the implications of until they are testing the feature, so we should make sure we note this here and then in the tracking issue to call this out for real world feedback.

[davidtwco]

I've added a link to this comment from the PR description

[epage]

What happens if I do:

$ cargo new foo
$ cd foo
$ cargo add std --optional

Should we

• error upfront
• wait for the natural parse error
• act as if they also did cargo add core or cargo add alloc (next lowest library)

[davidtwco]

I'd expect we'd wait for the natural parse error but I don't feel strongly, if Cargo has different norms around how to deal with cases like this then we can follow those norms.

[epage]

Today, we don't do much upfront work which leads to situations like rust-lang/cargo#16101

[davidtwco]

I'd lean towards following existing precedent and if issues like rust-lang/cargo#16101 are something that t-cargo would like to resolve then a case like this can be included in that effort.

[epage]

This is missing a very important motivation: if we put implicit builtins into Cargo.toml, then publishing with a new Cargo would raise your MSRV

[davidtwco]

Added this motivation in 87c3a95

[epage]

Should cargo add automatically add public = true for builtins?

[epage]

Hmm, but what about before its stabilized?

[davidtwco]

I've added a note that public= true would be added after public/private deps are stabilised in c214948

[epage]

I'm assuming this is more an implementation detail but it could have design ramifications: how do std dependencies refer to each other? builtin, path, or something else? Both first-party and vendored.

[davidtwco]

I think they would continue to use path, and then we can simplify how their dependencies refer to them as in Remove rustc_dep_of_std.

[Veykril]

This feels a bit odd to me. I can understand why we would want to skip this if they are implied, as thats the current state of things and it would technically bloat the output unnecessarily. But if explicit, why would we omit the dependencies of the standard libraries? Maybe I am misunderstanding but this sounds like it would make it difficult for tools like rust-analyzer to use the output to construct the full crate graph with sources and all correctly?

[davidtwco]

I think I excluded dependencies of the standard library only as we've tried to hide those as much as possible throughout, but cargo metadata is probably a special-case here because it is used by tools like rust-analyzer. I don't know enough about how cargo metadata is used by rust-analyzer to know what the right answer here is - do you need to construct a full crate graph including the dependencies of std?

[Veykril]

We need to know the entire crate graph of the standard libraries as well yes, otherwise we cannot correctly analyze things as even private dependencies can crop up in public things, think of type sizes for example.

[epage]

I'm less sure that cargo metadata is a special case. If looking at to change this, at least call it out as Unresolved to make sure the Cargo team explicitly talks this over.

[davidtwco]

Okay, I've changed this to include std's deps in 4b870f6.

[epage]

As I said, please leave this as an Unresolved Question