-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Reword E0044 and message for !Send
types
#48138
Conversation
r? @bluss (rust_highfive has picked a reviewer for you, use r? to override) |
08ad027
to
2fdd7a2
Compare
555a9f6
to
d6b6c3a
Compare
CC @nikomatsakis: could you check the wording of the messages as well as the applicability across cases? The special label for |
d6b6c3a
to
611f1f7
Compare
☔ The latest upstream changes (presumably #47843) made this pull request unmergeable. Please resolve the merge conflicts. |
611f1f7
to
207e0c4
Compare
src/libcore/marker.rs
Outdated
#[rustc_on_unimplemented( | ||
on( | ||
_Self="std::sync::mpsc::Receiver<T>", | ||
label="`{Self}` cannot be shared safely, if using a closure consider marking it `move`" |
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 seems fine; it'd be nice if we could be more selective about giving the hint (e.g., if we could test that the "backtrace" contains a closure). I worry that the wording is a bit vague, since what it
refers to could be either the closure or the Receiver
. Perhaps "consider marking the closure move
".
Ping from triage, @bluss — will you have some time to review this PR soon? |
src/libcore/marker.rs
Outdated
#[rustc_on_unimplemented( | ||
on( | ||
_Self="std::sync::mpsc::Receiver<T>", | ||
label="`{Self}` cannot be shared safely, consider marking the closure `move`" |
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 forget if I said this before -- but we don't know that a closure is involved, do we? It seems odd to write "the closure" here.
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.
We don't, but it does seem to be the most common case that happens in the wild.
@@ -21,7 +21,7 @@ fn assert_send<T: ?Sized + Send>() { } | |||
|
|||
fn main() { | |||
assert_sync::<A>(); | |||
//~^ ERROR the trait bound `A: std::marker::Sync` is not satisfied | |||
//~^ ERROR `A` cannot be shared between threads safely [E0277] |
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 definitely prefer this wording =)
src/test/ui/closure-move-sync.stderr
Outdated
--> $DIR/closure-move-sync.rs:16:13 | ||
| | ||
16 | let t = thread::spawn(|| { | ||
| ^^^^^^^^^^^^^ `std::sync::mpsc::Receiver<()>` cannot be shared safely, consider marking the closure `move` |
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.
the message happens to work here, but I imagine you could also have a scenario like this
fn gimme<T: Send>(_: T) { }
fn main() {
let (send, _recv) = ::std::sync::mpsc::channel();
gimme(&send);
}
What gets printed here?
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.
You'll get the label mentioning closures. That's why the original label was more ambiguous. I'll have to expand rustc_on_unimplemented
to be able to tell if a closure is involved in order to a message that is always correct.
I think that I'd prefer to merge this PR with the previous ambiguous wording ("std::sync::mpsc::Receiver<()>
cannot be shared safely, if using a closure consider marking it move
") and work on a follow up to improve that. I'm also waiting on #47613 to land in beta so that this message can be part of a note instead of the label.
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 could live with an ambiguous message for now, I suppose.
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.
Could we file a follow-up bug though describing the ambiguous message and thoughts for improvement? (And tag the message with // FIXME
and the issue number...)
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.
Filed #48534.
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.
Updated.
☔ The latest upstream changes (presumably #48449) made this pull request unmergeable. Please resolve the merge conflicts. |
@Zoxc hmm -- it's not a bad idea to include (Note that the |
Grumpy travis: |
- Reword E0044 help. - Change error message for types that don't implement `Send`
…ender}` Extend `rustc_on_unimplemented` to match on ADT without evaluating type arguments.
@bors r=nikomatsakis (@nikomatsakis based on #48138 (review)) |
📌 Commit 1bbd4fd has been approved by |
⌛ Testing commit 1bbd4fd with merge dda6f9b8c96840cff66a23c7bc0f61626b7c33a7... |
💔 Test failed - status-appveyor |
AppVeyor timed out. @bors retry |
For the previous failure:
It took two hours to figure out cloning that repo failed 😱 |
☀️ Test successful - status-appveyor, status-travis |
Send
CC #45092, #46678, #24909, #33307.