Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

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

Closed
nerosnm 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

nerosnm 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

@nerosnm
Copy link

nerosnm 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)

@nerosnm nerosnm added the C-bug Category: bug label Jan 11, 2021
@nerosnm nerosnm 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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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