Skip to content
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

Merged
merged 5 commits into from
Mar 15, 2018
Merged

Conversation

estebank
Copy link
Contributor

@estebank estebank commented Feb 11, 2018

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

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

@rust-highfive
Copy link
Collaborator

r? @bluss

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

@pietroalbini pietroalbini added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 11, 2018
@estebank estebank force-pushed the issue-45092 branch 3 times, most recently from 555a9f6 to d6b6c3a Compare February 12, 2018 05:17
@estebank
Copy link
Contributor Author

estebank commented Feb 12, 2018

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
Copy link
Contributor

bors commented Feb 12, 2018

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

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 12, 2018
@estebank estebank added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 12, 2018
#[rustc_on_unimplemented(
on(
_Self="std::sync::mpsc::Receiver<T>",
label="`{Self}` cannot be shared safely, if using a closure consider marking it `move`"
Copy link
Contributor

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

@shepmaster
Copy link
Member

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

@nikomatsakis
Copy link
Contributor

r? @nikomatsakis

@rust-highfive rust-highfive assigned nikomatsakis and unassigned bluss Feb 19, 2018
#[rustc_on_unimplemented(
on(
_Self="std::sync::mpsc::Receiver<T>",
label="`{Self}` cannot be shared safely, consider marking the closure `move`"
Copy link
Contributor

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.

Copy link
Contributor Author

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]
Copy link
Contributor

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

--> $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`
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Filed #48534.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

@nikomatsakis nikomatsakis added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 20, 2018
@estebank estebank added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 26, 2018
@bors
Copy link
Contributor

bors commented Feb 27, 2018

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

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 27, 2018
@pietroalbini pietroalbini added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 5, 2018
@nikomatsakis
Copy link
Contributor

@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
Copy link
Contributor

@nikomatsakis nikomatsakis added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 13, 2018
 - 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.
@estebank
Copy link
Contributor Author

@bors r=nikomatsakis

(@nikomatsakis based on #48138 (review))

@bors
Copy link
Contributor

bors commented Mar 15, 2018

📌 Commit 1bbd4fd has been approved by nikomatsakis

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 15, 2018
@bors
Copy link
Contributor

bors commented Mar 15, 2018

⌛ Testing commit 1bbd4fd with merge dda6f9b8c96840cff66a23c7bc0f61626b7c33a7...

@bors
Copy link
Contributor

bors commented Mar 15, 2018

💔 Test failed - status-appveyor

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 15, 2018
@pietroalbini
Copy link
Member

AppVeyor timed out.

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 15, 2018
@bors
Copy link
Contributor

bors commented Mar 15, 2018

⌛ Testing commit 1bbd4fd with merge ff2d506...

bors added a commit that referenced this pull request Mar 15, 2018
Reword E0044 and message for `!Send` types

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

CC #45092, #46678, #24909, #33307.
@alexcrichton
Copy link
Member

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
Copy link
Contributor

bors commented Mar 15, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants