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

ICE when cargo doc on lexical-core: attempted .def_id() on invalid res: Err #64705

Closed
Evrey opened this issue Sep 23, 2019 · 15 comments · Fixed by #67236
Closed

ICE when cargo doc on lexical-core: attempted .def_id() on invalid res: Err #64705

Evrey opened this issue Sep 23, 2019 · 15 comments · Fixed by #67236
Assignees
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-resolve Area: Path resolution A-visibility Area: Visibility / privacy. C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@Evrey
Copy link

Evrey commented Sep 23, 2019

I tried this code: Running cargo doc on a project that has lexical-core 0.6.2 as its direct or indirect dependency.

I expected to see this happen: All packages documented.

Instead, this happened: error: internal compiler error: src/librustc/hir/def.rs:345: attempted .def_id() on invalid res: Err — also fails on docs.rs.

Meta

rustc --version --verbose:

rustc 1.39.0-nightly (1dd188489 2019-09-22)
binary: rustc
commit-hash: 1dd1884891636d0eb51157d137230076bcf20627
commit-date: 2019-09-22
host: x86_64-unknown-linux-gnu
release: 1.39.0-nightly
LLVM version: 9.0

Does also happen for older nightlies, though I forgot to capture the versions before updating in hope it'd fix the issue. There are more ICE issues pointing at def.rs, but none on this line here.

Backtrace:

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:643:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:76
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:60
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1030
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1412
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:64
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:196
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:210
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:473
  11: std::panicking::begin_panic
  12: rustc_errors::Handler::bug
  13: rustc::util::bug::opt_span_bug_fmt::{{closure}}
  14: rustc::ty::context::tls::with_opt::{{closure}}
  15: rustc::ty::context::tls::with_context_opt
  16: rustc::ty::context::tls::with_opt
  17: rustc::util::bug::opt_span_bug_fmt
  18: rustc::util::bug::bug_fmt
  19: rustc::hir::def::Res<Id>::def_id::{{closure}}
  20: rustdoc::clean::register_res
  21: <syntax::source_map::Spanned<rustc::hir::VisibilityKind> as rustdoc::clean::Clean<core::option::Option<rustdoc::clean::Visibility>>>::clean
  22: <rustc::hir::ImplItem as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
  23: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
  24: <rustdoc::doctree::Impl as rustdoc::clean::Clean<alloc::vec::Vec<rustdoc::clean::Item>>>::clean
  25: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::spec_extend
  26: <rustdoc::doctree::Module as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
  27: <rustdoc::doctree::Module as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
  28: <rustdoc::doctree::Module as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
  29: <rustdoc::doctree::Module as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
  30: rustdoc::clean::krate
  31: rustc::ty::context::tls::enter_global
  32: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  33: rustc_interface::passes::create_global_ctxt::{{closure}}
  34: rustc_interface::passes::BoxedGlobalCtxt::enter
  35: rustc_interface::interface::run_compiler_in_existing_thread_pool
  36: rustdoc::core::run_core
  37: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  38: std::panicking::try::do_call
  39: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  40: rustc_driver::catch_fatal_errors
  41: rustdoc::main_options
  42: std::thread::local::LocalKey<T>::with
  43: scoped_tls::ScopedKey<T>::set
  44: syntax::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: aborting due to previous error
@jonas-schievink jonas-schievink added 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. labels Sep 23, 2019
@csmoe csmoe added the E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example label Sep 24, 2019
@ebkalderon
Copy link
Contributor

ebkalderon commented Oct 13, 2019

@jonas-schievink I can confirm that this ICE does not occur on Rust 1.37.0 stable, as shown in #65367 (comment). This might be a regression that slipped through the stable release somehow.

@jonas-schievink jonas-schievink added I-nominated regression-from-stable-to-stable Performance or correctness regression from one stable version to another. A-resolve Area: Path resolution labels Oct 13, 2019
@fredrik-jansson-se
Copy link

This still happens on 1.39 stable.

rustc --version --verbose
rustc 1.39.0 (4560ea788 2019-11-04)
binary: rustc
commit-hash: 4560ea788cb760f0a34127156c78e2552949f734
commit-date: 2019-11-04
host: x86_64-apple-darwin
release: 1.39.0
LLVM version: 9.0

error: internal compiler error: src/librustc/hir/def.rs:345: attempted .def_id() on invalid res: Err

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:812:9
stack backtrace:
  0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
  1: core::fmt::write
  2: std::io::Write::write_fmt
  3: std::panicking::default_hook::{{closure}}
  4: std::panicking::default_hook
  5: std::panicking::rust_panic_with_hook
  6: std::panicking::begin_panic
  7: rustc_errors::HandlerInner::bug
  8: rustc_errors::Handler::bug
  9: rustc::util::bug::opt_span_bug_fmt::{{closure}}
 10: rustc::ty::context::tls::with_opt::{{closure}}
 11: rustc::ty::context::tls::with_context_opt
 12: rustc::ty::context::tls::with_opt
 13: rustc::util::bug::opt_span_bug_fmt
 14: rustc::util::bug::bug_fmt
 15: rustc::hir::def::Res<Id>::def_id::{{closure}}
 16: rustdoc::clean::register_res
 17: <syntax::source_map::Spanned<rustc::hir::VisibilityKind> as rustdoc::clean::Clean<core::option::Option<rustdoc::clean::Visibility>>>::clean
 18: <rustc::hir::ImplItem as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
 19: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
 20: <rustdoc::doctree::Impl as rustdoc::clean::Clean<alloc::vec::Vec<rustdoc::clean::Item>>>::clean
 21: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::spec_extend
 22: <rustdoc::doctree::Module as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
 23: <rustdoc::doctree::Module as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
 24: <rustdoc::doctree::Module as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
 25: <rustdoc::doctree::Module as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
 26: rustdoc::clean::krate
 27: rustc::ty::context::tls::enter_global
 28: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
 29: rustc_interface::passes::create_global_ctxt::{{closure}}
 30: rustc_interface::passes::BoxedGlobalCtxt::enter
 31: rustc_interface::interface::run_compiler_in_existing_thread_pool
 32: rustdoc::core::run_core
 33: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
 34: std::panicking::try::do_call
 35: __rust_maybe_catch_panic
 36: rustc_driver::catch_fatal_errors
 37: rustdoc::main_options
 38: std::thread::local::LocalKey<T>::with
 39: scoped_tls::ScopedKey<T>::set
 40: syntax::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Documenting rayon-core v1.6.1
error: aborting due to previous error

error: Could not document `lexical-core`.

Caused by:
 process didn't exit successfully: `rustdoc --crate-type lib --crate-name lexical_core /Users/frjansso/.cargo/registry/src/github.com-1ecc6299db9ec823/lexical-core-0.6.2/src/lib.rs --cap-lints allow -o /Users/frjansso/dev/rust/advent_of_code2018/target/doc --cfg 'feature="arrayvec"' --cfg 'feature="correct"' --cfg 'feature="ryu"' --cfg 'feature="std"' --cfg 'feature="table"' --color always -L dependency=/Users/frjansso/dev/rust/advent_of_code2018/target/debug/deps --extern arrayvec=/Users/frjansso/dev/rust/advent_of_code2018/target/debug/deps/libarrayvec-3f025bb2d28518a6.rmeta --extern cfg_if=/Users/frjansso/dev/rust/advent_of_code2018/target/debug/deps/libcfg_if-426c934331571334.rmeta --extern ryu=/Users/frjansso/dev/rust/advent_of_code2018/target/debug/deps/libryu-8a280f8b9b571987.rmeta --extern static_assertions=/Users/frjansso/dev/rust/advent_of_code2018/target/debug/deps/libstatic_assertions-512ad2d38db95142.rmeta --cfg has_range_bounds --cfg has_slice_index --cfg has_full_range_inclusive --cfg has_const_index --cfg has_i128 --cfg has_ops_bound --cfg has_pointer_methods --cfg has_range_inclusive --cfg limb_width_64` (exit code: 1)
warning: build failed, waiting for other jobs to finish...
error: build failed

@jonas-schievink
Copy link
Contributor

cc @rust-lang/rustdoc

@nanocryk
Copy link

nanocryk commented Nov 25, 2019

It also does it when documenting a project with hyper-tls:0.4.0-alpha.4 on nightly. I had no trouble documenting all deps more than 2 weeks ago though.

