-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
always resolve to universal regions if possible #108121
Conversation
☔ The latest upstream changes (presumably #108020) made this pull request unmergeable. Please resolve the merge conflicts. |
that merge conflict is unfortunate 😅 r=me after perf |
Give a more clear name.
Bless tests and show an introduced unsoundness related to exits<'a> { forall<'b> { 'a == 'b } }. We now resolve the var ?a in U0 to the placeholder !b in U1.
8eee7db
to
bfd3501
Compare
The original change introduced a new unsoundness (see last commits). It is caused by resolving a region variable to a placeholder region from a universe that it can't name. I originally thought this is not a problem because region resolution doesn't rely on Theoretically, it is a preexisting bug because in the previous setup we could resolve a variable to another variable of higher universe, and thus allowing it to name more regions, but I can't think of an example where we unify two region variables from different universes inside a canonical query in order to exploit this. |
@bors try @rust-timer queue I am unhappy with bfd3501 as it feels fairly brittle. Can look into this myself at some point, but how difficult is it to 1. eagerly error when unifying a region with a placeholder from a higher universe and 2. when unifying 2 regions |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit 095b5fa with merge 6296cbeaecfc306187cacaad62bbb14d77d96ded... |
☀️ Try build successful - checks-actions |
1 similar comment
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (6296cbeaecfc306187cacaad62bbb14d77d96ded): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
I don't see a problem with the current approach. Anway, I tried to implement alternative approach in https://github.com/aliemjay/rust/tree/resolve-var-region-alt but I don't really like it especially how the universes of region variables change during inference. |
cc #108867 |
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.
looked a bit more into this and also at #108867
I think I agree with you now that this approach is nicer but thought of a way to make this harder to misuse by accident in the future.
r=me after this nit
_ => region, | ||
let mut ut = self.unification_table_mut(); // FIXME(rust-lang/ena#42): unnecessary mut | ||
let root_vid = ut.find(vid).vid; | ||
let resolved = ut.probe_value(root_vid).0.unwrap_or_else(|| tcx.mk_re_var(root_vid)); |
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 is the only use of probe_value
for regions 🤔 so yeah I agree that this is fine.
Can you add a comment to UnifiedRegion
that the assigned value may not be nameable by the region var?
Or even better, change unified region to
pub(super?) struct UnifiedRegion {
resolved: Option<Region<'tcx>>,
}
impl UnifiedRegion {
/// Something something the resolved region may not be nameable by
/// this region variable.
pub fn get_resolved_region_ignoring_universes(self) -> Option<Region<'tcx>> {
self.resolved
}
}
182ae54
to
228f408
Compare
@bors r+ rollup=never |
@lcnr one more commit to review 😅 |
I'll pull it to another PR. It's not that important. |
d9dec12
to
228f408
Compare
In case a variable is unified with two universal regions from different universes, use the one with the lower universe as it has a higher chance of being compatible with the variable.
☀️ Test successful - checks-actions |
Finished benchmarking commit (7c306f6): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
The improvements greatly outweight the miniscule regressions here. The cycles and wall-time numbers for @rustbot label: +perf-regression-triaged |
RegionConstraintCollector::opportunistic_resolve_var
, which is used in canonicalization and projection logic, doesn't resolve the region var to an equal universal region. So if we have equated'static == '1 == '2
, it doesn't resolve'1
or'2
to'static
. Now it does!Addresses review comment #107376 (comment).
r? @lcnr