Possibly support `-p` for standard library dependencies.

[ehuss]

Commands like cargo build can take the -p flag to build any dependency. The current implementation does not support doing this for standard library dependencies. Should this be supported?

[Ericson2314]

Yes I think it should; anything to make stdlib deps more normal is good.

[c272]

One possible implementation of this, which I have been testing as a patch, could work something like this:

• Both cargo build -p [...] and cargo clean -p [...] support specifying standard library packages when -Zbuild-std is passed.
• The -Zbuild-std=... flag essentially acts as an extension of -p and vice versa.
  • For example, cargo build -p foo -p core -p std -Zbuild-std would be equivalent to cargo build -p foo -Zbuild-std=core,std.
  • This would help remove ambiguity if a package with the same name existed in both workspaces, as if specified in the -Z argument, there is no doubt which is being targeted.
  • One drawback to this approach is that users specifying a static set of packages in .cargo/config.toml would have to remove these if wishing to build only a subset via. -p.
• If a -p spec matches a package name present in both the standard library workspace and the user workspace, a warning is presented and only the user package is selected.
  • This allows for the maximum range of selection, with the user able to pick only the user package (-p foo), the user package and the std package (-p foo -Zbuild-std=foo) and only the std package (-Zbuild-std=foo).

With the standard library occupying its own workspace currently, however, this does bring to mind a few implementation snags:

• When processing -p arguments, they would somehow have to be filtered into those intended for the standard library workspace, and those for the user workspace. This would likely involve creating a standard library resolve prior to compilation.
• This will add more stdlib-specific processing internally within Cargo.

Thinking further ahead, this could be one possible avenue of stabilising build-std into a standard command line option in place of -Zbuild-std, if there is a replacement for the .cargo/config.toml field in some form. This is obviously a slightly larger scoped discussion, though.

What are people's opinions on this approach? This would allow for user and stdlib packages to appear in the same space to the end user, however I would be interested in any alternative suggestions.

Related: https://github.com/rust-lang/wg-cargo-std-aware/issues/21