[BUG] Problem with move symantics after b24ce4d

[Burnett01]

Describe the bug

Prior to commit b24ce4d the following code was valid:

struct Test
{
    a: String;
    b: int;
}

fn main() -> int {
    let x = String::from("Hello"); // heap

    let test: Test = Test{ a: x, b: 1 };  // stack
    x.forget();

    test.a.free();

    return 0;
}

At+after that commit the following error is emitted:

error: Use of moved value 'x'
  --> code.zc:16:5
   |
16 |     x.forget();
   |     ^ here
   |
   = help: This type owns resources and cannot be implicitly copied
   |
   = help: Consider using a reference ('&') to borrow the value instead

To Reproduce

Checkout the commit prior to b24ce4d

1. git checkout 68525fd9fbbef05bd116505312d2d3ef5574960d

2. make clean && make install

3. zc run code.zc

= works

Checkout the commit after 68525fd

1. git checkout b24ce4d7849cec02a9f336f2c1264e0d907bf0c9

or git checkout main

2. make clean && make install

3. zc run code.zc

= error

Expected behavior

It should work (unless I'm mistaken) since forget() is intended to make test.a the owner of x.

Screenshots
n/a

Environment (please complete the following information):

• OS: Ubuntu 22.04.1
• Zen C Version: latest
• Compiler: GCC 13.3.0

Additional context

[Zuhaitz-dev]

I have to check this, but it looks like an edge case in the flow-sensitive semantics.

[davidscholberg]

I'm a little bit confused about the need for forget() in the first place. When test.a is assigned the value of the x variable, shouldn't the compiler count that as a move? Is forget() providing something that the compiler can't achieve?

[davidscholberg]

Actually I just happened to stumble across a use case for forget() that makes sense: https://github.com/z-libs/Zen-C/blob/main/std/string.zc#L25. It's used here to transfer the contents of the vector to the string since the vector variable can't be moved directly (being a different type).

But this has me wondering if the forget() method should be an implicit method that every struct automatically defines, and all it does is signal to the compiler that the variable should no longer be used nor dropped. Or maybe it could even be a unary operator:

let z = x.y;
forget x;