-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Moving out of &
in match yields a confusing error message
#8064
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
Comments
Nominating for production-ready status. |
One can't partially move out of a |
In the owned case, the note points to the exact location of where the move happened. It's true that the error messages are slightly different because they're exercising different properties of the language, but it would be great if in the Currently if you have a match with ~20 arms and you make a large refactoring and all of a sudden one of the arms causes a move, it's sometimes difficult to track it down. I think that this issue is specific to just |
Interesting, I tried to always point at the arm when giving an error, but I guess this case slipped by. This shouldn't be so hard to fix. |
Accepted production-ready |
Note that this has the same bad error message if you're moving out of an |
Not a 1.0 blocker, P-low. |
@
in match yields a confusing error message&
in match yields a confusing error message
This commit changes the way move errors are reported when some value is captured by a PatIdent. First, we collect all of the "cannot move out of" errors before reporting them, and those errors with the same "move source" are reported together. If the move is caused by a PatIdent (that binds by value), we add a note indicating where it is and suggest the user to put `ref` if they don't want the value to move. This makes the "cannot move out of" error in match expression nicer (though the extra note may not feel that helpful in other places :P). For example, with the following code snippet, ```rust enum Foo { Foo1(~u32, ~u32), Foo2(~u32), Foo3, } fn main() { let f = &Foo1(~1u32, ~2u32); match *f { Foo1(num1, num2) => (), Foo2(num) => (), Foo3 => () } } ``` Errors before the change: ```rust test.rs:10:9: 10:25 error: cannot move out of dereference of `&`-pointer test.rs:10 Foo1(num1, num2) => (), ^~~~~~~~~~~~~~~~ test.rs:10:9: 10:25 error: cannot move out of dereference of `&`-pointer test.rs:10 Foo1(num1, num2) => (), ^~~~~~~~~~~~~~~~ test.rs:11:9: 11:18 error: cannot move out of dereference of `&`-pointer test.rs:11 Foo2(num) => (), ^~~~~~~~~ ``` After: ```rust test.rs:9:11: 9:13 error: cannot move out of dereference of `&`-pointer test.rs:9 match *f { ^~ test.rs:10:14: 10:18 note: attempting to move value to here (to prevent the move, use `ref num1` or `ref mut num1` to capture value by reference) test.rs:10 Foo1(num1, num2) => (), ^~~~ test.rs:10:20: 10:24 note: and here (use `ref num2` or `ref mut num2`) test.rs:10 Foo1(num1, num2) => (), ^~~~ test.rs:11:14: 11:17 note: and here (use `ref num` or `ref mut num`) test.rs:11 Foo2(num) => (), ^~~ ``` Close #8064
…fate Fix `as_deref_mut` false positives in `needless_option_as_deref` Also moves it into `methods/` Fixes rust-lang#7846 Fixes rust-lang#8047 changelog: [`needless_option_as_deref`]: No longer lints for `as_deref_mut` on Options that cannot be moved supersedes rust-lang#8064
Currently, moving out of a managed box in a match yields an unclear error message that's sometimes difficult to track down:
However when using owned boxes, you get a very nice and clear error message
It'd be awesome to have similar behavior (the extra note) in the managed case as well.
The text was updated successfully, but these errors were encountered: