Reword E0044 and message for !Send types

[estebank]

• Reword E0044 help.
• Change error message for types that don't implement Send

CC #45092, #46678, #24909, #33307.

[rust-highfive]

r? @bluss

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

[estebank]

CC @nikomatsakis: could you check the wording of the messages as well as the applicability across cases?

The special label for channel::{Reciever, Sender} should become a note instead once note support for rustc_on_unimplemented lands in beta.

[bors]

☔ The latest upstream changes (presumably #47843) made this pull request unmergeable. Please resolve the merge conflicts.

[nikomatsakis]

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".

[shepmaster]

Ping from triage, @bluss — will you have some time to review this PR soon?

[nikomatsakis]

r? @nikomatsakis

[nikomatsakis]

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.

[estebank]

We don't, but it does seem to be the most common case that happens in the wild.

[nikomatsakis]

I definitely prefer this wording =)

[nikomatsakis]

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?

[estebank]

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.

[nikomatsakis]

I could live with an ambiguous message for now, I suppose.

[nikomatsakis]

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...)

[estebank]

Filed #48534.

[estebank]

Updated.

[bors]

☔ The latest upstream changes (presumably #48449) made this pull request unmergeable. Please resolve the merge conflicts.

[nikomatsakis]

@Zoxc hmm -- it's not a bad idea to include Sync, I agree, but I can't think of a nice wording. Any thoughts?

(Note that the help message does mention Sync explicitly, so the info is still there, though you have to look a bit harder.)

[nikomatsakis]

Grumpy travis:

https://travis-ci.org/rust-lang/rust/builds/352438805#L2500

[estebank]

@bors r=nikomatsakis

(@nikomatsakis based on #48138 (review))

[bors]

📌 Commit 1bbd4fd has been approved by nikomatsakis

[bors]

⌛ Testing commit 1bbd4fd with merge dda6f9b8c96840cff66a23c7bc0f61626b7c33a7...

[bors]

💔 Test failed - status-appveyor

[emilyalbini]

AppVeyor timed out.

@bors retry

[bors]

⌛ Testing commit 1bbd4fd with merge ff2d506...

[alexcrichton]

For the previous failure:

[00:01:35] Cloning into '/c/cache/rustsrc/src/src/doc/rust-by-example'...
[02:26:08] error: RPC failed; curl 18 transfer closed with outstanding read data remaining
[02:26:08] fatal: The remote end hung up unexpectedly
[02:26:08] fatal: early EOF
[02:26:08] fatal: index-pack failed
[02:26:09] fatal: clone of 'https://github.com/rust-lang/rust-by-example' into submodule path '/c/cache/rustsrc/src/src/doc/rust-by-example' failed

It took two hours to figure out cloning that repo failed 😱

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing ff2d506 to master...