$ rustc --version --verbose
rustc 1.41.0-nightly (412f43ac5 2019-11-24)
binary: rustc
commit-hash: 412f43ac5b4ae8c3599e71c6972112e9be4758fa
commit-date: 2019-11-24
host: x86_64-unknown-linux-gnu
release: 1.41.0-nightly
LLVM version: 9.0
error: internal compiler error: src/librustc/hir/def.rs:385: attempted .def_id() on invalid res: Err

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:892:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:84
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:61
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1030
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1412
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:65
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:50
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:188
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:205
  10: <alloc::boxed::Box<F> as core::ops::function::Fn<A>>::call
             at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/liballoc/boxed.rs:956
  11: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::enter::{{closure}}::{{closure}}
             at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libproc_macro/bridge/client.rs:305
  12: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:468
  13: std::panicking::begin_panic
  14: rustc_errors::HandlerInner::bug
  15: rustc_errors::Handler::bug
  16: rustc::util::bug::opt_span_bug_fmt::{{closure}}
  17: rustc::ty::context::tls::with_opt::{{closure}}
  18: rustc::ty::context::tls::with_opt
  19: rustc::util::bug::opt_span_bug_fmt
  20: rustc::util::bug::bug_fmt
  21: rustc::hir::def::Res<Id>::def_id::{{closure}}
  22: rustdoc::clean::register_res
  23: <syntax_pos::source_map::Spanned<rustc::hir::VisibilityKind> as rustdoc::clean::Clean<rustdoc::clean::Visibility>>::clean
  24: <rustc::hir::StructField as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
  25: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
  26: <rustdoc::doctree::Struct as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
  27: <rustdoc::doctree::Module as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
  28: rustdoc::clean::krate
  29: rustc::ty::context::tls::enter_global
  30: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  31: rustc_interface::passes::create_global_ctxt::{{closure}}
  32: rustc_interface::passes::BoxedGlobalCtxt::enter
  33: rustc_interface::interface::run_compiler_in_existing_thread_pool
  34: std::panicking::try::do_call
  35: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:81
  36: rustc_driver::catch_fatal_errors
  37: rustdoc::main_options
  38: std::thread::local::LocalKey<T>::with
  39: scoped_tls::ScopedKey<T>::set
  40: syntax::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: aborting due to previous error

error: Could not document `tokio-io`.

@coltfred
Copy link

coltfred commented Dec 3, 2019

This happened on our recent build rust 1.39.0 as well. https://docs.rs/crate/ironoxide/0.14.0/builds

@jonas-schievink jonas-schievink added the E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc label Dec 3, 2019
@jonas-schievink
Copy link
Contributor

cc @rust-lang/rustdoc please triage regressions!

If anyone would like to help out here: This is in need of a minimal example that reproduces the issue, as well as a bisection to pinpoint the PR that introduced this regression.

@ollie27
Copy link
Member

ollie27 commented Dec 4, 2019

Sorry for not getting to this earlier. I've reduced lexical-core down to:

macro_rules! perftools_inline {
    ($($item:tt)*) => (
        $($item)*
    );
}
mod state {
    pub struct RawFloatState;
    impl RawFloatState {
        perftools_inline! {
            pub(super) fn new() {}
        }
    }
}

The Def::Err is coming from the path inside pub(super) which is messed up somehow by the macro.

Bisecting this pointed to be3fb0c which almost certainly means it was caused by #63400 (cc. @petrochenkov).

This is an issue in rustc as well because if you try to use the new method from another crate like this for example:

extern crate stuff;
fn main() {
    stuff::state::RawFloatState::new();
}

rather than the expected error[E0624]: method `new` is private error since be3fb0c it now produces an ICE:

backtrace
error: internal compiler error: src\librustc_mir\monomorphize\collector.rs:804: cannot create local mono-item for DefId(14:8 ~ stuff[8787]::state[0]::{{impl}}[0]::new[0])

