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.

Sign up for GitHub

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

Jump to bottom

ICE: rustdoc: Tried to get crate index of builtin macros crate #61804

Closed
remram44 opened this issue Jun 13, 2019 · 6 comments · Fixed by #62086
Closed

ICE: rustdoc: Tried to get crate index of builtin macros crate #61804

remram44 opened this issue Jun 13, 2019 · 6 comments · Fixed by #62086
Labels
A-intra-doc-links Area: Intra-doc links, the ability to link to items in docs by name C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@remram44
Copy link
Contributor

Running cargo doc on rs-sync runs into an ICE today (CI log).

  • cargo 1.37.0-nightly (545f35425 2019-05-23)
  • rustc 1.37.0-nightly (2887008 2019-06-12)
  • rustdoc 1.37.0-nightly (2887008 2019-06-12)
  • Linux amd64 using rustup
$ RUST_BACKTRACE=full cargo doc
 Documenting cfg-if v0.1.2
 Documenting adler32 v1.0.2
   Compiling kernel32-sys v0.2.2
    Checking memchr v0.1.11
    Checking memchr v2.0.1
    Checking unreachable v1.0.0
 Documenting memchr v2.0.1
    Checking log v0.4.0
 Documenting memchr v0.1.11
 Documenting unreachable v1.0.0
    Checking thread_local v0.3.5
    Checking aho-corasick v0.5.3
    Checking aho-corasick v0.6.4
    Checking log v0.3.9
 Documenting kernel32-sys v0.2.2
    Checking thread-id v2.0.0
    Checking regex v0.2.4
    Checking thread_local v0.2.7
