cargo run --example false positive "is a library and cannot be executed"

[Walther]

RustAudio/vst-rs#71

In rust-vst's Cargo.toml, there is the following definition:

[[example]]
name = "simple_host"
crate-type = ["bin"]

among other example declarations which are crate-type = ["cdylib"] instead.

Trying to run it:

cargo run --example simple_host
error: example target `simple_host` is a library and cannot be executed

However, if you simply remove the line crate-type = ["bin"], it starts working.

<&mbrubeck> Walther: I think the bug is here https://github.com/rust-lang/cargo/blob/master/src/cargo/core/manifest.rs#L654-L658
<&mbrubeck> Any non-empty list is treated as ExampleLib, which triggers https://github.com/rust-lang/cargo/blob/master/src/cargo/ops/cargo_run.rs#L40-L45

[Walther]

Looking at

cargo/src/cargo/core/manifest.rs

Lines 647 to 658 in 5dbac98

	pub fn example_target(
	name: &str,
	crate_targets: Vec<LibKind>,
	src_path: PathBuf,
	required_features: Option<Vec<String>>,
	edition: Edition,
	) -> Target {
	let kind = if crate_targets.is_empty() {
	TargetKind::ExampleBin
	} else {
	TargetKind::ExampleLib(crate_targets)
	};

it seems there's a heavy assumption that examples will only ever be libraries.

If one changes the type signature to Vec<TargetKind>, line 655 TargetKind::ExampleLib(crate_targets) errors because ExampleLib cannot take TargetKind as an input. Additionally, there's a new error in line 355

cargo/src/cargo/util/toml/targets.rs

Lines 328 to 371 in 90fc9f6

	fn clean_examples(
	features: &Features,
	toml_examples: Option<&Vec<TomlExampleTarget>>,
	package_root: &Path,
	edition: Edition,
	autodiscover: Option<bool>,
	warnings: &mut Vec<String>,
	errors: &mut Vec<String>,
	) -> CargoResult<Vec<Target>> {
	let inferred = infer_from_directory(&package_root.join("examples"));
	let targets = clean_targets(
	"example",
	"example",
	toml_examples,
	&inferred,
	package_root,
	edition,
	autodiscover,
	warnings,
	errors,
	"autoexamples",
	)?;
	let mut result = Vec::new();
	for (path, toml) in targets {
	let crate_types = match toml.crate_types() {
	Some(kinds) => kinds.iter().map(|s| s.into()).collect(),
	None => Vec::new(),
	};
	let mut target = Target::example_target(
	&toml.name(),
	crate_types,
	path,
	toml.required_features.clone(),
	edition,
	);
	configure(features, &toml, &mut target)?;
	result.push(target);
	}
	Ok(result)
	}

caused by the .into() call:

the trait `std::convert::From<&std::string::String>` is not implemented for `core::manifest::TargetKind`

---

How should this be handled?

• Should we change the type of crate_targets in fn example_target(), and implement the conversion from string to TargetKind as well? How could that be done cleanly, with minimal repetition ref. LibKind's conversion method?
• Should we instead create some sort of an ExampleKind wrapper so that within fn clean_examples() method in targets.rs the into() call can be more restricted?
• Should we just keep the type as crate_targets: Vec<LibKind>, and blindly rely on the LibKind::Other -catch-all in the conversion, and parse for an Other-type and see if it contains a "bin" value? This would feel a bit dirty. On the other hand, that's exactly the codepath that is happening right now for examples with "bin" declared as the type
• On an even broader scope, how should we handle these crate_targets being Vec's - is it valid to have an example with both "lib" and "bin" target? What should happen then? What about possible other lists of targets?

---

(Additionally, while looking through the code, it seems that LibKind type doesn't even know about cdylib at all in manifest.rs. Should it? If so, that's probably a subject for a new issue? )

[alexcrichton]

Thanks for the report, this definitely sounds like a bug! I agree that we should do some actual parsing here and realize that the string bin is a binary, not actually a library.

I'd be down for basically any fix that works here, feel free to refactor as necessary!