-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 orDrop
structs, and preferred the language "a value whose type implements theDrop
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 theDrop
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 theDrop
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.