Skip to content

Remove restrictions from borrowck #14947

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
merged 14 commits into from
Jun 17, 2014
Merged

Remove restrictions from borrowck #14947

merged 14 commits into from
Jun 17, 2014

Conversation

zwarich
Copy link

@zwarich zwarich commented Jun 16, 2014

Now that features like const are gone, we can remove the concept of restrictions from borrowck and just track loans and their restricted paths.

Cameron Zwarich added 14 commits June 16, 2014 15:40
Now that all loans restrict mutation, there's no point in checking for
intersection with RESTR_MUTATE.
Remove the unused &Restriction parameter of each_in_scope_restriction's
op parameter.
Move the `incompatible` helper function from analyze_restrictions_on_use
to the file scope and invert its meaning to account for future uses.
Switch to checking BorrowKind values of loans instead of their
RestrictionSet values. This was the last code that made a decision
based on a RestrictionSet.
The RestrictionSet parameter of the err_borrowed_pointer_too_short
constructor isn't  actually used, so it can be removed.
Now that RestrictionSet is no longer being used for anything meaningful,
it can be removed, along with any other associated functions and
RestrictionSet fields of other types.
The Restriction struct now consists of a single Rc<LoanPath> field, so
it can be replaced with Rc<LoanPath>.
Add a helper function that generalizes the loan path restriction
strategy used by analyze_restrictions_on_use.
It doesn't actually matter if we call mark_variable_as_used_mut when the
assignment was invalid, since the variable was still used mutably.
The only caller of check_for_assignment_to_restricted_or_frozen_location
isn't checking its return value, so we can remove it and simplify the
internal logic of the function.
Currently, check_for_assignment_to_restricted_or_frozen_location bails
out early when looking for loaned base paths when it hits an McDeclared
or McImmutable extension. With the current type system, this is actually
irrelevant, since mutation can only occur given a unique mutable access
path, forcing the same requirement on each base path.
The last remaining use of each_in_scope_restriction in
check_for_assignment_to_restricted_or_frozen_location is using the
pattern captured by each_in_scope_loan_affecting_path, so it can be
removed.
Rename check_for_assignment_to_restricted_or_frozen_location to
check_for_assignment_to_borrowed_path.
@nikomatsakis
Copy link
Contributor

Exciting.

-> bool {
//! Iterates through all the in-scope restrictions for the
//! given `loan_path`
fn each_in_scope_loan_affecting_path(&self,
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder how hard it would be to make these into proper iterators. It'd make the code so much nicer.

bors added a commit that referenced this pull request Jun 17, 2014
…ikomatsakis

Now that features like `const` are gone, we can remove the concept of restrictions from borrowck and just track loans and their restricted paths.
@bors bors closed this Jun 17, 2014
@bors bors merged commit 480cd6f into rust-lang:master Jun 17, 2014
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 5, 2023
Add enum, reference, array and slice to `render_const_scalar`
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.

3 participants