-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Accessing a field in a closure makes rust want to copy ... something #2833
Comments
Oh, in the example where I don't assign to x.x, I instead let z = @x after the closure is created, to trigger the same error. |
This is not a bug. An |
Aha, mystery solved. I will think about what it would take to perhaps make this more intuitive. In the case where I don't reference x after I close over it, and there's no error: is it detecting that x is dead, and moving it into the closure? Or what's happening there? |
we discussed this on IRC, but for posterity's sake: if the variable is not used after the closure is constructed, it is considered a "last use" and is moved into the closure |
Update to new ui_test crate
Adds a set of scripts to automate building and installing most dependencies in Amazon Linux 2 environments. This will make it easier to provide ARM64 binaries for Linux (see rust-lang#2805). The installation of dependencies isn't minimal but improves our situation w.r.t. AL2. Testing done manually on remote AL2 ARM64 instances, after running this I'm able to run the regression successfully. ### Callouts * Hasn't been tested on AL2 x86.
Notably, it seems to be trying to copy the example object, not the int (as I first assumed), at least if you trust the error location marker.
So the question is, why does accessing a field of the object try to copy it?
This particular repro goes away if you remove the write to x.x after the closure is created, but I have another, larger one where the write isn't there and it still does it.
The text was updated successfully, but these errors were encountered: