-
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
fallback to resolve infer generics in type-changing-struct-update #102129
fallback to resolve infer generics in type-changing-struct-update #102129
Conversation
r? @estebank (rust-highfive has picked a reviewer for you, use r? to override) |
☔ The latest upstream changes (presumably #102306) made this pull request unmergeable. Please resolve the merge conflicts. |
let variances = tcx.variances_of(adt_ty.ty_adt_def().expect("not a adt ty!").did()); | ||
|
||
iter::zip(a_subst, b_subst).enumerate().for_each(|(i, (a, b))| { | ||
let _arg: RelateResult<'tcx, GenericArg<'tcx>> = |
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 are you throwing this result away?
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.
The purpose of this code is to instantiate the uninstantiated infer
generic created for base_expr in check_expr_struct_fields
by calling the relate_generic_arg
function. If Err
is returned, the generic type has been instantiated by the type of base_expr
itself and is not constrained by the created struct (constrained ones hav been checked in check_expr_struct_fields
).
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.
Perhaps we can have a more accurate approach, such as maintaining a non-constrained generic indexes list for base_expr
.
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.
Given that this is purely for diagnostics, this approach might be fine, but including what you wrote above as a comment would be welcome.
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.
Given that this is purely for diagnostics
I'm confused by this comment. This isn't purely diagnostic, I thought? My understanding is that this function affects type inference -- notably, relate_generic_arg
is also not an atomic operation, so even if it returns Err
, it can still partially constrain inference variables inside of that.
I'm not convinced that this approach is completely sound. I would be comfortable with something more along the lines of:
such as maintaining a non-constrained generic indexes list for base_expr.
At least in that case it's easier to reason about when we're allowed to unify unconstrained inference variables and when we expect to raise errors.
2ffc007
to
ae5c596
Compare
☔ The latest upstream changes (presumably #101632) made this pull request unmergeable. Please resolve the merge conflicts. |
Can we do a crater run to see if this will fix all breakages? On the issue the lang team expressed that this could be done via an edition change, but wouldn't it just work as good if this would resolve them? cc @scottmcm |
@bors try @craterbot run |
🚨 Error: missing start toolchain 🆘 If you have any trouble with Crater please ping |
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message
|
@rustbot author |
ae5c596
to
61fd9d5
Compare
@bors try |
⌛ Trying commit 61fd9d5 with merge cbe8532756bbbc4b7f32dda40d05981c8aeffd80... |
Just rebased the PR. We can have a crate run first |
☀️ Try build successful - checks-actions |
@craterbot run |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
@craterbot abort |
🗑️ Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
I'm going to reroll, I don't have the bandwidth for this PR at the moment. r? compiler |
This still seems to leave some regressions according to the crater run. This definitely needs further discussion discussion on the changes to inference here, and I still have some concerns (#102129 (comment)) on the exact implementation that we're doing here. |
@SparrowLii @rustbot label: +S-inactive |
Fixes #101970
When creating a struct with a base struct, we store the base struct's type which has infer generics. And then unify it with the created struct's generics through a function-body-scoped fallback during typeck.
cc #86555