tests/normal-dev-build.rs test failures since update of cargo

[est31]

Since the update of cargo to 0.66 in a103529 , there have been two regressions. One was fixed by a14f2a7, but the second is still around:

      Running `/home/runner/work/cargo-udeps/cargo-udeps/target/debug/deps/normal_dev_build-9001a7bb6731d304`

running 2 tests
test with_all_targets ... FAILED
test without_all_targets ... ok

failures:

---- with_all_targets stdout ----
thread 'with_all_targets' panicked at 'assertion failed: `(left == right)`

Diff < left / right > :
 unused dependencies:
 `normal_dev_build v0.0.1 (██████████)`
 ├─── dependencies
 │    └─── "if_chain"
<├─── dev-dependencies
<│    └─── "maplit"
 └─── build-dependencies
      └─── "matches"
 Note: They might be false-positive.
       For example, `cargo-udeps` cannot detect usage of crates that are only used in doc-tests.
       To ignore some dependencies, write `package.metadata.cargo-udeps.ignore` in Cargo.toml.

Through a git bisect of cargo, I've traced this down to the clap upgrade of cargo, that means any commit before works, any commit after doesn't. Also, the issue has nothing to do with the rustc used, as both the older and newer rustc work. I'm filing this issue to collect more information about the regression.

[est31]

Also, FTR, this is the reason why I've held back a release of cargo-udeps since, because I don't know how widespread the regression is.

[est31]

The issue seems to be that cargo does not interpret the cli arguments of the subcommand any more.

On 19ecf74:

info: filter: Only { all_targets: true, lib: Default, bins: All, examples: All, tests: All, benches: All }

On master:

info: filter: Default { required_features_filterable: true }

(When you do cargo +nightly test --all --no-fail-fast --test normal-dev-build with_all_target, and add a line config.shell().info(format_args!("filter: {:?}", compile_opts.filter))?; to OptUdeps::run, plus change stderr = Shell::from_write(Box::new(vec![])) to stderr = Shell::new() in Runner::run for printing).

[est31]

Workaround applied in 0d4889b. Upstream issue filed: clap-rs/clap#4869