ICE related to non_exhaustive_omitted_patterns lint

[chanks]

Just tried to update my toolchain from nightly-2021-09-04 to nightly-2021-09-29, and I now get an ICE in a project of mine when I run cargo check.

Code

I don't have a self-contained reproduction (though I can try to put one together if necessary). I see that the error is originating from the non_exhaustive_omitted_patterns lint introduced in 33a06b7 (cc @DevinR528), and the only pattern destructuring happening in the convert_bulk_write_failure function mentioned in the error is:

let mongodb::error::BulkWriteFailure {
	write_concern_error,
	write_errors,
	..
} = error;

In the version of the mongodb crate I am using (2.0.0-beta.3), this struct is defined as:

pub struct BulkWriteFailure {
    /// The error(s) that occurred on account of a non write concern failure.
    pub write_errors: Option<Vec<BulkWriteError>>,

    /// The error that occurred on account of write concern failure.
    pub write_concern_error: Option<WriteConcernError>,

    #[serde(skip)]
    pub(crate) inserted_ids: HashMap<usize, Bson>,
}

This makes me wonder if the compiler is getting confused by the pub(crate) visibility of the last field?

Meta

rustc --version --verbose:

rustc --version --verbose
rustc 1.57.0-nightly (8f8092cc3 2021-09-28)
binary: rustc
commit-hash: 8f8092cc32ec171becef8ceacec7dbb06c5d7d7e
commit-date: 2021-09-28
host: x86_64-unknown-linux-gnu
release: 1.57.0-nightly
LLVM version: 13.0.0

Error output

error: internal compiler error: compiler/rustc_typeck/src/check/pat.rs:1638:23: impossible case reached

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

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

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.57.0-nightly (8f8092cc3 2021-09-28) running on x86_64-unknown-linux-gnu

note: compiler flags: -Z share-generics=y -C embed-bitcode=no -C debuginfo=2 -C linker=/usr/bin/clang -C incremental -C link-arg=-fuse-ld=lld --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [typeck] type-checking `error_conversion::bulk_write_error::convert_bulk_write_failure`
#1 [typeck_item_bodies] type-checking all item bodies
end of query stack

Backtrace

error: internal compiler error: compiler/rustc_typeck/src/check/pat.rs:1638:23: impossible case reached

thread 'rustc' panicked at 'Box<dyn Any>', compiler/rustc_errors/src/lib.rs:1146:9
stack backtrace:
   0: std::panicking::begin_panic
   1: std::panic::panic_any
   2: rustc_errors::HandlerInner::bug
   3: rustc_errors::Handler::bug
   4: rustc_middle::ty::context::tls::with_opt
   5: rustc_middle::util::bug::opt_span_bug_fmt
   6: rustc_middle::util::bug::bug_fmt
   7: rustc_typeck::check::pat::<impl rustc_typeck::check::fn_ctxt::FnCtxt>::non_exhaustive_reachable_pattern::joined_uncovered_patterns
   8: rustc_typeck::check::pat::<impl rustc_typeck::check::fn_ctxt::FnCtxt>::check_struct_pat_fields
   9: rustc_typeck::check::pat::<impl rustc_typeck::check::fn_ctxt::FnCtxt>::check_pat
  10: rustc_typeck::check::fn_ctxt::checks::<impl rustc_typeck::check::fn_ctxt::FnCtxt>::check_decl_local
  11: rustc_typeck::check::fn_ctxt::checks::<impl rustc_typeck::check::fn_ctxt::FnCtxt>::check_stmt
  12: rustc_typeck::check::fn_ctxt::checks::<impl rustc_typeck::check::fn_ctxt::FnCtxt>::check_block_with_expected
  13: rustc_typeck::check::expr::<impl rustc_typeck::check::fn_ctxt::FnCtxt>::check_expr_kind
  14: rustc_typeck::check::expr::<impl rustc_typeck::check::fn_ctxt::FnCtxt>::check_expr_with_expectation
  15: rustc_typeck::check::check::check_fn
  16: rustc_infer::infer::InferCtxtBuilder::enter
  17: rustc_typeck::check::typeck
  18: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task
  19: rustc_data_structures::stack::ensure_sufficient_stack
  20: rustc_query_system::query::plumbing::try_execute_query
  21: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::typeck
  22: rustc_middle::ty::<impl rustc_middle::ty::context::TyCtxt>::par_body_owners
  23: rustc_typeck::check::typeck_item_bodies
  24: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task
  25: rustc_data_structures::stack::ensure_sufficient_stack
  26: rustc_query_system::query::plumbing::try_execute_query
  27: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::typeck_item_bodies
  28: rustc_session::utils::<impl rustc_session::session::Session>::time
  29: rustc_typeck::check_crate
  30: rustc_interface::passes::analysis
  31: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task
  32: rustc_data_structures::stack::ensure_sufficient_stack
  33: rustc_query_system::query::plumbing::try_execute_query
  34: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis
  35: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  36: rustc_span::with_source_map
  37: rustc_interface::interface::create_compiler_and_run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[chanks]

I think I see the problem, that last field is being correctly identified as not-visible, so an empty slice is being passed into non_exhaustive_reachable_pattern, which is immediately failing in joined_uncovered_patterns.

I don't know this lint well enough to know what the solution is. I guess you could replace:

            if non_exhaustive {
                self.non_exhaustive_reachable_pattern(pat, &accessible_unmentioned_fields, adt_ty)
            } else if !etc {

with

            if non_exhaustive {
                if !accessible_unmentioned_fields.is_empty() {
                    self.non_exhaustive_reachable_pattern(pat, &accessible_unmentioned_fields, adt_ty)
                }
            } else if !etc {

I'm not sure if that reflects how the lint is meant to work, though.

[DevinR528]

Yup that would completly make sense 🤦

Thanks for diagnosing and fixing the problem! You are correct that the lint should not be run if there are no fields to report and it runs into the [] => bug!() case in the match expression.