cargo install should not need to build the crate to determine there is no binary available

[CAD97]

cargo-lock is a good example of this. cargo-lock only provides a binary with --features cli. If a user doesn't notice this and instead just executes cargo install cargo-lock with a clean build cache, cargo will happily build the cargo-lock library along with all its dependencies before erroring out noting that there are no binaries available.

Since the presence of a binary crate target doesn't require building the crate to discover, it would be better if cargo could give the error before spending CPU time on building the crate.

[lukaslueg]

The problem is the following check, which does not take into account if the required-features in a package's [[bin]] will be satisfied.

cargo/src/cargo/ops/cargo_install.rs

Lines 312 to 314 in 134f614

	if !opts.filter.is_specific() && !pkg.targets().iter().any(|t| t.is_bin()) {
	bail!("specified package `{}` has no binaries", pkg);
	}

[weihanglo]

Since cargo supports dependency features (e.g. features = ["deps/feature"]), it is not possible to validate required features before resolving the dependency graph, which is done inside compile_ws. Hence, We need to dig into compile_ws and deal with at least two problems:

1. make the else if required_features branch work when there is no available binaries to install. And
2. filter_default_targets would include the default lib.rs target, which may not be suitable for cargo install.

cargo/src/cargo/ops/cargo_compile.rs

Lines 1095 to 1100 in b219f0e

	if target.is_lib() || unavailable_features.is_empty() {
	new_unit(&mut units, pkg, target, mode);
	} else if requires_features {
	let required_features = target.required_features().unwrap();
	let quoted_required_features: Vec<String> = required_features
	.iter()

cargo/src/cargo/ops/cargo_compile.rs

Lines 1251 to 1254 in b219f0e

	CompileMode::Build | CompileMode::Check { .. } => targets
	.iter()
	.filter(|t| t.is_bin() || t.is_lib())
	.collect(),

[marshall]

@rustbot claim