Panic in compiler\rustc_mir\src\borrow_check\region_infer\mod.rs:2120:35

[becky112358]

Hi! I tried to compile my code and got a compiler crash.

Code

https://github.com/becky112358/rust_compiler_bug

use serialport;

const BAUD_RATE: u32 = 115200;

use serialport::{SerialPort};

struct Example {
    member0: &'static [u8],
    member1: &'static str,
    member2: fn(&mut Box<dyn SerialPort>),
}

const EXAMPLE_MAP: &[Example] = &[
    Example { member0: "0".as_bytes(), member1: "1", member2: function0 },
    Example { member0: "0".as_bytes(), member1: "1", member2: function1 },
];

fn function0(_unused: &mut Box<dyn SerialPort>) { }

fn function1(_unused: &mut Box<dyn SerialPort>) { }


fn main() {
    let mut port = serialport::new("COM2", BAUD_RATE).open().unwrap();

    for example_member in EXAMPLE_MAP {
        (example_member.member2)(&mut port);
    }
}

Meta

rustc --version --verbose , stable, problem is present:

rustc 1.51.0 (2fd73fabe 2021-03-23)
binary: rustc
commit-hash: 2fd73fabe469357a12c2c974c140f67e7cdd76d0
commit-date: 2021-03-23
host: x86_64-pc-windows-msvc
release: 1.51.0
LLVM version: 11.0.1

rustc --version --verbose , beta, problem still present:

rustc 1.52.0-beta.7 (9a1dfd2dc 2021-04-30)
binary: rustc
commit-hash: 9a1dfd2dc5c42a2ee84b4606aa08cdadf8c0ee87
commit-date: 2021-04-30
host: x86_64-pc-windows-msvc
release: 1.52.0-beta.7
LLVM version: 12.0.0

rustc --version --verbose , nightly, problem still present:

rustc 1.53.0-nightly (42816d61e 2021-04-24)
binary: rustc
commit-hash: 42816d61ead7e46d462df997958ccfd514f8c21c
commit-date: 2021-04-24
host: x86_64-pc-windows-msvc
release: 1.53.0-nightly
LLVM version: 12.0.0

Error output

thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', compiler\rustc_mir\src\borrow_check\region_infer\mod.rs:2136:35
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

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.51.0 (2fd73fabe 2021-03-23) running on x86_64-pc-windows-msvc

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type bin

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

query stack during panic:
#0 [mir_borrowck] borrow-checking `EXAMPLE_MAP`
#1 [analysis] running analysis passes on this crate
end of query stack
error: could not compile `rust_compiler_bug`

To learn more, run the command again with --verbose.

Backtrace

RUST_BACKTRACE=full cargo build

stack backtrace:
   0:     0x7ffb7e83896e - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h0be32b274330c008
   1:     0x7ffb7e8647cb - core::fmt::write::h1aaaeb17cc45ab1e
   2:     0x7ffb7e82be68 - <std::io::IoSliceMut as core::fmt::Debug>::fmt::h4953295bcdf7c8c4
   3:     0x7ffb7e83cb3d - std::panicking::take_hook::h407a4a30481be788
   4:     0x7ffb7e83c609 - std::panicking::take_hook::h407a4a30481be788
   5:     0x7ffb5c33e0b5 - rustc_driver::report_ice::h95f5b27be13b72ff
   6:     0x7ffb7e83d5a2 - std::panicking::rust_panic_with_hook::h0389acbd2be8eae9
   7:     0x7ffb7e83d063 - rust_begin_unwind
   8:     0x7ffb7e8392ff - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h0be32b274330c008
   9:     0x7ffb7e83cfe9 - rust_begin_unwind
  10:     0x7ffb7e860a80 - core::panicking::panic_fmt::hcb326269aca941d7
  11:     0x7ffb7e8609cc - core::panicking::panic::h2e4326175465c4d2
  12:     0x7ffb5f19f365 - rustc_mir::borrow_check::region_infer::RegionInferenceContext::to_region_vid::he915ef710d21c4ab
  13:     0x7ffb5f5ab065 - rustc_mir::borrow_check::provide::hef6a38431e907834
  14:     0x7ffb5f0ec2cb - <rustc_middle::mir::traversal::ReversePostorder as core::iter::traits::iterator::Iterator>::size_hint::hda36076c24cd7432
  15:     0x7ffb5f5a838b - rustc_mir::borrow_check::provide::hef6a38431e907834
  16:     0x7ffb5f56d639 - <rustc_mir::util::spanview::SpanViewable as core::fmt::Debug>::fmt::h634057fcf70b84bf
  17:     0x7ffb5c56205e - rustc_interface::passes::BoxedResolver::complete::hc73eeae317e78de9
  18:     0x7ffb5c4f7fa6 - rustc_interface::util::commit_date_str::h3912c38032a724c5
  19:     0x7ffb5c4c08f0 - rustc_interface::util::commit_date_str::h3912c38032a724c5
  20:     0x7ffb5c524d98 - rustc_interface::interface::parse_cfgspecs::hccf1b6756214f4f0
  21:     0x7ffb5c5874f0 - rustc_interface::queries::Linker::link::hb404463f08312af9
  22:     0x7ffb5c56f46b - rustc_interface::queries::Linker::link::hb404463f08312af9
  23:     0x7ffb5c5831b9 - rustc_interface::queries::Linker::link::hb404463f08312af9
  24:     0x7ffb5c4feef7 - rustc_interface::util::commit_date_str::h3912c38032a724c5
  25:     0x7ffb5c53a15c - rustc_interface::passes::QueryContext::print_stats::hbb0586fa10203714
  26:     0x7ffb5c3457c0 - <rustc_driver::Compilation as core::fmt::Debug>::fmt::hc5ecdaebd526739d
  27:     0x7ffb5c387fc6 - rustc_ast::util::parser::prec_let_scrutinee_needs_par::h214551e4e217a2e9
  28:     0x7ffb5c2f55ad - chalk_engine::TimeStamp::increment::h8ab57932dde938a4
  29:     0x7ffb5c364911 - rustc_ast::util::parser::prec_let_scrutinee_needs_par::h214551e4e217a2e9
  30:     0x7ffb5c2db9bf - <rustc_typeck::coherence::inherent_impls::InherentCollect as rustc_hir::itemlikevisit::ItemLikeVisitor>::visit_trait_item::h1647d16705366107
  31:     0x7ffb5c2d5f7f - <rustc_typeck::coherence::inherent_impls::InherentCollect as rustc_hir::itemlikevisit::ItemLikeVisitor>::visit_trait_item::h1647d16705366107
  32:     0x7ffb5c345e9c - <rustc_driver::Compilation as core::fmt::Debug>::fmt::hc5ecdaebd526739d
  33:     0x7ffb5c361e1e - rustc_ast::util::parser::prec_let_scrutinee_needs_par::h214551e4e217a2e9
  34:     0x7ffb5c341215 - <rustc_driver::Compilation as core::fmt::Debug>::fmt::hc5ecdaebd526739d
  35:     0x7ffb5c3636a9 - rustc_ast::util::parser::prec_let_scrutinee_needs_par::h214551e4e217a2e9
  36:     0x7ffb5c342e05 - <rustc_driver::Compilation as core::fmt::Debug>::fmt::hc5ecdaebd526739d
  37:     0x7ffb5c365515 - rustc_ast::util::parser::prec_let_scrutinee_needs_par::h214551e4e217a2e9
  38:     0x7ffb5c38da9d - <tracing_subscriber::util::TryInitError as core::fmt::Display>::fmt::hb3fcb74fea10bfb2
  39:     0x7ffb7e84cb8a - std::sys::windows::thread::Thread::new::h1849799f24702024
  40:     0x7ffbbe5c7034 - BaseThreadInitThunk
  41:     0x7ffbbf6e2651 - RtlUserThreadStart

