Skip to content

Compiler should hint to user to deref when doing reference assignment #33570

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
frewsxcv opened this issue May 11, 2016 · 4 comments · Fixed by #61054
Closed

Compiler should hint to user to deref when doing reference assignment #33570

frewsxcv opened this issue May 11, 2016 · 4 comments · Fixed by #61054
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@frewsxcv
Copy link
Member

frewsxcv commented May 11, 2016

https://is.gd/wm0S9G

fn change_opt(opt: &mut Option<String>){
    opt = None
}
<anon>:2:11: 2:15 error: mismatched types:
 expected `&mut core::option::Option<collections::string::String>`,
    found `core::option::Option<_>`
(expected &-ptr,
    found enum `core::option::Option`) [E0308]
<anon>:2     opt = None
                   ^~~~
<anon>:2:11: 2:15 help: see the detailed explanation for E0308
error: aborting due to previous error

It'd be great if this had a hint:

 Did you mean `*opt = None`

Someone on IRC just ran into this.

@pnkfelix
Copy link
Member

pnkfelix commented May 11, 2016

In the general case (i.e. for arbitrary expr: T and let mut opt: &mut T), can we know whether the intention was

opt = &mut expr;

or if it was

*opt = expr;

?

I would be a little cautious about unilaterally suggesting the latter when the former is potentially what was desired...

  • Update: after thinking on the matter more (see bottom of comment), I am less nervous about a unilateral suggestion.

(However, when opt is declared as non-mut, I'm a little more amenable towards suggesting *opt = expr...)


Update: of course in many cases suggesting opt = &mut expr; will be a bad idea. E.g. opt = &mut None; will almost certainly yield a "borrowed value does not live long enough" message. Maybe there's some smarter analysis of the expr that can figure out when to not bother suggesting the nonsensical one.

@durka
Copy link
Contributor

durka commented May 11, 2016

@pnkfelix if opt is mut you could suggest both, otherwise just the dereference.

@steveklabnik steveklabnik added the A-diagnostics Area: Messages for errors, warnings, and lints label May 24, 2016
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 25, 2017
@estebank
Copy link
Contributor

The compiler now suggests:

error[E0308]: mismatched types
 --> src/main.rs:2:11
  |
2 |     opt = None
  |           ^^^^ expected mutable reference, found enum `std::option::Option`
  |
  = note: expected type `&mut std::option::Option<std::string::String>`
             found type `std::option::Option<_>`
  = help: try with `&mut None`

The suggestion is not smart enough to also suggest *opt = None.

@estebank
Copy link
Contributor

Update:

error[E0308]: mismatched types
 --> src/main.rs:2:11
  |
2 |     opt = None
  |           ^^^^
  |           |
  |           expected mutable reference, found enum `std::option::Option`
  |           help: consider mutably borrowing here: `&mut None`
  |
  = note: expected type `&mut std::option::Option<std::string::String>`
             found type `std::option::Option<_>`

Compiler still not smart enough to suggest *opt = None.

Centril added a commit to Centril/rust that referenced this issue May 23, 2019
…avis

Suggest dereferencing on assignment to mutable borrow

Fix rust-lang#33570
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants