-
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
Fix up autoderef when reborrowing #72280
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @eddyb (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
It ended up that #68590 is caused by a similar issue. When a implicit mutable reborrow happens, it is equivalent to |
☔ The latest upstream changes (presumably #72346) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
Gah, ran out of time for reviews today, but here is one tiny nit =)
BTW it is recommended to review commit by commit, as I've intentionally separated the PR into individually meaningful commits. |
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.
What do you think of this refactoring idea I describe below?
@nbdd0121 Apologies for the slow review. Took me a bit to grok this PR. I'll try to be snappier from now on (I've gotten on top of my backlog) |
I checked all callers of I also checked all construction of
To avoid wasteful call into Alternatively, we can modify these three places to use What do you think? @nikomatsakis |
This can live inside FnCtxt rather than ConfirmContext, and would be useful for other operations as well.
Refactoring idea: |
@nbdd0121 remind me, the If so, I have indeed contemplating removing it and relying solely on the "fixup" path that we need to have anyway. |
Regarding your other comments, I would prefer to not have an additional argument indicating whether the fixup is needed unless we have evidence that it's a performance hazard, just because I think it's better to keep things simple. If we can refactor away |
Yes, |
⌛ Trying commit 5cedf5d with merge d6a8b4706fb7d366174f875dc50d1b591c21d310... |
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.
Gave it a quick skim, seems like a massive simplification, but I want to re-review when considering the full PR -- I feel like I'm missing something, maybe it's almost too easy now. ;) Anyway let's look at the perf results.
☀️ Try build successful - checks-azure |
Queued d6a8b4706fb7d366174f875dc50d1b591c21d310 with parent c8a9c34, future comparison URL. |
Finished benchmarking try commit (d6a8b4706fb7d366174f875dc50d1b591c21d310): comparison url. |
OK, perf looks neutral, that's good. |
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 looks great! I left a few comment nits (here, and in my previous review), but r=me once those are satisfied!
@bors r=nikomatsakis |
@nbdd0121: 🔑 Insufficient privileges: Not in reviewers |
@bors r+ |
📌 Commit 2b7d858 has been approved by |
Rollup of 10 pull requests Successful merges: - rust-lang#72280 (Fix up autoderef when reborrowing) - rust-lang#72785 (linker: MSVC supports linking static libraries as a whole archive) - rust-lang#73011 (first stage of implementing LLVM code coverage) - rust-lang#73044 (compiletest: Add directives to detect sanitizer support) - rust-lang#73054 (memory access sanity checks: abort instead of panic) - rust-lang#73136 (Change how compiler-builtins gets many CGUs) - rust-lang#73280 (Add E0763) - rust-lang#73317 (bootstrap: read config from $RUST_BOOTSTRAP_CONFIG) - rust-lang#73350 (bootstrap/install.rs: support a nonexistent `prefix` in `x.py install`) - rust-lang#73352 (Speed up bootstrap a little.) Failed merges: r? @ghost
Add UI test for issue 73592 It happens that rust-lang#72280 accidentally fixed a bug which is later discovered in rust-lang#73592. This PR adds a UI test to prevent future regression. Closes rust-lang#73592
Add UI test for issue 73592 It happens that rust-lang#72280 accidentally fixed a bug which is later discovered in rust-lang#73592. This PR adds a UI test to prevent future regression. Closes rust-lang#73592
Fix regionck failure when converting Index to IndexMut Fixes rust-lang#74933 Consider an overloaded index expression `base[index]`. Without knowing whether it will be mutated, this will initially be desugared into `<U as Index<T>>::index(&base, index)` for some `U` and `T`. Let `V` be the `expr_ty_adjusted` of `index`. If this expression ends up being used in any mutable context (or used in a function call with `&mut self` receiver before rust-lang#72280), we will need to fix it up. The current code will rewrite it to `<U as IndexMut<V>>::index_mut(&mut base, index)`. In most cases this is fine as `V` will be equal to `T`, however this is not always true when `V/T` are references, as they may have different region. This issue is quite subtle before rust-lang#72280 as this code path is only used to fixup function receivers, but after rust-lang#72280 we've made this a common path. The solution is basically just rewrite it to `<U as IndexMut<T>>::index_mut(&mut base, index)`. `T` can retrieved in the fixup path using `node_substs`.
Currently
(f)()
andf.call_mut()
behaves differently if expressionf
contains autoderef in it. This causes a weird error in #72225.When
f
is type checked,Deref
is used (this is expected as we can't yet determine if we should useFn
orFnMut
). When subsequently we determine the actual trait to be used, when using thef.call_mut()
syntax theDeref
is patched toDerefMut
, while for the(f)()
syntax case it is not.This PR replicates the fixup for the first case.
Fixes #72225
Fixes #68590