Skip to content

panic: "rustdoc should not accept multiple -p flags" with --document-private-items #5958

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
jashank opened this issue Sep 1, 2018 · 4 comments · Fixed by #6022
Closed

panic: "rustdoc should not accept multiple -p flags" with --document-private-items #5958

jashank opened this issue Sep 1, 2018 · 4 comments · Fixed by #6022
Labels

Comments

@jashank
Copy link

jashank commented Sep 1, 2018

Running cargo 1.29.0-nightly (0ec7281 2018-08-20) on x86_64-unknown-linux-gnu.
I've grabbed rust-lang-nursery/futures-rs from Git, and am attempting to generate documentation. If I do cargo doc --document-private-items in the workspace at the root of the repo, I get a panic:

> cargo doc -v -v --document-private-items
thread 'main' panicked at '`rustdoc` should not accept multiple `-p` flags', tools/cargo/src/cargo/ops/cargo_compile.rs:259:9
stack backtrace:
   0:     0x55e0b4644a4e - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h7047c1a597dcbdc4
                               at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1:     0x55e0b462ea26 - std::sys_common::backtrace::print::hc896935949d1a0e3
                               at libstd/sys_common/backtrace.rs:71
                               at libstd/sys_common/backtrace.rs:59
   2:     0x55e0b462cb6d - std::panicking::default_hook::{{closure}}::h8ce6b22d84426080
                               at libstd/panicking.rs:211
   3:     0x55e0b462c8e0 - std::panicking::default_hook::h532f37e19dbd6862
                               at libstd/panicking.rs:227
   4:     0x55e0b462d1dc - std::panicking::rust_panic_with_hook::h20449f9d67a691e6
                               at libstd/panicking.rs:477
   5:     0x55e0b462cdd9 - std::panicking::continue_panic_fmt::h9d6a073457a16c6e
                               at libstd/panicking.rs:391
   6:     0x55e0b462cd3d - std::panicking::begin_panic_fmt::hbe3fc570c77e117d
                               at libstd/panicking.rs:346
   7:     0x55e0b3fd5752 - cargo::ops::cargo_compile::compile_ws::h3fcd3698049de63e
   8:     0x55e0b3fd1ec5 - cargo::ops::cargo_compile::compile::h242d2630c8ecc9d9
   9:     0x55e0b3f9649c - cargo::ops::cargo_doc::doc::hac0a5efb429b1e31
  10:     0x55e0b3f3a103 - cargo::commands::doc::exec::hc799ec035f885e60
  11:     0x55e0b3eef250 - cargo::cli::main::hc641b2acdafd186e
  12:     0x55e0b3f03487 - cargo::main::h8b228ee40e8d5fa9
  13:     0x55e0b3f1d4d2 - std::rt::lang_start::{{closure}}::he6641002b10560d8
  14:     0x55e0b462cc72 - std::panicking::try::do_call::hbae78c8d6c9d0d09
                               at libstd/rt.rs:59
                               at libstd/panicking.rs:310
  15:     0x55e0b4658579 - __rust_maybe_catch_panic
                               at libpanic_unwind/lib.rs:103
  16:     0x55e0b463cd75 - std::rt::lang_start_internal::h5a1694262f452700
                               at libstd/panicking.rs:289
                               at libstd/panic.rs:392
                               at libstd/rt.rs:58
  17:     0x55e0b3f05643 - main
  18:     0x7f8c58cb7002 - __libc_start_main
  19:     0x55e0b3ee4128 - <unknown>
@ehuss
Copy link
Contributor

ehuss commented Sep 1, 2018

If you want a workaround, you can run:
RUSTDOCFLAGS=--document-private-items cargo doc

I'm not sure I understand the original motivation for the restriction that custom flags can only apply to one Unit, especially considering you can use environment variables to circumvent that restriction.

@alexcrichton
Copy link
Member

Thanks for the report! Definitely a bug in Cargo we should fix!

@ehuss
Copy link
Contributor

ehuss commented Sep 2, 2018

@alexcrichton What do you think about removing the "only one unit" restriction for cargo rustdoc? I can't think of a specific reason to prevent that. If not, we'll need to add a new way to pass in extra arguments that don't have that restriction.

@alexcrichton
Copy link
Member

@ehuss I think we'll want to keep that for the cargo rustc and cargo rustdoc commands as their intention is to execute precisely one rustc/rustdoc invocation with custom arguments, but the implementation of cargo doc --document-private-items can probably just be updated to use a different implementation mechanism.

ehuss added a commit to ehuss/cargo that referenced this issue Sep 13, 2018
bors added a commit that referenced this issue Sep 13, 2018
Fix --document-private-items for multiple targets.

Closes #5958.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants