Output filename collisions and ICE with 'cargo doc' on 1.38.0 #65367

ebkalderon · 2019-10-13T10:27:55Z

Summary

I was attempting to run cargo doc --open at the top level of a Cargo workspace, which resulted in several warnings regarding output filename collisions for lexical-core, proc_macro2, quote, syn, and unicode-xid (rust-lang/cargo#6313).

Later on, there is an internal compiler error caused by lexical-core 0.4.6:

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

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:644:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

This issue only occurs in cargo doc, as far as I can tell. Running cargo build, cargo run, and cargo bench all behave as expected.

Toolchain information

rustc 1.38.0 (625451e37 2019-09-23)
rustdoc 1.38.0 (625451e37 2019-09-23)
x86_64-unknown-linux-gnu
Arch Linux (5.3.5-arch1-1-ARCH)

How to reproduce

Clone this repository and enter the root directory.
cargo doc --open

Debug output

Output filename collision warning messages

warning: output filename collision.
The lib target `lexical-core` in package `lexical-core v0.6.2` has the same output filename as the lib target `lexical-core` in package `lexical-core v0.4.6`.
Colliding filename is: /home/ekalderon/Documents/nix-language-server/target/doc/lexical_core/index.html
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The lib target `proc_macro2` in package `proc-macro2 v1.0.5` has the same output filename as the lib target `proc-macro2` in package `proc-macro2 v0.4.30`.
Colliding filename is: /home/ekalderon/Documents/nix-language-server/target/doc/proc_macro2/index.html
The output filenames should be unique.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
If this looks unexpected, it may be a bug in Cargo. Please file a bug report at
https://github.com/rust-lang/cargo/issues/ with as much information as you
can provide.
cargo 1.38.0 (23ef9a4ef 2019-08-20) running on `x86_64-unknown-linux-gnu` target `x86_64-unknown-linux-gnu`
First unit: Unit { pkg: Package { id: PackageId { name: "proc-macro2", version: "1.0.5", source: "registry `https://github.com/rust-lang/crates.io-index`" }, ..: ".." }, target: Target { ..: lib_target("proc_macro2", ["lib"], "/home/ekalderon/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-1.0.5/src/lib.rs", Edition2018) }, profile: Profile { incremental: false, ..: default_doc() }, kind: Host, mode: Doc { deps: true } }
Second unit: Unit { pkg: Package { id: PackageId { name: "proc-macro2", version: "0.4.30", source: "registry `https://github.com/rust-lang/crates.io-index`" }, ..: ".." }, target: Target { ..: lib_target("proc-macro2", ["lib"], "/home/ekalderon/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.30/src/lib.rs", Edition2015) }, profile: Profile { incremental: false, ..: default_doc() }, kind: Host, mode: Doc { deps: true } }
warning: output filename collision.
The lib target `quote` in package `quote v1.0.2` has the same output filename as the lib target `quote` in package `quote v0.6.13`.
Colliding filename is: /home/ekalderon/Documents/nix-language-server/target/doc/quote/index.html
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The lib target `syn` in package `syn v1.0.5` has the same output filename as the lib target `syn` in package `syn v0.15.44`.
Colliding filename is: /home/ekalderon/Documents/nix-language-server/target/doc/syn/index.html
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The lib target `unicode-xid` in package `unicode-xid v0.2.0` has the same output filename as the lib target `unicode-xid` in package `unicode-xid v0.1.0`.
Colliding filename is: /home/ekalderon/Documents/nix-language-server/target/doc/unicode_xid/index.html
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.

Full backtrace output for ICE

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

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:644:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:47
   3: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:36
   4: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:200
   5: std::panicking::default_hook
             at src/libstd/panicking.rs:214
   6: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:477
   7: std::panicking::begin_panic
   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: <rustc::hir::Crate as rustdoc::clean::Clean<rustdoc::clean::Crate>>::clean
  27: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  28: rustc_interface::passes::create_global_ctxt::{{closure}}
  29: rustc_interface::interface::run_compiler_in_existing_thread_pool
  30: rustdoc::core::run_core
  31: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  32: std::panicking::try::do_call
  33: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  34: rustc_driver::report_ices_to_stderr_if_any
  35: rustdoc::main_options
  36: std::thread::local::LocalKey<T>::with
  37: scoped_tls::ScopedKey<T>::set
  38: syntax::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
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.38.0 (625451e37 2019-09-23) running on x86_64-unknown-linux-gnu

error: Could not document `lexical-core`.

The text was updated successfully, but these errors were encountered:

ebkalderon · 2019-10-13T10:37:02Z

After further investigation, it seems unlikely that this ICE has anything to do with Cargo workspaces. This bug appears to be isolated to the nix-parser crate.

Removing the nix-parser crate from the workspace members, entering the nix-parser subdirectory, and running cargo doc --open still results in the same ICE:

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

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:644:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:47
   3: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:36
   4: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:200
   5: std::panicking::default_hook
             at src/libstd/panicking.rs:214
   6: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:477
   7: std::panicking::begin_panic
   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: <rustc::hir::Crate as rustdoc::clean::Clean<rustdoc::clean::Crate>>::clean
  27: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  28: rustc_interface::passes::create_global_ctxt::{{closure}}
  29: rustc_interface::interface::run_compiler_in_existing_thread_pool
  30: rustdoc::core::run_core
  31: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  32: std::panicking::try::do_call
  33: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  34: rustc_driver::report_ices_to_stderr_if_any
  35: rustdoc::main_options
  36: std::thread::local::LocalKey<T>::with
  37: scoped_tls::ScopedKey<T>::set
  38: syntax::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: aborting due to previous error

One thing to note here is that nix-parser depends directly on lexical-core 0.6.2 and nom 5.0.1, which transitively depends on lexical-core 0.4.6. I wonder if the output filename collision occurring in lexical-core is causing the problem here?

ebkalderon · 2019-10-13T10:50:25Z

Also, I should mention that running cargo build, cargo run, or cargo bench at either the repo root or in the nix-parser subdirectory do not result in "output filename collision" warnings. The bug causing this ICE appears to be localized to rustdoc and/or cargo doc.

jonas-schievink · 2019-10-13T11:09:18Z

Does it also happen on nightly? Is there an older stable version for which this doesn't happen?

ebkalderon · 2019-10-13T11:13:17Z

@jonas-schievink I'm checking the latest nightly right now, and I will report back back with my findings. I haven't tried this project with any older stable versions, but I'll try to roll back to 1.37.0 and see what happens.

jonas-schievink · 2019-10-13T11:23:21Z

Ah, it uses lexical-core, so this is a duplicate of #64705. Closing in favor of that, but thanks for filing anyways!

ebkalderon · 2019-10-13T11:27:51Z

@jonas-schievink Awesome, good to know I'm not the only one affected! With that said, the ICE still occurs on the latest 1.40.0-nightly but doesn't occur on 1.37.0. Running cargo doc --open at the workspace root, I get the following results:

Nightly toolchain information

rustc 1.40.0-nightly (1721c9685 2019-10-12)
rustdoc 1.40.0-nightly (1721c9685 2019-10-12)

Output file collision warning messages

warning: output filename collision.
The lib target `lexical-core` in package `lexical-core v0.6.2` has the same output filen
Colliding filename is: /home/ekalderon/Documents/nix-language-server/target/doc/lexical_
The targets should have unique names.
This is a known bug where multiple crates with the same name use
the same path; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The lib target `proc_macro2` in package `proc-macro2 v1.0.5` has the same output filenam
Colliding filename is: /home/ekalderon/Documents/nix-language-server/target/doc/proc_mac
The output filenames should be unique.
This is a known bug where multiple crates with the same name use
the same path; see <https://github.com/rust-lang/cargo/issues/6313>.
If this looks unexpected, it may be a bug in Cargo. Please file a bug report at
https://github.com/rust-lang/cargo/issues/ with as much information as you
can provide.
cargo 1.40.0-nightly (a429e8cc4 2019-10-04) running on `x86_64-unknown-linux-gnu` target
First unit: Unit { pkg: Package { id: PackageId { name: "proc-macro2", version: "1.0.5", Target { ..: lib_target("proc_macro2", ["lib"], "/home/ekalderon/.cargo/registry/src/gi { name: "doc", debuginfo: Some(2), debug_assertions: true, overflow_checks: true, ..: d
Second unit: Unit { pkg: Package { id: PackageId { name: "proc-macro2", version: "0.4.30t: Target { ..: lib_target("proc-macro2", ["lib"], "/home/ekalderon/.cargo/registry/src/ile { name: "doc", debuginfo: Some(2), debug_assertions: true, overflow_checks: true, ..}
warning: output filename collision.
The lib target `quote` in package `quote v1.0.2` has the same output filename as the lib
Colliding filename is: /home/ekalderon/Documents/nix-language-server/target/doc/quote/in
The targets should have unique names.
This is a known bug where multiple crates with the same name use
the same path; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The lib target `syn` in package `syn v1.0.5` has the same output filename as the lib tar
Colliding filename is: /home/ekalderon/Documents/nix-language-server/target/doc/syn/inde
The targets should have unique names.
This is a known bug where multiple crates with the same name use
the same path; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The lib target `unicode-xid` in package `unicode-xid v0.2.0` has the same output filenam
Colliding filename is: /home/ekalderon/Documents/nix-language-server/target/doc/unicode_
The targets should have unique names.
This is a known bug where multiple crates with the same name use
the same path; see <https://github.com/rust-lang/cargo/issues/6313>.

Full backtrace output for ICE

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:917: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:77
   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:1028
   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:189
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:206
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:469
  11: std::panicking::begin_panic
  12: rustc_errors::HandlerInner::bug
  13: rustc_errors::Handler::bug
  14: rustc::util::bug::opt_span_bug_fmt::{{closure}}
  15: rustc::ty::context::tls::with_opt::{{closure}}
  16: rustc::ty::context::tls::with_context_opt
  17: rustc::ty::context::tls::with_opt
  18: rustc::util::bug::opt_span_bug_fmt
  19: rustc::util::bug::bug_fmt
  20: rustc::hir::def::Res<Id>::def_id::{{closure}}
  21: rustdoc::clean::register_res
  22: <syntax::source_map::Spanned<rustc::hir::VisibilityKind> as rustdoc::clean::Clean<rustdoc::clean::Visibility>>::clean
  23: <rustc::hir::ImplItem as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
  24: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
  25: <rustdoc::doctree::Impl as rustdoc::clean::Clean<alloc::vec::Vec<rustdoc::clean::Item>>>::clean
  26: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::spec_extend
  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::doctree::Module as rustdoc::clean::Clean<rustdoc::clean::Item>>::clean
  31: rustdoc::clean::krate
  32: rustc::ty::context::tls::enter_global
  33: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  34: rustc_interface::passes::create_global_ctxt::{{closure}}
  35: rustc_interface::passes::BoxedGlobalCtxt::enter
  36: rustc_interface::interface::run_compiler_in_existing_thread_pool
  37: rustdoc::core::run_core
  38: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  39: std::panicking::try::do_call
  40: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  41: rustc_driver::catch_fatal_errors
  42: rustdoc::main_options
  43: std::thread::local::LocalKey<T>::with
  44: scoped_tls::ScopedKey<T>::set
  45: 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 `lexical-core`.

1.37 toolchain information

rustc 1.37.0 (eae3437df 2019-08-13)
rustdoc 1.37.0 (eae3437df 2019-08-13)

Output file collision warning messages

``` warning: output filename collision. The lib target `lexical-core` in package `lexical-core v0.6.2` has the same output filename as the lib target `lexical-core` in package `lexical-core v0.4.6`. Colliding filename is: /home/ekalderon/Documents/nix-language-server/target/doc/lexical_core/index.html The targets should have unique names. Consider changing their names to be unique or compiling them separately. This may become a hard error in the future; see . warning: output filename collision. The lib target `proc_macro2` in package `proc-macro2 v1.0.5` has the same output filename as the lib target `proc-macro2` in package `proc-macro2 v0.4.30`. Colliding filename is: /home/ekalderon/Documents/nix-language-server/target/doc/proc_macro2/index.html The output filenames should be unique. Consider changing their names to be unique or compiling them separately. This may become a hard error in the future; see . If this looks unexpected, it may be a bug in Cargo. Please file a bug report at https://github.com/rust-lang/cargo/issues/ with as much information as you can provide. cargo 1.37.0 (9edd08916 2019-08-02) running on `x86_64-unknown-linux-gnu` target `x86_64-unknown-linux-gnu` First unit: Unit { pkg: Package { id: PackageId { name: "proc-macro2", version: "1.0.5", source: "registry `https://github.com/rust-lang/crates.io-index`" }, ..: ".." }, target: Target { ..: lib_target("proc_macro2", ["lib"], "/home/ekalderon/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-1.0.5/src/lib.rs", Edition2018) }, profile: Profile { incremental: false, ..: default_doc() }, kind: Host, mode: Doc { deps: true } } Second unit: Unit { pkg: Package { id: PackageId { name: "proc-macro2", version: "0.4.30", source: "registry `https://github.com/rust-lang/crates.io-index`" }, ..: ".." }, target: Target { ..: lib_target("proc-macro2", ["lib"], "/home/ekalderon/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.30/src/lib.rs", Edition2015) }, profile: Profile { incremental: false, ..: default_doc() }, kind: Host, mode: Doc { deps: true } } warning: output filename collision. The lib target `quote` in package `quote v1.0.2` has the same output filename as the lib target `quote` in package `quote v0.6.13`. Colliding filename is: /home/ekalderon/Documents/nix-language-server/target/doc/quote/index.html The targets should have unique names. Consider changing their names to be unique or compiling them separately. This may become a hard error in the future; see . warning: output filename collision. The lib target `syn` in package `syn v1.0.5` has the same output filename as the lib target `syn` in package `syn v0.15.44`. Colliding filename is: /home/ekalderon/Documents/nix-language-server/target/doc/syn/index.html The targets should have unique names. Consider changing their names to be unique or compiling them separately. This may become a hard error in the future; see . warning: output filename collision. The lib target `unicode-xid` in package `unicode-xid v0.2.0` has the same output filename as the lib target `unicode-xid` in package `unicode-xid v0.1.0`. Colliding filename is: /home/ekalderon/Documents/nix-language-server/target/doc/unicode_xid/index.html The targets should have unique names. Consider changing their names to be unique or compiling them separately. This may become a hard error in the future; see . ```

While I still get the warnings, I can successfully document the crate containing lexical-core. I might post this to the other issue, if it helps.

ebkalderon mentioned this issue Oct 13, 2019

Documenting nix-parser produces ICE on 1.38.0 ebkalderon/nix-language-server#9

Open

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 Oct 13, 2019

jonas-schievink closed this as completed Oct 13, 2019

ebkalderon mentioned this issue Oct 13, 2019

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

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Output filename collisions and ICE with 'cargo doc' on 1.38.0 #65367

Output filename collisions and ICE with 'cargo doc' on 1.38.0 #65367

ebkalderon commented Oct 13, 2019 •

edited

Loading

ebkalderon commented Oct 13, 2019

Uh oh!

ebkalderon commented Oct 13, 2019

Uh oh!

jonas-schievink commented Oct 13, 2019

Uh oh!

ebkalderon commented Oct 13, 2019

Uh oh!

jonas-schievink commented Oct 13, 2019

Uh oh!

ebkalderon commented Oct 13, 2019 •

edited

Loading

Uh oh!

Output filename collisions and ICE with 'cargo doc' on 1.38.0 #65367

Output filename collisions and ICE with 'cargo doc' on 1.38.0 #65367

Comments

ebkalderon commented Oct 13, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Toolchain information

How to reproduce

Debug output

ebkalderon commented Oct 13, 2019

Uh oh!

ebkalderon commented Oct 13, 2019

Uh oh!

jonas-schievink commented Oct 13, 2019

Uh oh!

ebkalderon commented Oct 13, 2019

Uh oh!

jonas-schievink commented Oct 13, 2019

Uh oh!

ebkalderon commented Oct 13, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Nightly toolchain information

1.37 toolchain information

Uh oh!

ebkalderon commented Oct 13, 2019 •

edited

Loading

ebkalderon commented Oct 13, 2019 •

edited

Loading