Skip to content
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

Don't suggest changing &self and &mut self in function signature to be mutable when taking &mut self in closure #112019

Merged
merged 1 commit into from
Jun 6, 2023

Conversation

jieyouxu
Copy link
Member

Current suggestion for when taking a mutable reference to self in a closure (as an upvar) will produce a machine-applicable suggestion to change the self in the function signature to mut self, but does not account for the specialness of implicit self in that it can already have & and &mut (see #111554). This causes the function signature to become test(&mut mut self) which does not seem desirable.

error[E0596]: cannot borrow `self` as mutable, as it is not declared as mutable
   --> src/sound_player.rs:870:11
    |
869 |     pub fn test(&mut self) {
    |                      ---- help: consider changing this to be mutable: `mut self`
870 |     || test2(&mut self);
    |              ^^^^^^^^^ cannot borrow as mutable

This PR suppresses the "changing this to be mutable" suggestion if the implicit self is either ImplicitSelfKind::ImmRef or ImplicitSelfKind::MutRef.

Fixes #111554.

@rustbot
Copy link
Collaborator

rustbot commented May 27, 2023

r? @jackh726

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 27, 2023
@jieyouxu jieyouxu changed the title Don't suggest changing &self and &mut self to be mutable Don't suggest changing &self and &mut self in function signature to be mutable when taking &mut self in closure May 27, 2023
@compiler-errors compiler-errors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 29, 2023
@jieyouxu
Copy link
Member Author

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 29, 2023
@compiler-errors
Copy link
Member

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Jun 5, 2023

📌 Commit 57e67e4 has been approved by compiler-errors

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 5, 2023
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 6, 2023
…errors

Don't suggest changing `&self` and `&mut self` in function signature to be mutable when taking `&mut self` in closure

Current suggestion for when taking a mutable reference to `self` in a closure (as an upvar) will produce a machine-applicable suggestion to change the `self` in the function signature to `mut self`, but does not account for the specialness of implicit self in that it can already have `&` and `&mut` (see rust-lang#111554). This causes the function signature to become `test(&mut mut self)` which does not seem desirable.

```
error[E0596]: cannot borrow `self` as mutable, as it is not declared as mutable
   --> src/sound_player.rs:870:11
    |
869 |     pub fn test(&mut self) {
    |                      ---- help: consider changing this to be mutable: `mut self`
870 |     || test2(&mut self);
    |              ^^^^^^^^^ cannot borrow as mutable
```

This PR suppresses the "changing this to be mutable" suggestion if the implicit self is either `ImplicitSelfKind::ImmRef` or `ImplicitSelfKind::MutRef`.

Fixes rust-lang#111554.
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 6, 2023
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#111058 (Correct fortanix LVI test print function)
 - rust-lang#111369 (Added custom risc32-imac for esp-espidf target)
 - rust-lang#111962 (Make GDB Python Pretty Printers loadable after spawning GDB, avoiding required `rust-gdb`)
 - rust-lang#112019 (Don't suggest changing `&self` and `&mut self` in function signature to be mutable when taking `&mut self` in closure)
 - rust-lang#112199 (Fix suggestion for matching struct with `..` on both ends)
 - rust-lang#112220 (Cleanup some `EarlyBinder::skip_binder()` -> `EarlyBinder::subst_identity()`)
 - rust-lang#112325 (diagnostics: do not suggest type name tweaks on type-inferred closure args)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 21e7463 into rust-lang:master Jun 6, 2023
@rustbot rustbot added this to the 1.72.0 milestone Jun 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Taking a mutable reference to self in a closure leads to suggestion to change "self" in function signature
5 participants