Ignore `workspace.default-members` when running `cargo install` on root package of a non-virtual workspace

[tedinski]

What does this PR try to resolve?

• Fixes #11058

Two observable behaviors are fixed:

1. When running cargo install with --path or --git and specifically requesting the root package of a non-virtual workspace, cargo install will accidentally build workspace.default-members instead of the requested root package.
2. Further, if that default-members does not include the root package, it will install binaries from those other packages (the default-members) and claim they were the binaries from the root package! There is no way, actually, to install the root package binaries.

These two behaviors have the same root cause:

• cargo install effectively does cargo build --release in the requested package directory, but when this is the root of a non-virtual workspace, that builds default-members instead of the requested package.

How should we test and review this PR?

I have included a test exhibiting this behavior. It currently fails in the manner indicated in the test, and passes with the changes included in this PR.

I'm not sure the solution in the PR is the best solution, but the alternative I am able to come up with involves much more extensive changes to how cargo install works, to produce a distinct CompileOptions for every package built. I tried to keep the new workspace "API" ignore_default_members() as narrowly-scoped in its effect as possible.

Additional information

The only way I could think this behavior change could impact someone is if they were somehow using cargo install --path (or --git) and wanting it to actually install the binaries from all of default-members. However, I don't believe that's possible, since if there are multiple packages with binaries, I believe cargo requires the packages to be specified. So someone would have to be additionally relying on specifying just the root package, but then wanting the binaries from more than just the root. I think this is probably an acceptable risk for merging!

[rust-highfive]

r? @ehuss

(rust-highfive has picked a reviewer for you, use r? to override)

[weihanglo]

Ping @tedinski. Just checking in to see if you are still interested in working on this, or if you were seeking guidances.

[tedinski]

I hope to return to this if someone else doesn't beat me to a better solution, but I'm not certain what the best approach would be.

The trouble with the "build with different -p options" approach is that the CompileOptions isn't a clonable type, and ultimately (via BuildConfig) seems to contain some things that aren't clonable.

My guess at a path forward there is perhaps to write a clone_as_template method to both these types that asserts that certain problematic fields are None (and not Something unclonable). (I'm assuming we don't want to add a Clone implementation that's partial and might fail, hence the ad-hoc method.) Then we could clone and mutate the initial CompileOptions for each build, letting us (effectively) set -p appropriately for each one.

[ehuss]

I think it would be fine to #[derive(Debug, Clone)] on CompileOptions and BuildConfig, and just wrap rustfix_diagnostic_server in an Arc (as in rustfix_diagnostic_server: Arc<RefCell<Option<RustfixDiagnosticServer>>>). Can you say if you ran into any problems with that? I think it generally should be a one or two line change.

[tedinski]

I've updated the PR to the suggested approach. The change was smooth, I just wasn't sure if wrapping it in an Arc was the right approach to take, so that was helpful.

[weihanglo]

@bors r+

[bors]

:pushpin: Commit 7dc8be541460f83c27161b0513d3644f83cef474 has been approved by weihanglo

It is now in the queue for this repository.

[bors]

:hourglass: Testing commit 7dc8be541460f83c27161b0513d3644f83cef474 with merge 23424fde2ed33850c749169056c6804b29f4675e...

[bors]

:sunny: Test successful - checks-actions Approved by: weihanglo Pushing 23424fde2ed33850c749169056c6804b29f4675e to master...

[bors]

:sunny: Test successful - checks-actions Approved by: weihanglo Pushing 23424fde2ed33850c749169056c6804b29f4675e to master...