0.13.0 and later will hang forever

[adamchalmers]

Describe the bug
When I run cargo deny check on my project, it hangs forever. This does not happen in 0.12.0, but happens in every 0.13.x release so far.

To Reproduce
I haven't got an open-source reproduction, because the dependency which makes cargo deny check hang forever is closed-source. It does use features and a build.rs which generates protobuf stubs using tonic 0.8, and @OrionNebula says

It uses a bunch of CPU while it's stuck. I was able to pull this stack trace:

* frame #0: 0x0000000102b08220 cargo-deny`_$LT$krates..builder..features..ParsedFeature$u20$as$u20$core..convert..From$LT$$RF$str$GT$$GT$::from::hf68f245ee90305bc + 880
    frame EmbarkStudios/cargo-deny#1: 0x0000000102af78e8 cargo-deny`core::ops::function::impls::_$LT$impl$u20$core..ops..function..FnMut$LT$A$GT$$u20$for$u20$$RF$mut$u20$F$GT$::call_mut::heacbba78aae5bd8a + 1252
    frame EmbarkStudios/cargo-deny#2: 0x0000000102b1a79c cargo-deny`_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$alloc..vec..spec_from_iter..SpecFromIter$LT$T$C$I$GT$$GT$::from_iter::h95bc6335c05ec316 + 112
    frame EmbarkStudios/cargo-deny#3: 0x0000000102b03914 cargo-deny`krates::builder::Builder::build_with_metadata::h3b97f71ebdbfe52c + 2812
    frame EmbarkStudios/cargo-deny#4: 0x0000000102b38434 cargo-deny`cargo_deny::common::KrateContext::gather_krates::h305c801079727285 + 1528
    frame EmbarkStudios/cargo-deny#5: 0x0000000102ac1d94 cargo-deny`_$LT$core..panic..unwind_safe..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h20701a9243b8a631 + 168
    frame EmbarkStudios/cargo-deny#6: 0x0000000102b50ec4 cargo-deny`std::panicking::try::hceb1dcc0c38e1c37 + 76
    frame EmbarkStudios/cargo-deny#7: 0x0000000102aeed2c cargo-deny`_$LT$rayon_core..job..HeapJob$LT$BODY$GT$$u20$as$u20$rayon_core..job..Job$GT$::execute::h881373966ed269c9 + 312
    frame EmbarkStudios/cargo-deny#8: 0x0000000102facc08 cargo-deny`rayon_core::registry::WorkerThread::wait_until_cold::hccf0349944ec2090 + 288
    frame EmbarkStudios/cargo-deny#9: 0x0000000102e6fe84 cargo-deny`rayon_core::registry::ThreadBuilder::run::hcec1fb84ac686d4a + 584
    frame EmbarkStudios/cargo-deny#10: 0x0000000102e72748 cargo-deny`std::sys_common::backtrace::__rust_begin_short_backtrace::heba377b850be9f58 + 52
    frame EmbarkStudios/cargo-deny#11: 0x0000000102e6c604 cargo-deny`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::ha077a802a4cc31a1 + 172
    frame EmbarkStudios/cargo-deny#12: 0x0000000102f7b41c cargo-deny`std::sys::unix::thread::Thread::new::thread_start::h403ab16d5f453cd4 [inlined] _$LT$alloc..boxed..Box$LT$F$C$A$GT$$u20$as$u20$core..ops..function..FnOnce$LT$Args$GT$$GT$::call_once::h8a0d110322a74330 at boxed.rs:1935:9 [opt]
    frame EmbarkStudios/cargo-deny#13: 0x0000000102f7b410 cargo-deny`std::sys::unix::thread::Thread::new::thread_start::h403ab16d5f453cd4 [inlined] _$LT$alloc..boxed..Box$LT$F$C$A$GT$$u20$as$u20$core..ops..function..FnOnce$LT$Args$GT$$GT$::call_once::h381d30f48837780e at boxed.rs:1935:9 [opt]
    frame EmbarkStudios/cargo-deny#14: 0x0000000102f7b40c cargo-deny`std::sys::unix::thread::Thread::new::thread_start::h403ab16d5f453cd4 at thread.rs:108:17 [opt]
    frame EmbarkStudios/cargo-deny#15: 0x000000019168826c libsystem_pthread.dylib`_pthread_start + 148
    ```
> Which I think comes from this line: https://docs.rs/krates/latest/src/krates/builder.rs.html#875 (or something in that statement anyway)

**Expected behavior**
cargo deny check should terminate in a few seconds

**Device:**
 - OS: macOS Monterey
 - Architecture: tested on both Intel arm64 and Apple Silicon M1 (aarch64)

**Additional context**
I'm sorry this is so vague, I am trying to reproduce in an open-source way. But I figured I'd open this issue now, even though it's not very helpful, in case anyone else has this problem with an open-source crate.

[Jake-Shadle]

Would it be possible to just post the output of cargo metadata --format-version 1 to a gist?

[adamchalmers]

Yeah, here it is, in pretty or raw JSON

[Jake-Shadle]

It seems the proto_schema crate has cyclic feature references

"features": {
  "auditlog-receiver-v1": [
      "auditlog-receiver-v1-ans-v1",
      "blocks-v1",
      "blocks-v2",
      "challenges-widgets-v1",
      "dlp-v1",
      "dns-firewall-v1",
      "emailrouting-config-v1",
      "emailrouting-v2",
      "iam-iapi-v1",
      "web3-config-v1",
      "zaraz-config-v1"
  ],
  "auditlog-receiver-v1-ans-v1": [
      "auditlog-receiver-v1"
  ],
}

I wasn't protecting against that because I could have sworn cargo would actually error if there were cyclic references like that, but maybe that doesn't apply to features, only crates, fixing.

[Jake-Shadle]

Thanks for the repro!

[adamchalmers]

Thanks for the quick fix :)