error: internal compiler error: src/librustc/hir/def_id.rs:51: Tried to get crate index of builtin macros crate

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:643:9
stack backtrace:
    Checking regex v0.1.80
   0:     0x7fc38dd7f17b - backtrace::backtrace::libunwind::trace::h37e8a367d6921aa8
                               at /cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/libunwind.rs:88
   1:     0x7fc38dd7f17b - backtrace::backtrace::trace_unsynchronized::h248427898d35c0c6
                               at /cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/mod.rs:66
   2:     0x7fc38dd7f17b - std::sys_common::backtrace::_print::he196ebe73104e0d6
                               at src/libstd/sys_common/backtrace.rs:47
   3:     0x7fc38dd7f17b - std::sys_common::backtrace::print::hea7e6b9f756deddc
                               at src/libstd/sys_common/backtrace.rs:36
   4:     0x7fc38dd7f17b - std::panicking::default_hook::{{closure}}::hdb08e9c6d066c960
                               at src/libstd/panicking.rs:198
   5:     0x7fc38dd7ee7c - std::panicking::default_hook::h0cb542c8a02e7512
                               at src/libstd/panicking.rs:212
   6:     0x7fc38dd7f8f0 - std::panicking::rust_panic_with_hook::h48a72e8eabfd4099
                               at src/libstd/panicking.rs:475
   7:     0x7fc38e8e94dd - std::panicking::begin_panic::hc6a0004ee4956ade
   8:     0x7fc38e90959f - rustc_errors::Handler::bug::hcf07ca34a6805319
   9:     0x7fc38f9e2933 - rustc::util::bug::opt_span_bug_fmt::{{closure}}::h30e49872349e1b56
  10:     0x7fc38f9d48ca - rustc::ty::context::tls::with_opt::{{closure}}::hc208fb6746701e51
  11:     0x7fc38f9d47e5 - rustc::ty::context::tls::with_context_opt::h15cdcb1db35091b0
  12:     0x7fc38f9d4877 - rustc::ty::context::tls::with_opt::h891d00ecedec2006
  13:     0x7fc38f9e2848 - rustc::util::bug::opt_span_bug_fmt::h70b20b7323044267
  14:     0x7fc38f9e27b2 - rustc::util::bug::bug_fmt::had20fba359e6cb41
  15:     0x563306096ab3 - rustc::ty::query::__query_compute::crate_name::h8b43c1f26b00fb9c
  16:     0x5633060bbd09 - rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::crate_name>::compute::hff5eac7498ce3951
  17:     0x5633060a0352 - rustc::dep_graph::graph::DepGraph::with_task_impl::h5f8fa552d5e4edae
  18:     0x5633060cf681 - rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query::h553e4393c1761ee0
  19:     0x563305fd53b9 - rustdoc::clean::inline::record_extern_fqn::hc278d9460d71fbac
  20:     0x563305ff7544 - rustdoc::clean::register_res::he2e76e71c93a2a42
  21:     0x563305e67a3f - <rustdoc::passes::collect_intra_doc_links::LinkCollector as rustdoc::fold::DocFolder>::fold_item::he61b0ea3b3aff64d
  22:     0x563305e6ab3c - <rustdoc::passes::collect_intra_doc_links::LinkCollector as rustdoc::fold::DocFolder>::fold_crate::heb139cd0d64723fb
  23:     0x563305e64938 - rustdoc::passes::collect_intra_doc_links::collect_intra_doc_links::hd59b413f945905ea
  24:     0x563305f663e9 - rustc::ty::context::tls::enter_global::h67954f21b2bb08db
  25:     0x563305f945f5 - rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}::h130794a59f0212d7
  26:     0x7fc391436615 - rustc_interface::passes::create_global_ctxt::{{closure}}::h9455f3a1e30caa2a
  27:     0x563305f94dba - rustc_interface::interface::run_compiler_in_existing_thread_pool::h05ad216b805d92e6
  28:     0x5633060b43a5 - rustdoc::core::run_core::h107268107fd770cb
  29:     0x563305f497e9 - <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::h671b84da37a2eeed
  30:     0x5633060839b4 - std::panicking::try::do_call::h2594efe39321f4f4
  31:     0x7fc38dd908ca - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:85
  32:     0x563305e73b1f - rustdoc::main_options::h8151ccbbcb801724
  33:     0x563306077987 - std::thread::local::LocalKey<T>::with::h2858f3258f098c48
  34:     0x563305f92665 - scoped_tls::ScopedKey<T>::set::h987e033854ca136b
  35:     0x563305f68d62 - syntax::with_globals::h631ab6d18b38e093
  36:     0x563305fb7cb3 - std::sys_common::backtrace::__rust_begin_short_backtrace::h08deae4a6f64f6b0
  37:     0x7fc38dd908ca - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:85
  38:     0x563305e3de69 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hfca600189f1ae5f0
  39:     0x7fc38dd62edf - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::hbbe4b50e56f896eb
                               at /rustc/2887008e0ce0824be4e0e9562c22ea397b165c97/src/liballoc/boxed.rs:746
  40:     0x7fc38dd8f5a0 - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h7ab4448ee8ad917c
                               at /rustc/2887008e0ce0824be4e0e9562c22ea397b165c97/src/liballoc/boxed.rs:746
  41:     0x7fc38dd8f5a0 - std::sys_common::thread::start_thread::h0cd07c3bb37a8763
                               at src/libstd/sys_common/thread.rs:13
  42:     0x7fc38dd8f5a0 - std::sys::unix::thread::Thread::new::thread_start::h6a06e7fee86bebc7
                               at src/libstd/sys/unix/thread.rs:79
  43:     0x7fc38d8f76db - start_thread
  44:     0x7fc38d40888f - __clone
  45:                0x0 - <unknown>
error: aborting due to previous error


note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.37.0-nightly (2887008e0 2019-06-12) running on x86_64-unknown-linux-gnu

error: Could not document `cfg-if`.

Caused by:
  process didn't exit successfully: `rustdoc --crate-name cfg_if /home/remram/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/cfg-if-0.1.2/src/lib.rs --cap-lints allow --color always -o /home/remram/Documents/programming/rs-sync/target/doc -L dependency=/home/remram/Documents/programming/rs-sync/target/debug/deps` (exit code: 1)
warning: build failed, waiting for other jobs to finish...
error: build failed
@jonas-schievink jonas-schievink added C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ I-nominated T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Jun 13, 2019
@QuietMisdreavus
Copy link
Member

Looks like the failure is in an older version of cfg-if. If you update your Cargo.lock file, it should update to a version that skips this bug.

Minimal reproduction:

//! [cfg]

Looks like it's trying to treat [cfg] as an intra-doc-link link anchor, and found the #[cfg] attribute to match it to. We probably need to check whether the result of a lookup is a builtin attribute before trying to register it.

@remram44
Copy link
Contributor Author

Thanks, I'll try to update! This might be worth fixing in rustdoc though.

@QuietMisdreavus
Copy link
Member

Yeah, i'm investigating how we'd fix this in rustdoc.

@jonas-schievink jonas-schievink added the A-intra-doc-links Area: Intra-doc links, the ability to link to items in docs by name label Jun 16, 2019
@QuietMisdreavus QuietMisdreavus mentioned this issue Jun 17, 2019
Closed
@QuietMisdreavus
Copy link
Member

I've opened #61916 to start resolving intra-doc links to builtin macros.

@jonas-schievink jonas-schievink mentioned this issue Jun 19, 2019
Closed
@HeroicKatora HeroicKatora mentioned this issue Jun 19, 2019
Merged
@QuietMisdreavus QuietMisdreavus mentioned this issue Jul 2, 2019
Merged
@orlp
Copy link
Contributor

orlp commented Jul 14, 2019 •
edited
Loading

I just reproduced this today on nightly with Windows 10. No issue on stable.

@mathewcohle mathewcohle mentioned this issue Jul 20, 2019
Closed
@petrochenkov
Copy link
Contributor

Fixed in #62086.

Centril added a commit to Centril/rust that referenced this issue Jul 26, 2019
@Centril
Rollup merge of rust-lang#62086 - petrochenkov:builtout, r=eddyb
c5c5534 
Define built-in macros through libcore

This PR defines built-in macros through libcore using a scheme similar to lang items (attribute `#[rustc_builtin_macro]`).
All the macro properties (stability, visibility, etc.) are taken from the source code in libcore, with exception of the expander function transforming input tokens/AST into output tokens/AST, which is still provided by the compiler.

The macros are made available to user code through the standard library prelude (`{core,std}::prelude::v1`), so they are still always in scope.
As a result **built-in macros now have stable absolute addresses in the library**, like `core::prelude::v1::line!()`, this is an insta-stable change.

Right now `prelude::v1` is the only publicly available absolute address for these macros, but eventually they can be moved into more appropriate locations with library team approval (e.g. `Clone` derive -> `core::clone::Clone`).

Now when built-in macros have canonical definitions they can be imported or reexported without issues (rust-lang#61687).

Other changes:
- You can now define a derive macro with a name matching one of the built-in derives (rust-lang#52269). This was an artificial restriction that could be worked around with import renaming anyway.

Known regressions:
- Empty library crate with a crate-level `#![test]` attribute no longer compiles without `--test`. Previously it didn't compile *with* `--test` or with the bin crate type.

Fixes rust-lang#61687
Fixes rust-lang#61804
r? @eddyb
bors added a commit that referenced this issue Jul 26, 2019
@bors
Auto merge of #62086 - petrochenkov:builtout, r=eddyb
09e3989 
Define built-in macros through libcore

This PR defines built-in macros through libcore using a scheme similar to lang items (attribute `#[rustc_builtin_macro]`).
All the macro properties (stability, visibility, etc.) are taken from the source code in libcore, with exception of the expander function transforming input tokens/AST into output tokens/AST, which is still provided by the compiler.

The macros are made available to user code through the standard library prelude (`{core,std}::prelude::v1`), so they are still always in scope.
As a result **built-in macros now have stable absolute addresses in the library**, like `core::prelude::v1::line!()`, this is an insta-stable change.

Right now `prelude::v1` is the only publicly available absolute address for these macros, but eventually they can be moved into more appropriate locations with library team approval (e.g. `Clone` derive -> `core::clone::Clone`).

Now when built-in macros have canonical definitions they can be imported or reexported without issues (#61687).

Other changes:
- You can now define a derive macro with a name matching one of the built-in derives (#52269). This was an artificial restriction that could be worked around with import renaming anyway.

Known regressions:
- Empty library crate with a crate-level `#![test]` attribute no longer compiles without `--test`. Previously it didn't compile *with* `--test` or with the bin crate type.

Fixes #61687
Fixes #61804
r? @eddyb
@petrochenkov petrochenkov mentioned this issue Aug 8, 2019
Closed
@dtolnay dtolnay mentioned this issue Aug 12, 2019
Closed
dtolnay added a commit to dtolnay/syn that referenced this issue Aug 12, 2019
@dtolnay
Work around intra doc link bug
831e273 
rust-lang/rust#61804
The bug is fixed in nightly but docs.rs hasn't picked up the fix yet.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-intra-doc-links Area: Intra-doc links, the ability to link to items in docs by name C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
5 participants
@orlp @remram44 @jonas-schievink @QuietMisdreavus @petrochenkov