thread 'rustc' panicked at 'Box<Any>', src\librustc_errors\lib.rs:892:9
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: <std::io::IoSlice as core::fmt::Debug>::fmt
   3: std::panicking::take_hook
   4: std::panicking::take_hook
   5: rustc_driver::report_ice
   6: std::panicking::rust_panic_with_hook
   7: <rustc_errors::snippet::Style as core::fmt::Debug>::fmt
   8: rustc_errors::HandlerInner::abort_if_errors_and_should_abort
   9: rustc_errors::Handler::bug
  10: rustc::util::bug::bug_fmt
  11: rustc::ty::util::provide
  12: rustc::ty::util::provide
  13: rustc::util::bug::bug_fmt
  14: rustc::util::bug::bug_fmt
  15: <rustc_mir::monomorphize::collector::MirNeighborCollector as rustc::mir::visit::Visitor>::visit_place_base
  16: <rustc_mir::monomorphize::collector::MirNeighborCollector as rustc::mir::visit::Visitor>::visit_place_base
  17: <rustc_mir::monomorphize::collector::MirNeighborCollector as rustc::mir::visit::Visitor>::visit_terminator_kind
  18: rustc_mir::monomorphize::collector::collect_crate_mono_items
  19: <rustc_mir::transform::instcombine::OptimizationFinder as rustc::mir::visit::Visitor>::visit_rvalue
  20: <rustc_mir::const_eval::ConstEvalError as core::fmt::Debug>::fmt
  21: rustc_mir::monomorphize::collector::collect_crate_mono_items
  22: <rustc_mir::const_eval::ConstEvalError as core::fmt::Debug>::fmt
  23: rustc_mir::monomorphize::partitioning::compute_codegen_unit_name
  24: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_utils::codegen_backend::CodegenBackend>::join_codegen_and_link
  25: <rustc_codegen_llvm::builder::Builder as core::ops::drop::Drop>::drop
  26: <rustc_codegen_llvm::debuginfo::metadata::MemberDescription as core::fmt::Debug>::fmt
  27: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_utils::codegen_backend::CodegenBackend>::codegen_crate
  28: rustc_interface::passes::BoxedResolver::to_resolver_outputs
  29: rustc_interface::passes::BoxedResolver::to_resolver_outputs
  30: <rustc_interface::proc_macro_decls::Finder as rustc::hir::itemlikevisit::ItemLikeVisitor>::visit_item
  31: rustc_interface::passes::BoxedResolver::complete
  32: rustc_interface::passes::BoxedResolver::to_resolver_outputs
  33: rustc_interface::passes::BoxedResolver::to_resolver_outputs
  34: <rustc_interface::proc_macro_decls::Finder as rustc::hir::itemlikevisit::ItemLikeVisitor>::visit_item
  35: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::ongoing_codegen
  36: <rustc_driver::Compilation as core::fmt::Debug>::fmt
  37: <syntax_pos::symbol::SymbolStr as core::fmt::Display>::fmt
  38: <rustc::ty::Predicate as rustc::ty::codec::EncodableWithShorthand>::variant
  39: rustc_driver::pretty::print_after_hir_lowering
  40: <rustc::ty::Predicate as rustc::ty::codec::EncodableWithShorthand>::variant
  41: _rust_maybe_catch_panic
  42: rustc_driver::pretty::print_after_hir_lowering
  43: ZN244_$LT$std..error..$LT$impl$u20$core..convert..From$LT$alloc..string..String$GT$$u20$for$u20$alloc..boxed..Box$LT$dyn$u20$std..error..Error$u2b$core..marker..Send$u2b$core..marker..Sync$GT$$GT$..from..StringError$u20$as$u20$core..fmt..Display$GT$3fmt17
  44: std::sys::windows::thread::Thread::new
  45: BaseThreadInitThunk
  46: RtlUserThreadStart
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

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.41.0-nightly (25d8a9494 2019-11-29) running on x86_64-pc-windows-msvc

query stack during panic:
#0 [collect_and_partition_mono_items] collect_and_partition_mono_items
end of query stack
error: aborting due to previous error

Another interesting case comes from removing the inner module:

macro_rules! perftools_inline {
    ($($item:tt)*) => (
        $($item)*
    );
}
pub struct RawFloatState;
impl RawFloatState {
    perftools_inline! {
        pub(super) fn new() {}
    }
}

This didn't compile before be3fb0c but now does somehow.


Also the regressions in tokio-io and ironoxide are a similar but newer regression which I've made a new issue for: #67006.

@ollie27 ollie27 added A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-visibility Area: Visibility / privacy. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example labels Dec 4, 2019
@pnkfelix pnkfelix added P-high High priority and removed I-nominated labels Dec 5, 2019
@GuillaumeGomez
Copy link
Member

I guess I'll take a look since it's been a week. Thanks @ollie27 for the minimal code case!

@GuillaumeGomez GuillaumeGomez self-assigned this Dec 10, 2019
@jonas-schievink
Copy link
Contributor

Was this not fixed by #67106?

@GuillaumeGomez
Copy link
Member

I don't know. If so then we're all good?

@GuillaumeGomez
Copy link
Member

No, I can confirm there's still an ICE.

@oli-obk
Copy link
Contributor

oli-obk commented Dec 10, 2019

Is the nonrustdoc example from #64705 (comment) still ICEing or is it just the rustdoc issue left?

@petrochenkov
Copy link
Contributor

I'll see what happens.

@petrochenkov petrochenkov self-assigned this Dec 10, 2019
@petrochenkov
Copy link
Contributor

petrochenkov commented Dec 10, 2019

Similarly to the case in #67106 this ICE in rustdoc may mean that a bug or error is silently ignored in rustc.
So hiding it like #67207 does is not a good idea.

@petrochenkov
Copy link
Contributor

Fixed in #67236.

@bors bors closed this as completed in 0f286e8 Dec 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-resolve Area: Path resolution A-visibility Area: Visibility / privacy. C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.