Drop for dynamic objects

[avanhatt]

Description of changes:

RMC does not current codegen calls to drop for dynamic objects. This PR does that, inserting vtable calls as necessary.

Resolved issues:

Resolves #66
Should also resolve #435

Call-outs:

• Known issue with the SizeAndAlignOfDst tests. This patch has a workaround to insert a codegen_unimplemented call in the case that drop fails to typecheck, which maintains soundness (the current implementation is not sound because it does not call drop at all).

Testing:

• How is this change tested?

Existing plus 7 new regressions.

• Is this a refactor change?

Not really.

Checklist

• Each commit message has a non-empty body, explaining why the change was made
• Methods or procedures are documented
• Regression or unit tests are included, or existing tests cover the modified code
• My PR is restricted to a single feature or bugfix

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

[chinmaydd]

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

[avanhatt]

Added

[danielsn]

Is this the right link? #202

[avanhatt]

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

[danielsn]

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

[avanhatt]

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.

[danielsn]

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.

[danielsn]

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

[avanhatt]

Without it, we fail on:

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

[danielsn]

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

[avanhatt]

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.

[danielsn]

This would be in the case of dropping a slice?

[avanhatt]

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

[danielsn]

use the expect_fail macro