[enhancement] "false positive" on a complex dependency in libra

[huitseeker]

TL;DR:

cargo-guppy doesn't support the use case of a feature-controlled dependency, and reports both alternatives as dependencies.

This is not really a bug, rather an understandable limitation, because I can't imagine how introspection into manually-built xor-semantics of features (something only made possible by the recent resolver v2) would naturally fall into scope.

The present issue is hence more for awareness, or to advocate for a possible warning inviting a second look on dependencies:

• marked as optional, and,
• loaded as part of a feature switch.

Long form:

On PR diem/diem#4970
a crate in Libra switches from having a single dependency source and offering a feature switch for whether an upstream feature therein is activated or not:

[dependencies]
foo = { ... }

[features]
default = [ "bazfeat"]
bazfeat = ["foo/bazfeat"]
barfeat = ["foo/barfeat"]

To having two dependencies and choosing (exclusively) between them using the same sort of feature switch:

[dependencies]
foo = { ..., features = ["bazfeat"], optional = true}
quux = { <some other source for the same dep> , package = 'foo', features = ["barfeat"], optional = true}

[features]
default = [ "bazfeat"]
bazfeat = ["foo"]
barfeat = ["quux"]

Then in code:

#[cfg(feature = "barfeat")]
use quux as foo;

(a later PR makes explicit those are meant to be loaded exclusively)

Upon that change, the following script:
diem/diem#4132

Reports each alternative foo, quux as dependencies, and therefore records this PR as "adding" quux.

cc: @metajack