Skip to content

Panic in cargo doc with resolver = "2" when indirectly depending on proc-macro2 #9064

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
maddiemort opened this issue Jan 11, 2021 · 2 comments · Fixed by #9077
Closed

Panic in cargo doc with resolver = "2" when indirectly depending on proc-macro2 #9064

maddiemort opened this issue Jan 11, 2021 · 2 comments · Fixed by #9077
Assignees
Labels
A-features2 Area: issues specifically related to the v2 feature resolver C-bug Category: bug Command-doc P-high Priority: High

Comments

@maddiemort
Copy link

maddiemort commented Jan 11, 2021

Problem
cargo doc panics when run on crate A that depends on crate B, when crate B depends on proc-macro2. This does not happen when directly running cargo doc on crate B.

Error & Backtrace
thread 'main' panicked at 'activated_features for invalid package: features did not find PackageId { name: "proc-macro2", version: "1.0.24", source: "registry `https://github.com/rust-lang/crates.io-index`" } false

Stack backtrace:
   0: std::backtrace::Backtrace::create
   1: std::backtrace::Backtrace::capture
   2: cargo::core::resolver::features::ResolvedFeatures::activated_features_int
   3: cargo::core::compiler::unit_dependencies::new_unit_dep_with_profile
   4: cargo::core::compiler::unit_dependencies::compute_deps
   5: cargo::core::compiler::unit_dependencies::deps_of
   6: cargo::core::compiler::unit_dependencies::deps_of
   7: cargo::core::compiler::unit_dependencies::build_unit_dependencies
   8: cargo::ops::cargo_compile::create_bcx
   9: cargo::ops::cargo_compile::compile_ws
  10: cargo::ops::cargo_compile::compile
  11: cargo::ops::cargo_doc::doc
  12: cargo::commands::doc::exec
  13: cargo::cli::main
  14: cargo::main
  15: std::sys_common::backtrace::__rust_begin_short_backtrace
  16: std::rt::lang_start::{{closure}}
  17: std::rt::lang_start_internal
  18: _main', src/tools/cargo/src/cargo/core/resolver/features.rs:235:14
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::option::expect_none_failed
   3: cargo::core::compiler::unit_dependencies::new_unit_dep_with_profile
   4: cargo::core::compiler::unit_dependencies::compute_deps
   5: cargo::core::compiler::unit_dependencies::deps_of
   6: cargo::core::compiler::unit_dependencies::deps_of
   7: cargo::core::compiler::unit_dependencies::build_unit_dependencies
   8: cargo::ops::cargo_compile::create_bcx
   9: cargo::ops::cargo_compile::compile_ws
  10: cargo::ops::cargo_compile::compile
  11: cargo::ops::cargo_doc::doc
  12: cargo::commands::doc::exec
  13: cargo::cli::main
  14: cargo::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Steps

  1. Clone the minimal example at https://github.com/nerosnm/proc-macro-resolver-bug
  2. Run cargo doc (or, more explicitly, cargo +nightly-2021-01-10 doc)

Possible Solution(s)
This looks similar to #8774 to me, although from what I can tell it's not explicitly relying on any features specific to the new resolver.

Notes
Output of cargo version: cargo 1.51.0-nightly (329895f 2021-01-06)

@maddiemort maddiemort added the C-bug Category: bug label Jan 11, 2021
@maddiemort maddiemort changed the title Panic in cargo doc with resolver = "2" when depending on proc-macro2 Panic in cargo doc with resolver = "2" when indirectly depending on proc-macro2 Jan 11, 2021
@rustbot
Copy link
Collaborator

rustbot commented Jan 11, 2021

Error: The feature relabel is not enabled in this repository.
To enable it add its section in the triagebot.toml in the root of the repository.

Please let @rust-lang/release know if you're having trouble with this bot.

@ehuss ehuss self-assigned this Jan 11, 2021
@ehuss ehuss added P-high Priority: High A-features2 Area: issues specifically related to the v2 feature resolver Command-doc labels Jan 11, 2021
@ehuss
Copy link
Contributor

ehuss commented Jan 11, 2021

@nerosnm Thanks for the clear report and reproduction. I see what's going on, but it is uncovering some long festering problems with how cargo integrates with rustdoc. I'll need to think about it for a bit to try to decide on the best course to take.

@bors bors closed this as completed in 783bc43 Jan 20, 2021
bors added a commit that referenced this issue Dec 18, 2022
Enable triagebot's relabel functionality

### What does this PR try to resolve?

This fixes the following failure that rustbot currently posts whenever someone tries to use "<b>`@</b><b>rustbot</b>` label" in this repository.

> **Error**: The feature `relabel` is not enabled in this repository.
> To enable it add its section in the `triagebot.toml` in the root of the repository.

Unauthenticated relabel has been enabled in rust-lang/rust for nearly 4 years. People overwhelmingly use it in good faith.

<br>

### How should we test and review this PR?

Compare against https://github.com/rust-lang/rust/blob/1.66.0/triagebot.toml.

Also skim through the 7 pages of labels on https://github.com/rust-lang/cargo/labels, whether it makes sense the ones I decided to allow arbitrary GitHub users to apply.

<br>

### Additional information

Attempted uses of "<b>`@</b><b>rustbot</b>` label", that failed, but this PR would allow:

- #10343 (comment)
- #10243 (comment)
- #9982 (comment)
- #9128 (comment)
- #9067 (comment)
- #8441 (comment)
- #11432 (comment)
- #8841 (comment)
- #10820 (comment)
- #10572 (comment)
- #9114 (comment)
- #8980 (comment)
- #9064 (comment)
- #8726 (comment)
- #8089 (comment)
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-features2 Area: issues specifically related to the v2 feature resolver C-bug Category: bug Command-doc P-high Priority: High
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants