Internal compiler error while compiling `mio` 0.8.6

[kryvashek]

Code

Actual code unknown, error encountered on

   Compiling mio v0.8.6
error: could not compile `mio`

Meta

rustc 1.67.0 (fc594f156 2023-01-24) running on x86_64-unknown-linux-gnu
compiler flags: --crate-type lib -C opt-level=3 -C embed-bitcode=no -C link-arg=-fuse-ld=lld

Error output

thread 'rustc' panicked at 'index out of bounds: the len is 561152 but the index is 4827502', compiler/rustc_metadata/src/rmeta/decoder.rs:615:19

Backtrace

   0: rust_begin_unwind
             at /rustc/fc594f15669680fa70d255faec3ca3fb507c3405/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/fc594f15669680fa70d255faec3ca3fb507c3405/library/core/src/panicking.rs:64:14
   2: core::panicking::panic_bounds_check
             at /rustc/fc594f15669680fa70d255faec3ca3fb507c3405/library/core/src/panicking.rs:147:5
   3: <rustc_span::symbol::Symbol as rustc_serialize::serialize::Decodable<rustc_metadata::rmeta::decoder::DecodeContext>>::decode
   4: <rustc_metadata::rmeta::CrateRoot as rustc_serialize::serialize::Decodable<rustc_metadata::rmeta::decoder::DecodeContext>>::decode
   5: <rustc_metadata::rmeta::decoder::MetadataBlob>::get_root
   6: <rustc_metadata::locator::CrateLocator>::extract_one
   7: <rustc_metadata::locator::CrateLocator>::extract_lib
   8: <rustc_metadata::locator::CrateLocator>::maybe_load_library_crate
   9: <rustc_metadata::creader::CrateLoader>::load
  10: <rustc_metadata::creader::CrateLoader>::maybe_resolve_crate
  11: <rustc_metadata::creader::CrateLoader>::maybe_process_path_extern
  12: <rustc_resolve::Resolver>::early_resolve_ident_in_lexical_scope
  13: <rustc_resolve::Resolver>::resolve_path_with_ribs
  14: <rustc_resolve::imports::ImportResolver>::resolve_imports
  15: <rustc_resolve::Resolver as rustc_expand::base::ResolverExpand>::resolve_imports
  16: <rustc_expand::expand::MacroExpander>::fully_expand_fragment
  17: <rustc_expand::expand::MacroExpander>::expand_crate
  18: <rustc_session::session::Session>::time::<core::result::Result<rustc_ast::ast::Crate, rustc_errors::ErrorGuaranteed>, rustc_interface::passes::configure_and_expand::{closure#1}>
  19: rustc_interface::passes::configure_and_expand
  20: <rustc_interface::queries::Queries>::expansion
  21: <rustc_interface::interface::Compiler>::enter::<rustc_driver::run_compiler::{closure#1}::{closure#2}, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_errors::ErrorGuaranteed>>
  22: rustc_span::with_source_map::<core::result::Result<(), rustc_errors::ErrorGuaranteed>, rustc_interface::interface::run_compiler<core::result::Result<(), rustc_errors::ErrorGuaranteed>, rustc_driver::run_compiler::{closure#1}>::{closure#0}::{closure#0}>
  23: <scoped_tls::ScopedKey<rustc_span::SessionGlobals>>::set::<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_errors::ErrorGuaranteed>, rustc_driver::run_compiler::{closure#1}>::{closure#0}, core::result::Result<(), rustc_errors::ErrorGuaranteed>>

[clubby789]

This looks like an incremental compilation bug. Does cargo clean then recompiling fix the issue?

@rustbot label +A-incr-comp

[kryvashek]

Does cargo clean then recompiling fix the issue?

Well, I'd say yes. Building was in the Gitlab CI/CD runner with artifacts saved from the previous job. After job restart building finished successfully.

[cjgillot]

This does not look like an incremental bug. Those should not cause ICEs decoding crate metadata.

• either the saved artifacts were corrupted;
• or the version of rustc changed between the two jobs.

Is this any of those 2 cases?

[kryvashek]

• either the saved artifacts were corrupted;
• or the version of rustc changed between the two jobs.

Is this any of those 2 cases?

Unfortunately, I can't say for sure now. But changing compiler version seems impossible since it bad been chosen along with the docker image once on pipeline start.

[kryvashek]

Sorry, I'm answering from the phone and mistakenly hit the wrong button.

[saethlin]

I think the root cause of this issue was rustc incorrectly handling/reporting I/O errors. I've landed a number of PRs to address the problem; the most recent of those is #119510 which is now part of the latest stable toolchain, 1.77. Therefore, even though I have not reproduced exactly what you've reported here, I'm going to close this because I am reasonably confident that this bug is now fixed on stable.

Of course it is possible that I am wrong and the bug you've reported here is not fixed. If you happen to run into problems like this in 1.77 or later please do not hesitate to open a new issue.