-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Add detailed error explanation for E0509 #33383
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Aatch (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
Here, we tried to move a field out of a struct of type `DropStruct` which | ||
implements the `Drop` trait. | ||
|
||
`Drop` types have an implicit destructor that gets called when they go out of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This expression is a bit unwieldy. The correct explanation would be that a struct cannot be dropped if one of its field(s) is borrowed.
Also, I don't like the expression "Drop
types". I prefer to use "Types which implement Drop
trait".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I was trying to explain exactly why a struct couldn't be dropped if one of its field(s) is borrowed, but I agree it made the overall explanation harder to understand. I'll push a commit fixing that in a minute.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I think we want "moved", not "borrowed" 👍.
Except for the problem I wrote about, it's very good. Thanks! Ping me once fixed please. |
@@ -429,6 +429,93 @@ You can find more information about borrowing in the rust-book: | |||
http://doc.rust-lang.org/stable/book/references-and-borrowing.html | |||
"##, | |||
|
|||
E0509: r##" | |||
This error occurs when an attempt is made to move out of a container that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this would be clearer as "move out of a value whose type implements the Drop
trait", as "container" is a bit overloaded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"...a value whose type implements..." sounds kind of awkward to me, but I agree it's less ambiguous.
5c1fe56
to
e732fa0
Compare
Please squash your commits. |
Thanks! |
|
||
Here, we tried to move a field out of a struct of type `DropStruct` which | ||
implements the `Drop` trait. However, a struct cannot be dropped if one or | ||
more of its fields have been moved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you explain why this is the case here?
(Moving a field out of a struct invalidates that field, but it might be used during the drop call. Drop
structs should be thought of as a single unit which can't have its fields moved)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually gave an explanation similar to that in an earlier version of this PR. @GuillaumeGomez and I agreed that it was a bit unwieldy, so I replaced it with a simpler explanation. @GuillaumeGomez also had an issue with calling things Drop
types or Drop
structs, and preferred the language "a value whose type implements the Drop
trait." I'll try to reconcile the two-- what do you think of this language:
"Structs implementing the Drop
trait have an implicit destructor that gets called when they go out of scope. This destructor may use the fields of the struct, so moving out of the struct could make it impossible to run the destructor. Therefore, we must think of all values whose type implements the Drop
trait as single units whose fields cannot be moved."
Definitely more complicated, but I think it captures both messages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I propose: "Structs implementing the Drop
trait have an implicit destructor that gets called when they go out of scope. However, the struct cannot be destroyed if one of its field is borrowed because it would make it unavailable and we'd have to face unsafety. Therefore, we must think of all values whose type implements the Drop
trait as single units whose fields cannot be moved."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change made.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's nothing wrong with a field being borrowed, though (the borrow ends befire the drop anyway), the issue is with a field being moved.
I prefer @cramertj's suggested text, though Guillaume's text works with s/borrow/move too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Manishearth Good point. I glossed over that. @GuillaumeGomez Shall I switch back to my original proposal, or would you rather go with a combination of the two (or your proposal with "borrowed" changed to "moved")? Personally, I'm not a huge fan of the "we'd have to face unsafety" language, but I recognize I'm the newcomer here so I'm prepared to give concessions 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@GuillaumeGomez @Manishearth How do you feel about the current language?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"This destructor may use the fields of the struct, so moving out of the struct could make it impossible to run the destructor." -> This part is still incorrect.
EDIT: Maybe more details to help you understand why: That's not the fact that the destructor might use the field which makes the borrowing an issue but the fact that once the structure is destroyed, if you have a reference to one of its fields, this reference becomes invalid and unsafe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What? No, that's not the case, the destructor using it is exactly the reason, no more. Borrowck prevents references escaping.
e10bfdd
to
0cf96d8
Compare
Edited the error explanation for E0509 to clarify dropping of moved fields Edited the error explanation for E0509 to clarify move out of Drop value language Fixed typeo in last commit to E0509 Switched to erroneous code wording
@bors r+ |
📌 Commit 5071728 has been approved by |
@bors rollup |
@Manishearth: You agree with the sentence: "This destructor may use the fields of the struct, so moving out of the struct could make it impossible to run the destructor."? |
Yes. |
Fine then. |
Add detailed error explanation for E0509 Part of rust-lang#32777
Add detailed error explanation for E0509 Part of rust-lang#32777
Add detailed error explanation for E0509 Part of rust-lang#32777
Add detailed error explanation for E0509 Part of rust-lang#32777
Part of #32777