-
-
Notifications
You must be signed in to change notification settings - Fork 14.3k
Miscellaneous cleanups to borrowck related code #150550
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -229,8 +229,9 @@ impl<'tcx> UniversalRegionRelationsBuilder<'_, 'tcx> { | |
| // not ready to process them yet. | ||
| // - Then compute the implied bounds. This will adjust | ||
| // the `region_bound_pairs` and so forth. | ||
| // - After this is done, we'll process the constraints, once | ||
| // the `relations` is built. | ||
| // - After this is done, we'll register the constraints in | ||
| // the `BorrowckInferCtxt`. Checking these constraints is | ||
| // handled later by actual borrow checking. | ||
| let mut normalized_inputs_and_output = | ||
| Vec::with_capacity(self.universal_regions.unnormalized_input_tys.len() + 1); | ||
| for ty in unnormalized_input_output_tys { | ||
|
|
@@ -254,6 +255,15 @@ impl<'tcx> UniversalRegionRelationsBuilder<'_, 'tcx> { | |
| constraints.push(c) | ||
| } | ||
|
|
||
| // Currently `implied_outlives_bounds` will normalize the provided | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure how useful a lot of my comments here actually are given afaik @tiif is rewriting the logic for computing implies bounds so this code might just all get yoten soon:tm:
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i think the core logic here won't change too much, so it will still be very useful :3 |
||
| // `Ty`, despite this it's still important to normalize the ty ourselves | ||
| // as normalization may introduce new region variables (#136547). | ||
| // | ||
| // If we do not add implied bounds for the type involving these new | ||
| // region variables then we'll wind up with the normalized form of | ||
| // the signature having not-wf types due to unsatisfied region | ||
| // constraints. | ||
| // | ||
| // Note: we need this in examples like | ||
| // ``` | ||
| // trait Foo { | ||
|
|
@@ -262,7 +272,7 @@ impl<'tcx> UniversalRegionRelationsBuilder<'_, 'tcx> { | |
| // } | ||
| // impl Foo for () { | ||
| // type Bar = (); | ||
| // fn foo(&self) ->&() {} | ||
| // fn foo(&self) -> &() {} | ||
| // } | ||
| // ``` | ||
| // Both &Self::Bar and &() are WF | ||
|
|
@@ -277,6 +287,15 @@ impl<'tcx> UniversalRegionRelationsBuilder<'_, 'tcx> { | |
| } | ||
|
|
||
| // Add implied bounds from impl header. | ||
| // | ||
| // We don't use `assumed_wf_types` to source the entire set of implied bounds for | ||
| // a few reasons: | ||
| // - `DefiningTy` for closure has the `&'env Self` type while `assumed_wf_types` doesn't | ||
| // - We compute implied bounds from the unnormalized types in the `DefiningTy` but do not | ||
| // do so for types in impl headers | ||
| // - We must compute the normalized signature and then compute implied bounds from that | ||
| // in order to connect any unconstrained region vars created during normalization to | ||
| // the types of the locals corresponding to the inputs and outputs of the item. (#136547) | ||
| if matches!(tcx.def_kind(defining_ty_def_id), DefKind::AssocFn | DefKind::AssocConst) { | ||
| for &(ty, _) in tcx.assumed_wf_types(tcx.local_parent(defining_ty_def_id)) { | ||
| let result: Result<_, ErrorGuaranteed> = param_env | ||
|
|
@@ -352,10 +371,7 @@ impl<'tcx> UniversalRegionRelationsBuilder<'_, 'tcx> { | |
| known_type_outlives_obligations.push(outlives); | ||
| } | ||
|
|
||
| /// Update the type of a single local, which should represent | ||
| /// either the return type of the MIR or one of its arguments. At | ||
| /// the same time, compute and add any implied bounds that come | ||
| /// from this local. | ||
| /// Compute and add any implied bounds that come from a given type. | ||
| #[instrument(level = "debug", skip(self))] | ||
| fn add_implied_bounds( | ||
| &mut self, | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -836,7 +836,7 @@ impl BorrowKind { | |
|
|
||
| /// Returns whether borrows represented by this kind are allowed to be split into separate | ||
| /// Reservation and Activation phases. | ||
| pub fn allows_two_phase_borrow(&self) -> bool { | ||
| pub fn is_two_phase_borrow(&self) -> bool { | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. in some sense its always a two phase borrow, just sometimes its activated at the same point its created I think? The previous name confused me because it made it sound like a reference may or may not be a two phase borrow and then we went on to unconditionally treat it as two phase without ever checking if it "actually is". |
||
| match *self { | ||
| BorrowKind::Shared | ||
| | BorrowKind::Fake(_) | ||
|
|
||
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 felt very confusing to read to me. we first insert the borrow with the wrong activation location (we assume its not two phase). and then
insert_as_pending_if_two_phasedoes more than it says and actually fixes up the activation location to what it should have been from the startI inlined this function as it only had one call site and deferred inserting into the location map until we actually choose a
TwoPhaseActivationto use.