Skip to content

Fix overly permissive borrow checking rules for &mut &mut #10519

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

Merged

Conversation

nikomatsakis
Copy link
Contributor

See #8624 for details.

r? @pnkfelix

@nikomatsakis
Copy link
Contributor Author

ping @pnkfelix (though I see it's bitrotted)

allowed `*x` to be mutated without making the subpaths of `*x`
inaccessible: worse, they became accessible through a new path (I
suppose that we could support swap, too, if needed, by moving the
loans over to the new path).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume the comments made here about the swap operator solely apply to the feature as implemented at the language level, and that the util::swap library function does not fall victim to it? But then again, that library function is implemented by pretty simplistic looking unsafe code. . . does the type system ensure that the type signature of util::swap suffices to enforce the necessary guarantees here?

If the above is true, you may just want to stress further that you are solely commenting on the <-> operator, not the util::swap function.

@pnkfelix
Copy link
Member

�Feel free to push with r=pnkfelix after rebasing + fixing above nits.

…o the first/last item in the slice and modify the slice to exclude the returned item. Useful when writing iterators over mutable references.
return None;
}
let r = if self.remaining2.len() > 0 {
&mut self.remaining1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be self.remaining2?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it, yes. Weird that this didn't seem to fail any tests?

@nikomatsakis
Copy link
Contributor Author

@huonw patched up that problem and improved tests so they would test case where you had a reverse iterator and the data wrapped around.

bors added a commit that referenced this pull request Nov 28, 2013
@bors bors closed this Nov 28, 2013
@bors bors merged commit 09e12fa into rust-lang:master Nov 28, 2013
@nikomatsakis nikomatsakis deleted the issue-8624-borrowck-overly-permissive branch March 30, 2016 16:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants