-
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
Ignore arguments when looking for IndexMut
for subsequent mut
obligation
#72068
Conversation
r? @davidtwco (rust_highfive has picked a reviewer for you, use r? to override) |
CC @eddyb, @oli-obk, @nikomatsakis who will likely be interested in checking this out for correctness. @davidtwco don't approve without input from them as I fear this might not be sound for some reason. |
r? @oli-obk |
Just from looking at the function you changed, I would have said the bug is in the |
Skimming the diff, I agree with @oli-obk that this doesn't seem like the right approach. I think I would want to see the logs coming from this call: rust/src/librustc_typeck/check/method/mod.rs Line 331 in 3fe4dd2
There must be some underlying bug here. |
It seems to me that the difference in behavior is that when
Also, changing It might be that what needs to change is the call to rust/src/librustc_typeck/check/method/confirm.rs Lines 470 to 478 in 4282776
in order to get the correctly resolved type for the index expr, with all the previously accepted derefs applied. I'd tried doing the same thing I saw above, rust/src/librustc_typeck/check/method/confirm.rs Lines 447 to 467 in 4282776
navigating the adjustments and changing the type being passed in, but that was giving me MIR errors afterwards (about finding Looking at that code with fresh eyes, I see that I was cargo-culting the update, using |
…igation Given code like `v[&field].boo();` where `field: String` and `.boo(&mut self)`, typeck will have decided that `v` is accessed using `Index`, but when `boo` adds a new `mut` obligation, `convert_place_op_to_mutable` is called. When this happens, for *some reason* the arguments' dereference adjustments are completely ignored causing an error saying that `IndexMut` is not satisfied: ``` error[E0596]: cannot borrow data in an index of `Indexable` as mutable --> src/main.rs:30:5 | 30 | v[&field].boo(); | ^^^^^^^^^ cannot borrow as mutable | = help: trait `IndexMut` is required to modify indexed content, but it is not implemented for `Indexable` ``` This is not true, but by changing `try_overloaded_place_op` to retry when given `Needs::MutPlace` without passing the argument types, the example successfully compiles. I believe there might be more appropriate ways to deal with this.
I don't know, but it's easy to test by changing the Anyway, yes this looks like the right fix now, and makes me wonder if we have similar issues flying around. Maybe we should rename |
I made a quick check and from the looks of it we only get issues around binops in const scopes (complaining about not yet stable comp fns) and some borrow check errors in binop assignments talking about borrowing, but the output is not necessarily worse in all cases. It seems like this change is something we should consider doing soon. |
@oli-obk let me know if I should make any further changes on this PR (which would be nice to backport soon) and we can change how we call |
I agree that, in most cases, invoking |
@bors r+ |
📌 Commit 0dcde02 has been approved by |
the issue isn't marked as a stable/beta regression. Should it be?
This seems like a fairly mechanical change. Maybe open an E-mentor issue for it? |
Rollup of 5 pull requests Successful merges: - rust-lang#71886 (Stabilize saturating_abs and saturating_neg) - rust-lang#72066 (correctly handle uninferred consts) - rust-lang#72068 (Ignore arguments when looking for `IndexMut` for subsequent `mut` obligation) - rust-lang#72338 (Fix ICE in -Zsave-analysis) - rust-lang#72344 (Assert doc wording) Failed merges: r? @ghost
It's not a regression because it's always been broken, but given how low risk it is I thought it could jump on the running train. That being said, I guess I'm getting too happy to do that and from a policy stand point we shouldn't do so and let it wait in the station for a few weeks won't hurt anyone (beyond the people I saw horribly confused a few weeks back when they hit this and couldn't understand why it didn't work, but that's always true for stable users).
👍 |
Given code like
v[&field].boo();
wherefield: String
and.boo(&mut self)
, typeck will have decided thatv
is accessed usingIndex
, but whenboo
adds a newmut
obligation,convert_place_op_to_mutable
is called. When this happens, for somereason the arguments' dereference adjustments are completely ignored
causing an error saying that
IndexMut
is not satisfied:This is not true, but by changing
try_overloaded_place_op
to retrywhen given
Needs::MutPlace
without passing the argument types, theexample successfully compiles.
I believe there might be more appropriate ways to deal with this.
Fix #72002.