It’s possible to build optional dependencies not listed in Cargo.lock

[SimonSapin]

Test case: (run in a temporary directory)

cargo new a
cd a
echo 'b = {path = "b"}' >> Cargo.toml
cargo new b
cd b
echo 'c = {path = "c", optional = true}' >> Cargo.toml
cargo new c
cd c
echo 'd = {path = "d"}' >> Cargo.toml
cargo new d
cd ..
cd ..
cargo build --features b/c --verbose
cat Cargo.lock
cd ..
rm -rf a

Output in cargo 0.17.0-nightly (67e4ef1 2017-01-25)

     Created library `a` project
     Created library `b` project
     Created library `c` project
     Created library `d` project
   Compiling d v0.1.0 (file:///tmp/lol/a/b/c/d)
     Running `rustc --crate-name d b/c/d/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=d1f001e6c4277757 -C extra-filename=-d1f001e6c4277757 --out-dir /tmp/lol/a/target/debug/deps -L dependency=/tmp/lol/a/target/debug/deps`
   Compiling c v0.1.0 (file:///tmp/lol/a/b/c)
     Running `rustc --crate-name c b/c/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=d3fb71d0c424d062 -C extra-filename=-d3fb71d0c424d062 --out-dir /tmp/lol/a/target/debug/deps -L dependency=/tmp/lol/a/target/debug/deps --extern d=/tmp/lol/a/target/debug/deps/libd-d1f001e6c4277757.rlib`
   Compiling b v0.1.0 (file:///tmp/lol/a/b)
     Running `rustc --crate-name b b/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 --cfg 'feature="c"' -C metadata=bf9fdaf735940263 -C extra-filename=-bf9fdaf735940263 --out-dir /tmp/lol/a/target/debug/deps -L dependency=/tmp/lol/a/target/debug/deps --extern c=/tmp/lol/a/target/debug/deps/libc-d3fb71d0c424d062.rlib`
   Compiling a v0.1.0 (file:///tmp/lol/a)
     Running `rustc --crate-name a src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 --cfg 'feature="b"' -C metadata=50db5a511b950de6 -C extra-filename=-50db5a511b950de6 --out-dir /tmp/lol/a/target/debug/deps -L dependency=/tmp/lol/a/target/debug/deps --extern b=/tmp/lol/a/target/debug/deps/libb-bf9fdaf735940263.rlib`
    Finished dev [unoptimized + debuginfo] target(s) in 2.22 secs
[root]
name = "a"
version = "0.1.0"
dependencies = [
 "b 0.1.0",
]

[[package]]
name = "b"
version = "0.1.0"

Crates c and d were compiled and used, but are not listed in Cargo.lock.

[alexcrichton]

Definitely looks like a bug! I think that this is only possible from the command line, right?

[SimonSapin]

Yes, for example adding features = ["c"] to the b dependency in the root Cargo.toml adds c in Cargo.lock.

[alexcrichton]

Yeah the change here is that you shouldn't be able to activate a feature that wasn't already in the lock file. To that end you shouldn't be able to activate a transitive feature that wasn't already possible to activate via some local feature.

[SimonSapin]

For what it’s worth, html5ever uses a custom test harness crate (to support dynamically generated tests on stable Rust) which has optional features for stuff that uses unstable std APIs. It’s been very convenient to use cargo test --features rustc-test/capture. This particular feature doesn’t add any additional crate to the build, but it could. I suppose I could live with adding a local test-capture feature to html5ever.

[alexcrichton]

Oh yeah this kind of feature should still be supported, but yeah you'll need some sort of feature locally to optionally enable a transitive feature. That'll ensure everything makes its way to the lock file and prevents weird bugs like updating the registry too often and such.

[SimonSapin]

So what’s the fix? Forbid --features foo/bar on the command line?

[alexcrichton]

Nah ---features foo/bar should still be allowed so long as the feature bar in the package foo could be activated via some other means. For example if it's a workspace member or otherwise a crate already has an optional dependency on foo/bar that'd be allowed.

What wouldn't be allowed is activating foo/bar when otherwise it's impossible to activate bar, as that means the feature isn't in Cargo.lock and may not resolve correctly.