Cargo-installing a binary within a workspace shows warnings about profile overrides

[tomaka]

Situation:

• A workspace is composed of two packages: a and b.
• b depends on the crate smallvec.
• The workspace has a section mentioning [profile.dev.package] smallvec = { opt-level = 3 }.

When running cargo install --path ./a, I'm getting a warning:

warning: profile package spec `smallvec` in profile `dev` did not match any packages

This warning is printed as the package a doesn't depend on smallvec.
Running cargo install --path ./b works fine.

I believe that this is an issue with Cargo, as I don't think that there's a clean way to silence this warning.

[tomaka]

I've created a repo with that situation: https://github.com/tomaka/cargo-bug-repro-20200624

Interestingly, with cargo 1.42, running cargo install --git https://github.com/tomaka/cargo-bug-repro-20200624 a does not show any warning.
However with cargo 1.44-nightly (2020-03-17), the same command does show a warning.

In both cargo 1.42 and 1.44, running cargo install --path ... does show the warning.

[ehuss]

Thanks for the detailed report! This is kinda related to #7169. cargo install --path ignores Cargo.lock by default (this can be avoided with --locked). What happens is that it re-runs resolution in a special mode where it only resolves the given package (ignoring everything else in the workspace), which more closely matches the behavior of cargo install from a registry. The code that checks for unused profiles can then only see that limited set of resolved packages.

The reason 1.44 is now showing a warning is that installing a git url now respects workspace settings (see #7768).

There is a bit of discussion on that issue (and elsewhere) about changing the default behavior. It does seem like making cargo install --path more equivalent to cargo build in that same directory would be less surprising for most people.