-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Handle recursion limit for subtype and well-formed predicates #117754
Conversation
I think this makes sense but @lcnr knows overflow handling better so passing to them r? lcnr |
// Test that generalize handles variables that have a subtype relation to an | ||
// already resolved value, but not an equality relation. | ||
// Found when considering fixes to #117151 | ||
// check-pass |
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 test feels a bit :/ currently the way we generalize higher ranked types is wrong when subtyping.
we currently do the following (using x
for the infer var in x: None<_>
):
- emit (and stall on) a
Subtype(x <: y)
obligation - the
w = a
assignment setsx
tofor<'a> fn(&'a ())
, emits aSubtype(y <: z)
obligation and generalizesz
tofn(&'0 ())
. - we then prove
Subtype(x <: y)
settingy
tofor<'a> fn(&'a ())
and then proveSubtype(y <: z)
which is now trivial as both types are rigid.
If we were to prove the Subtype
obligations before generalizing z
we'd get an incorrect error, e.g:
fn main() {
let mut x = None;
let y = x;
let z = Default::default();
let mut w = (&mut x, z, z);
let mut temp = None::<for<'a> fn(&'a ())>;
w.0 = &mut temp;
w.1 = y;
w.2 = None::<fn(&'static ())>; //~ ERROR mismatched types
}
It feels like this test mostly tests a very specific impl detail of our subtyping algorithm where we do not try to eagerly make progress on previous Subtype
obligations while relating.
I think the explanation here is somewhat misleading. The reason this works is because generalization does not care about subtype relations (apart from the occurs check). I would instead use sth like "Subtyping of inference variables is currently handled via delayed Subtype
obligations. We do not immediately process them after constraining one of the involved inference variables. We'd otherwise incorrectly constrain the type of z
as generalization does not handle binders correctly".
r=me on the impl changes, would like to improve the test explanation however |
☔ The latest upstream changes (presumably #118120) made this pull request unmergeable. Please resolve the merge conflicts. |
e164c54
to
b5da932
Compare
This comment has been minimized.
This comment has been minimized.
b5da932
to
942e939
Compare
@bors r+ rollup thanks 👍 |
☀️ Test successful - checks-actions |
Finished benchmarking commit (0919ad1): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. 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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 671.261s -> 672.207s (0.14%) |
Adds a recursion limit check for subtype predicates and well-formed predicates.
-Ztrait-solver=next
currently panics with unimplemented for these cases.These cases are arguably bugs in the occurs check but:
closes #117151
r? types