-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
region unification: update universe of region vars #121442
Conversation
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
region unification: update universe of region vars necessary for rust-lang#119106. see inline comment for why this is necessary r? `@compiler-errors` `@BoxyUwU`
This comment has been minimized.
This comment has been minimized.
.unwrap_or_else(|| ty::Region::new_var(tcx, root_vid)); | ||
|
||
// Don't resolve a variable to a region that it cannot name. | ||
if self.var_universe(vid).can_name(self.universe(resolved)) { |
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.
if we equate an infer var with a root which is in a higher universe, we previously did not return that root vid here. This caused the PlaceholderReplacer
to not map a placeholder region back to a bound var in deeply_normalize
(with #119106) due to the following setup:
for<'a> fn(RigidAlias<'a>)
gets instantiated asfn(RigidAlias<'!a>)
- normalizing
RigidAlias<'!a>
emitsAliasRelate(RigidAlias<'!a>, ?u)
- uniquifying regions in the input results in the canonical goal
exists<U> exists<'a> AliasRelate(RigidAlias<'a>, U)
- inside of the query we instantiate this to get
RigidAlias<'?a.1>
and?u.0
NormalizesTo
fails, so we first instantiate?u.0
withRigidAlias<'new.whatever>
, the universe of that gets pulled down into universe0
- we then equate the args of
RigidAlias<'new.0>
withRigidAlias<'a.1>
, equating'new
and'a
, using'a
as the root in the unification table - when canonicalizing the response, we are unable to canonicalize
'new
as'a
because the universe of'a
is higher than the universe of'new
- because of this
RigidAlias<'!a>
normalizes toRigidAlias<'new>
where'new
is constrained to be equal to'!a
- we fail to map
'new
back to'a
in thePlaceholderReplacer
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.
- inside of the query we instantiate this to get
RigidAlias<'?a.1>
and?u.0
This looks like an issue with the new solver canonicalization! the universe of ?u
should certainly be able to name '?a
. How does ?a
end up in U1 and ?u
as U0?
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.
In the new solver all regions are canonicalized to new inference variables in a single universe that is higher than everything else in the input. ?u
can name '?a
even with this setup it just requires lowering '?a
's universe when equating it which is something we already do for cases like ?x.0 eq ?y.1
. Even if the new solver did not have this canonicalization scheme I would still expect this PR to be required somehow as it is just wrong for '?x.0 eq '?y.1
to not allow resolving '?x
to '?y
later on and there should be other ways to wind up with a region variable in a higher universe that is equated with something in a lower one
a7ea3de
to
2bf4c79
Compare
fn unify_values(value1: &Self, value2: &Self) -> Result<Self, Self::Error> { | ||
match (*value1, *value2) { | ||
(RegionVariableValue::Known { .. }, RegionVariableValue::Known { .. }) => { | ||
// FIXME: We could alternatively use the value with a lower universe, |
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.
Why didn't you implement this? Do we expect this branch to be hit?
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.
I expect it to be hit, I can't completely tell whether it's desirable though 🤷
I personally don't think it is really 🤔 so yeah, should maybe just remove the FIXME 😁
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.
yeah, I think that after reworking lexical region resolution, we may want to look into not emitting subtype constraints if we're able to unify the region vids. At that point unifying known regions won't work anymore anyways.
@rust-timer build 9d779e1 |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (9d779e1): 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 649.949s -> 649.436s (-0.08%) |
thank u 👍 @bors r+ |
12b9040
to
16350d7
Compare
removed the FIXME @bors r=compiler-errors |
…iler-errors region unification: update universe of region vars necessary for rust-lang#119106. see inline comment for why this is necessary r? `@compiler-errors` `@BoxyUwU`
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
@bors retry |
☀️ Test successful - checks-actions |
Finished benchmarking commit (ea2cc43): comparison URL. Overall result: ✅ improvements - no action needed@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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 650.894s -> 649.932s (-0.15%) |
necessary for #119106. see inline comment for why this is necessary
r? @compiler-errors @BoxyUwU