-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
More precisely point out what is immutable for E0596 #113924
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
fe180e0
to
6b23a19
Compare
ed4fe97
to
bb468d2
Compare
help: this expression is of type `&str`, which is an immutable reference | ||
--> $DIR/issue-76510.rs:5:34 | ||
| | ||
LL | const S: &'static mut str = &mut " hello "; | ||
| ^^^^^^^^^ |
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.
I'm not exactly sure what this is trying to demonstrate.
The issue here is a subtle detail -- &mut X
will try to autoderef X
to match it to the type it needs. From the surface, &mut ""
looks like it should give you a type of &mut &'static str
, which is valid, but it's not valid because we autoderef it to make it into a &mut str
:
fn foo() {
// works
let x = &mut "";
// doesnt work
let y: &mut str = &mut "";
}
If you're not pointing this behavior out, then I don't really know if it's more helpful or more misleading to say "this is an expr of type &str
".
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.
how we don't give this hint when X
is a ExprKind::Lit(_)
?
since seems it does not provide more details.
dde0b99
to
a922780
Compare
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.
I still don't know if I like the presentation of this diagnostic. It still doesn't explain that the problem here is the autoderef behavior of &
/&mut
-- you're allowed to take a reference to &mut &Foo
-- the problem is that there's a deref being inserted there that's not present in the code, and I think a diagnostic improvement here should explain this. Without that, you're really just adding more labels.
@rustbot author |
I think one of the confusion from the origin issue is that the span contains the Considering |
a922780
to
fc0abde
Compare
Hi @chenyukang: I still don't believe this PR makes the underlying issue more easy to understand. It just points out that the pointee of the @rustbot author |
☔ The latest upstream changes (presumably #120576) made this pull request unmergeable. Please resolve the merge conflicts. |
@chenyukang any updates on this? thanks |
Closing this as inactive. Feel free to reöpen this pr or create a new pr if you get the time to work on this. Thanks |
Fixes #113842