Skip to content

Miri tests fail with debug assertions enabled #99605

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
RalfJung opened this issue Jul 22, 2022 · 4 comments · Fixed by #99607
Closed

Miri tests fail with debug assertions enabled #99605

RalfJung opened this issue Jul 22, 2022 · 4 comments · Fixed by #99607

Comments

@RalfJung
Copy link
Member

I thought I had tested the debug assertions that I added in #99420, but it seems I hadn't tested them on enough code, because they do actually fail, for example:

thread 'rustc' panicked at 'assertion failed: `(left == right)`
  left: `Instance { def: VTableShim(DefId(2:3509 ~ core[3dde]::ops::function::FnOnce::call_once)), substs: [[closure@std::thread::Builder::spawn_unchecked_<[closure@tests/pass/weak_memory/weak.rs:38:20: 38:27], ()>::{closure#1}], ()] }`,
 right: `Instance { def: Item(WithOptConstParam { did: DefId(1:985 ~ std[636e]::thread::{impl#0}::spawn_unchecked_::{closure#1}), const_param_did: None }), substs: [ReErased, ReErased, [closure@tests/pass/weak_memory/weak.rs:38:20: 38:27], (), i32, extern "rust-call" fn(()), (std::thread::Thread, std::option::Option<std::sync::Arc<std::sync::Mutex<std::vec::Vec<u8>>>>, [closure@tests/pass/weak_memory/weak.rs:38:20: 38:27], std::sync::Arc<std::thread::Packet<()>>)] }`', /home/r/src/rust/rustc/compiler/rustc_const_eval/src/interpret/terminator.rs:600:21

That's this assertion:

assert_eq!(fn_inst, concrete_method);

failing on this code:

note: the place in the program where the ICE was triggered
  --> /home/r/src/rust/rustc/library/alloc/src/boxed.rs:1935:9
   |
LL |         <F as FnOnce<Args>>::call_once(*self, args)
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

@eddyb looks like the check you proposed does not always hold?

@eddyb
Copy link
Member

eddyb commented Jul 22, 2022

Oh yeah my bad I forgot to double-check that Instance::resolve_for_vtable is used, not Instance::resolve.

(which can return VtableShim instead of the resolve result, but it looks like it has some other conditions/outcomes too so it's better to call resolve_for_vtable directly)

EDIT: you should also test with some #[track_caller] situations to trigger ReifyShim as well, not just VtableShim.

@RalfJung
Copy link
Member Author

you should also test with some #[track_caller] situations to trigger ReifyShim as well, not just VtableShim.

What would those situations look like?

@eddyb
Copy link
Member

eddyb commented Jul 22, 2022

Looks like #[track_caller] in the impl but not in the trait (see on godbolt):

pub trait Foo {
    fn foo(&self);
}

struct Bar;
impl Foo for Bar {
    #[track_caller]
    fn foo(&self) {}
}

&Bar as &dyn Foo ends up with this vtable entry:

<example::Bar as example::Foo>::foo::{shim:reify#0}

which is the ReifyShim, and it calls:

<example::Bar as example::Foo>::foo

@RalfJung
Copy link
Member Author

You are right, that used to ICE mentioning a ReifyShim. resolve_for_vtable fixes both cases. :)

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants