feat(cargo-add): warn when adding binary-only packages

[raushan728]

Emit a warning when cargo add adds a package that does not contain a library target. The dependency is still added to Cargo.toml, but Cargo warns that the package is unlikely to work as a dependency.

Rationale

Users sometimes use cargo add for binary-only crates when they intended to install a CLI tool. Keeping this as a warning preserves the existing behavior while providing immediate feedback about a likely mistake.

The registry index does not include target information, so cargo add cannot determine whether a package exposes a library target from the index alone. Instead of waiting until a later build, this implementation follows the approach suggested in #11803 (comment) by downloading the resolver-selected package (when network access is available) and inspecting its manifest to determine whether it provides a library target.

Closes #11803

[rustbot]

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @epage, @weihanglo
• @epage, @weihanglo expanded to epage, weihanglo
• Random selection from epage, weihanglo

[epage]

Closes #11803

Note that the linked Issue is a "needs mentor". In #11803 (comment), the right way to do this is said to be from the Index with a "It could be worked around" by downloading the package. What I would expect for a PR like this is a comment in the PR description (actually, it really should be in the Issue before making a PR) about why to go ahead with the discouraged route.

[raushan728]

Note that the linked Issue is a "needs mentor"

Yes, I was aware of that.

the right way to do this is said to be from the Index with a "It could be worked around" by downloading the package

I followed the suggested workaround. The registry index does not contain target information, so cargo add cannot determine whether a package provides a library target from the index alone. When network access is available, it downloads the resolver-selected package and inspects its manifest to determine whether a library target exists, rather than trying to infer it from index metadata.

What I would expect for a PR like this is a comment in the PR description (actually, it really should be in the Issue before making a PR) about why to go ahead with the discouraged route.

I've updated the PR description. Specifically, it notes that the index lacks the information needed for this check, so downloading the resolver-selected package is necessary to determine whether a library target is present.

[raushan728]

Also, all tests pass locally for me, including the full Cargo testsuite. The CI failures I'm seeing are only snapshot differences where the output changes from 1.97.0 to 1.97.1.

My local toolchain is: 1.97.0

I'm not sure whether these should be treated as expected snapshot differences due to the toolchain version, or if there's something else I should investigate.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[epage]

Redactions for rust versions weren't preserved, causing test failures

View changes since the review

[epage]

I'm going to close to redirect back to the issue, particularly because I didn't go back up in the thread to the see the status of this and started looking into the details when that isn't the stage this is at. We can always re-open this if we decide on this direction.