Skip to content
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

Implement stronger guarantees for mutable borrows #14739

Merged
merged 9 commits into from
Jun 14, 2014
Merged

Implement stronger guarantees for mutable borrows #14739

merged 9 commits into from
Jun 14, 2014

Conversation

zwarich
Copy link

@zwarich zwarich commented Jun 8, 2014

Implement the stronger guarantees for mutable borrows proposed in #12624.

@zwarich
Copy link
Author

zwarich commented Jun 8, 2014

r? @nikomatsakis

@pcwalton
Copy link
Contributor

pcwalton commented Jun 9, 2014

🤘

@nikomatsakis
Copy link
Contributor

I would r+, but Travis CI is showing legit looking failures

@nikomatsakis
Copy link
Contributor

Though it's not obvious to me how they are related to this PR

@alexcrichton
Copy link
Member

The travis failure is unrelated to this PR (it'll be fixed by a snapshot)

Cameron Zwarich added 9 commits June 13, 2014 20:48
It will be simpler to make some of the changes that I need to make to
analyze_move_out if it uses a loop rather than recursion.
… &Rc<LoanPath>

It doesn't actually need the Rc, and it reduces the net number of
pointer manipulations.
Currently analyze_move_out_from checks all restrictions on all base
paths of the move path, but it only needs to check restrictions from
loans of the base paths, and can disregard restrictions from loans of
extensions of those base paths.
Currently analyze_move_out_from ignores the BorrowKind of loans, but the
same logic is useful when restricted to loans of specific borrow kinds.
Also rename MoveError to UseError and MoveOk / MoveWhileBorrowed to
UseOk / UseWhileBorrowed.
Fix all violations in the Rust source tree of the stronger guarantee
of a unique access path for mutable borrows as described in #12624.
Implement the stronger guarantees for mutable borrows from #12624. This
removes the ability to read from a mutably borrowed path for the
duration of the borrow, and enforces a unique access path for any
mutable borrow, for both reads and writes.

This makes mutable borrows work better with concurrent accesses from
multiple threads, and it opens the door for allowing moves out of
mutably borrowed values, as long as a new value is written before the
mutable borrow ends. This also aligns Rust more closely with academic
languages based on substructural types and separation logic.

The most common situation triggering an error after this change is a
call to a function mutably borrowing self with self.field as one of the
arguments. The workaround is to bind self.field to a temporary, but the
need for these temporaries will hopefully go away after #6268 is fixed.

Another situation that triggers an error is using the head expression of
a match in an arm that binds a variable with a mutable reference. The
use of the head expression needs to be replaced with an expression that
reconstructs it from match-bound variables.

This fixes #12624.

[breaking-change]
Move analyze_restrictions_on_use and check_if_path_is_moved so that all
of the code related to assignments is in a contiguous block at the end
of the file.
@zwarich
Copy link
Author

zwarich commented Jun 14, 2014

I had to rebase to account for some intervening lexer and parser changes.

@zwarich
Copy link
Author

zwarich commented Jun 14, 2014

@bors: retry

bors added a commit that referenced this pull request Jun 14, 2014
Implement the stronger guarantees for mutable borrows proposed in #12624.
@bors bors closed this Jun 14, 2014
@bors bors merged commit 6fc7889 into rust-lang:master Jun 14, 2014
pnkfelix referenced this pull request Jun 18, 2014
thereof.)

PR 14739 injected the new message that this removes from one test
case: borrowck-vec-pattern-loan-from-mut.rs

When reviewing the test case, I was not able to convince myself that
the error message was a legitimate thing to start emitting.  Niko did
not see an obvious reason for it either, so I am going to remove it
and wait for someone (maybe Cameron Zwarich) to explain to me why we
should be emitting it.
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 5, 2023
…r=Veykril

Parse bare dyn types with leading lifetime

TIL types may start with a lifetime identifier e.g. `type A = 'static + Trait;`. When parsing types, leading lifetime followed by a plus sign should be parsed as a bare dyn type rather than a generic lifetime argument or error type (which is what we produce today).

Although it's no longer accepted since Rust 2021, it wouldn't hurt to support this obsolete syntax.
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.

5 participants