Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

buggy behavior for tuple clone #1312

Closed
tjhance opened this issue Oct 18, 2024 · 1 comment
Closed

buggy behavior for tuple clone #1312

tjhance opened this issue Oct 18, 2024 · 1 comment

Comments

@tjhance
Copy link
Collaborator

tjhance commented Oct 18, 2024

This currently fails verification:

fn stuff(a: (u8, u8)) {
    let b = a.clone();
    assert(a == b); // FAILS
}

This should be supported - but there's also a separate problem. This should fail with an error that tuple2::clone is not supported or some such. For any type other than tuples, we would give such an error. For some reason, Verus isn't doing this check. We should make sure that Verus correctly does this check, including for traits other than Clone.

@tjhance
Copy link
Collaborator Author

tjhance commented Oct 21, 2024

Update: the reason for the current behavior has to do with this code in fn_call_to_vir, which is meant to get the static resolution of a trait call:

        if let Ok(Some(inst)) = inst {
            if let rustc_middle::ty::InstanceDef::Item(did) = inst.def {

For a tuple call, the inst.def is actually an InstanceDef::CloneShim.

InstanceDef actually has quite a lot of variants that are unhandled: https://doc.rust-lang.org/1.76.0/nightly-rustc/rustc_middle/ty/enum.InstanceDef.html

This leads to inconsistent behaviors:

  • If a method is InstanceDef::Item(did) where the did is unsupported, this will get caught later (in well_formed.rs) with an error that the method isn't supported
  • If a method is InstanceDef::some_other_variant (like CloneShim) then it gets silently ignored

Both cases ought to have the same behavior, but I wonder what it should be? It definitely shouldn't be silently ignored, since that's confusing, but perhaps it should be a warning instead of a hard error.

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

No branches or pull requests

1 participant