Confusing error message when trying to implement a shared mutable state

[lovasoa]

Let's say I am a rust beginner coming from another language, and I want to write a simple multi-threaded program in rust.

So I write this simple function :

fn simple() -> u8 {
    let mut x = 0;
    std::thread::spawn(|| {
        x += 1;
    });
    x += 1;
    x
}

One of the selling points of rust is being able to prevent data races, so it should be able to explain in details what is wrong with this function. However, it gives a confusing error message.

It does not compile, and the compiler returns :

closure may outlive the current function, but it borrows x, which is owned by the current function
help: to force the closure to take ownership of x (and any other referenced variables), use the move keyword

And if I look up the detailed error message in the error book (here: https://doc.rust-lang.org/error-index.html#E0373), it also tells me to add a move in front of the closure.

I think this is confusing. Obviously, the right thing to do here is to use a mutex, but this is not mentioned neither in the error message, nor in the error book.

Maybe the error should also say something like

If you need to use x both in the current function and in the closure, than you may have to use a form of shared state concurrency

It would be even nicer if the compiler could detect that we are using x after the litigious function, and thus not talk about move at all.

[lovasoa]

Maybe it is hard for the compiler at that point to know that we want to mutate x from two different threads, but it could at least say something about what to do and where to look if we cannot use move.

[cramertj]

Just adding Mutex isn't sufficient. As the compiler pointed out, the spawned thread may outlive the scope of simple, after which point referring to x at all would be undefined behavior (because the stack space for x in simple would have gone away). move is sufficient to solve this problem because it causes a copy of x to be sent to the other thread, rather than referencing the current thread. If you're looking for a way to spawn threads that can refer to local stack variables, look into crossbeam::scope or rayon::scope.

[lovasoa]

I did not know about crossbeam::scope and rayon::scope. Thank you for the information.

I'm sorry if my example wasn't clear enough. In my example, x is an u8 so it will be copied if we use move. However, in the general case x will not be copied, and using move will trigger a new error.
I really think the diagnostic in this error is lacking some important information and might mislead the developer.

[lovasoa]

(of course the mutex would have to be wrapped in an Arc, but this is not what this issue is about)