Do we want to create an issue for this ? Not sure if this is tracked somewhere..

Added

Is this the right link? #202

Oops no it should actually be #281.

The problem is when we skip functions in should_skip_current_fn, the thing we're skipping could be a drop that's called elsewhere. #202 is the first function we skip but bridge::client, #281, is where we actually see it

Does this typecheck? We want a pointer to an unimplemented function, and instead we're getting an unimplemented function that returns a fn pointer.

It does type check, we cast to the same type in the if case. I don't think we have any unit tests that hit this, only the standard library regression.

The issue is that this code is called in a constructor, so it will always fail at CBMC time (which is sound, but not helpful). I think what we want is to make a function whose body is unimplemented, and put a pointer to that function into the vtable.

Do we still need the hook here? Or could we just move its logic inside the regular codegen?

Without it, we fail on:

failures:
    [expected] expected/replace-hashmap/main.rs
    [expected] expected/replace-vec/main.rs

Can we assert this above? Would that be a better check than matching on loc_ty.kind()

The conditional doesn't work as a check, because asserting the inverse in the dynamic case fails whenever the instance def is InstanceDef::DropGlue instead of ::Virtual. This structure also matches how the Cranelift backend handles this case.

This would be in the case of dropping a slice?

We've also seen it be a fat pointer to a nested dynamic object.

use the expect_fail macro