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

[Bug][compiler-v2] Difference in compiler v1 and v2 when actively borrowed variable is destroyed #14387

Open
vineethk opened this issue Aug 22, 2024 · 0 comments
Labels
bug Something isn't working compiler-v2 stale-exempt Prevents issues from being automatically marked and closed as stale

Comments

@vineethk
Copy link
Contributor

🐛 Bug

Consider the following code:

module 0x8675309::M {
    struct R has key, copy, drop { f: u64 }

    fun t4(cond: bool, addr: address): bool acquires R {
        let r = R { f: 0 };
        let f = &borrow_global<R>(addr).f;
        let r1; if (cond) r1 = borrow_global<R>(addr) else r1 = &mut r;
        R { f: _ } = r;
        let res = f == &r1.f;
        res
    }
}

Compiler v1 - provides the following error:

Error: error[E07006]: ambiguous usage of variable
-   ┌─ TEMPFILE:8:22
-   │
- 7 │         let r1; if (cond) r1 = borrow_global<R>(addr) else r1 = &mut r;
-   │                                                                 ------ It is still being borrowed by this reference
- 8 │         R { f: _ } = r;
-   │                      ^
-   │                      │
-   │                      Ambiguous usage of variable 'r'
-   │                      Try an explicit annotation, e.g. 'move r' or 'copy r'
-   │
-   = Ambiguous inference of 'move' or 'copy' for a borrowed variable's last usage: A 'move' would invalidate the borrowing reference, but a 'copy' might not be the expected implicit behavior since this the last direct usage of the variable.

But compiler v2 accepts this code (and inserts a copy of the actively borrowed variable, which is then destroyed). Such a silent copy insertion may not be obvious to the user, so we may want to do what compiler v1 does here.

@vineethk vineethk added the bug Something isn't working label Aug 22, 2024
@sausagee sausagee added the stale-exempt Prevents issues from being automatically marked and closed as stale label Sep 5, 2024
@brmataptos brmataptos moved this from 🆕 New to For Grabs in Move Language and Runtime Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working compiler-v2 stale-exempt Prevents issues from being automatically marked and closed as stale
Projects
Status: For Grabs
Development

No branches or pull requests

4 participants