[hellow554]

Seems to be a duplicate of #81899 according to the error message itself, but I can't see a const generic expression anywhere. Maybe in the serialport crate. I try to minimize this one.

[hellow554]

MCVE:

trait SerialPort {}

struct Example {
    member0: &'static [u8],
    member2: fn(&Box<dyn SerialPort>),
}
fn function1(_: &Box<dyn SerialPort>) {}

const EXAMPLE_MAP: &[Example] = &[
    Example {
        member0: "0".as_bytes(),
        member2: function1,
    },
    Example {
        member0: "0".as_bytes(),
        member2: function1,
    },
];

fn main() {
    let port = todo!();

    for example_member in EXAMPLE_MAP {
        (example_member.member2)(&port);
    }
}

[hellow554]

It seems to be const related because of as_bytes. If I replace it with b"0" this won't panic anymore and as_bytes is const since 1.32.0

Regression in nightly-2019-11-29 between e87a205...bbb664a stable versions: 1.40.0 and 1.41.0

So, this one is different to the linked issue, therefore let's ping it to the people

@rustbot modify labels: regression-from-stable-to-stable

[hameerabbasi]

@becky112358 Is this blocking an update of the compiler on existing code or is it just experimentation?

[becky112358]

@hameerabbasi This is just something I ran into yesterday while coding. With @hellow554's finding that replacing "x".as_bytes() with b"x", I can continue with my code. :)
Does that answer your question? I don't totally understand it. :(

[apiraino]

Assigning priority as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

@becky112358 thanks for the feedback, don't worry, we simply wanted to clarify if the suggested workaround allows you to move on (which you confirmed) or if the issue was blocking.

@rustbot label -I-prioritize +P-medium

[vamolessa]

I also had this issue happen to me (rustc 1.53.0) and I was able to reproduce it with this:

pub const fn bad_hash(_bytes: &[u8]) -> u64 {
    0
}

struct Thing {
    pub h: u64,
    pub f: for<'a> fn(std::marker::PhantomData<&'a ()>),
}

static THINGS: &[Thing] = &[
    Thing {
        h: bad_hash(b"abc"),
        f: |_| (),
    },
    Thing {
        h: bad_hash(b"abc"),
        f: |_| (),
    },
];

I think it's worth noting that the error goes away if we either:

• we remove the f field from Thing (or just remove the for<'a> from the function signature and replace the PhantomData<&'a ()> with just PhantomData<()>);
• we substitute both calls to bad_hash in second Thing's h field initialization with a literal (e.g. 0 for example);

[JohnTitor]

This is no longer ICE with the latest nightly, I think #88698 is the fix. Marking as E-needs-test.

[cameron1024]

Hi, I've made a PR that adds a test for this, pretty much copy/pastes @hellow554 's MCVE 😄 #89997