--unit-test doesnt seem to be able to prioritise lib over bin

[akanalytics]

Using --unit-test when my crate builds both a single bin and a single lib fails.

$ cargo flamegraph --unit-test -- my_test
Error: several possible targets found: [BinaryTarget { package: "odonata", target: "odonata", kind: ["lib"] }, BinaryTarget { package: "odonata", target: "odonata", kind: ["bin"] }], please pass an explicit target.

But --unit-test and --bin are incompatible options (and really I want to specify lib somehow)

--verbose doesnt show any additional info

Removing "bin" from the below fixes this - but probably isnt the right fix.

} else if let Some(unit_test) = opt.unit_test {
let target = find_unique_target(
&["bin", "lib"],
opt.package.as_deref(),
opt.manifest_path.as_deref(),
unit_test.as_deref(),
)?;

[djc]

I'm honestly not sure I completely understood your bug report. It seems fair that cargo flamegraph --unit-test -- my_test should work if there is such a test, but I'm not sure what you mean by incompatible options. Without context, it's also a bit hard to judge the code change you suggest. Could you give some more context and/or submit a PR to suggest a change that you think would fix the issue here?

[akanalytics]

To clarify.

My project builds as a lib and a single bin. ie I have [[bin] and [lib] entries in my cargo.toml. This is very typical and the bin simply uses the lib.

The code from flamegraph below means that both "bin" and "lib" are "searched" when --unit-test is used. And hence no unique target is found.

} else if let Some(unit_test) = opt.unit_test {
let target = find_unique_target(
&["bin", "lib"],
opt.package.as_deref(),
opt.manifest_path.as_deref(),
unit_test.as_deref(),
)?;

This results in the error below

Error: several possible targets found: [BinaryTarget { package: "odonata", target: "odonata", kind: ["lib"] }, BinaryTarget { package: "odonata", target: "odonata", kind: ["bin"] }], please pass an explicit target.

If I try and specify that I only want the "bin" considered by running the command with "--bin" option

cargo flamegraph --unit-test --bin -- my_test

then I get the error

error: The argument '--unit-test [<UNIT_TEST>]' cannot be used with '--bin '

USAGE:
cargo flamegraph <--bin |--example |--test |--unit-test [<UNIT_TEST>]|--bench > <TRAILING_ARGUMENTS>...

Hence there appears no way to say although my project consists of a lib and a bin, please do not refuse to run the unit-test thinking I need to specifiy a specific binary.

When I change the code below

} else if let Some(unit_test) = opt.unit_test {
let target = find_unique_target(
&["bin", "lib"],
opt.package.as_deref(),
opt.manifest_path.as_deref(),
unit_test.as_deref(),
)?;

so that

        &["lib"],

is used instead, it works, for my project. But this probably isnt the right fix. My project has a single bin and a lib.
I dont know the flamegraph codebase, but Im assuming this is trying to catch the case when there are several bin's and they each have their own unit test? Unsure.

I notice in the code that there is logic:

if let Some(Some(ref unit_test)) = opt.unit_test {
match kind.into_iter().any(|k| k == "lib") {
true => cmd.arg("--lib"),
false => cmd.args(&["--bin", unit_test]),
};
}

Which seems to imply that when unit test is specified that "lib" is prefered. But this doesnt stop me getting the error, as this logic is in the "build()" function, and find_unique_target() function is called first (and fails) with the "several possible targets" error...

Error: several possible targets found: [BinaryTarget { package: "odonata", target: "odonata", kind: ["lib"] }, BinaryTarget { package: "odonata", target: "odonata", kind: ["bin"] }], please pass an explicit target.

[djc]

If you want to submit a fix in a PR, I'd be happy to review it.

[carloskiki]

I have also noted this bug, and will open a PR soon.

[wminshew]

Hitting this bug rn -- confirmed that the current build doesn't allow you to flamegraph unit-tests if you have a main & lib with the same name (which is standard practice I think?)

[djc]

If you want to help with a fix (seems #290 has stalled) that would be great.

[felipou]

I created this PR with the simplest solution I could come up with, that just adds a new option, not changing anything else if not used: #322