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

[ebkalderon]

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

1. Clone this repository and enter the root directory.
2. 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`.

[ebkalderon]

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]

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]

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

[ebkalderon]

@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]

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

[ebkalderon]

@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.