-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Bogus "consider specifying this binding's type" when reference differs in mutability #113767
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
Comments
Can I try to fix this? :) |
It seems this can happen in function arguments too, where the suggestion also results in invalid syntax. If the pub async fn json_from_response<T: DeserializeOwned>(response: &mut Response) -> anyhow::Result<T> {
response
.json()
.await
.map_err(|e| anyhow!(e.to_string()))
.context("could not get JSON")
} ...is replaced by Invalid clippy suggestion for completenesswarning: this argument is a mutable reference, but not used mutably
--> src/network.rs:46:64
|
46 | pub async fn json_from_response<T: DeserializeOwned>(response: &mut Response) -> anyhow::Result<T> {
| ^^^^^^^^^^^^^ help: consider changing to: `&Response`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_pass_by_ref_mut
= note: `#[warn(clippy::needless_pass_by_ref_mut)]` on by default
warning: `signalupdates-bot` (lib) generated 1 warning ...that results in: error[E0596]: cannot borrow `*response` as mutable, as it is behind a `&` reference
--> src/network.rs:47:5
|
47 | response
| ^^^^^^^^ `response` is a `&` reference, so the data it refers to cannot be borrowed as mutable
|
help: consider specifying this binding's type
|
46 | pub async fn json_from_response<T: DeserializeOwned>(response: &mut worker::Response: &Response) -> anyhow::Result<T> {
| +++++++++++++++++++++++ which suggests adding a second type to the function argument. Sorry for non-minimal example / if it's a different issue. |
It looks like this happens only for async fn foo(x: &Vec<i32>) {
x.push(42);
}
This makes sense, because the fn foo(x: &Vec<i32>) -> impl core::future::Future<Output = ()> + '_ {
async move {
let x = x; // <-- notice let binding here
x.push(42);
}
} ... and the compiler then tries to help by suggesting
Yes, absolutely, feel free to work on this. Be sure to check out the dev guide and don't hesitate to ask in the help channel on zulip if you have any questions. |
Awesome! thanks 🦀 |
@rustbot claim |
issue: rust-lang#113767 This commit disables the "consider changing this bindings type" suggestion in cases where the initial value of a binding is not mutable and the suggestion is therefore invalid.
issue: rust-lang#113767 This commit disables the "consider changing this bindings type" suggestion in cases where the initial value of a binding is not mutable and the suggestion is therefore invalid.
Code
Current output
Desired output
Rationale and extra context
The type is defined as immutable reference by the return type of the function and specifying it as a mutable reference in the let binding won't help.
Other cases
This seems to happen only if
let x = &vec![];
)x
goes through auto(de)ref with a method call or field access (eg.x.field = 1
)Anything else?
@rustbot label A-suggestion-diagnostics D-incorrect
The text was updated successfully, but these errors were encountered: