Send impl error message is too smart

[Gankra]

use std::collections::BTreeMap;
use std::rc::Rc;
fn foo<T: Send>() {}
fn main() {
    foo::<BTreeMap<Rc<()>, Rc<()>>>();
}

<anon>:5:5: 5:36 error: the trait `core::marker::Send` is not implemented for the type `alloc::rc::Rc<()>` [E0277]
<anon>:5     foo::<BTreeMap<Rc<()>, Rc<()>>>();
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<anon>:5:5: 5:36 note: `alloc::rc::Rc<()>` cannot be sent between threads safely
<anon>:5     foo::<BTreeMap<Rc<()>, Rc<()>>>();
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

The lack of an impl of Send for Rc is the problem, but the more pertinent problem is that BTreeMap itself is not Send. The Rc detail is a great piece of additional information, though.

[Gankra]

cc @Manishearth

[FillZpp]

I think the Send is not implemented for Rc, you may use Arc instead.

use std::collections::BTreeMap;
use std::sync::Arc;
fn foo<T: Send>() { }
fn main() {
    foo::<BTreeMap<Arc<()>, Arc<()>>>();
}

It would work.

[Manishearth]

That's not the issue here, the issue is that the error is complaining directly about Rc without mentioning that BTreeMap is Send only for Send parameters

[huonw]

This is particularly bad when its some type hidden deep in internals that is causing the problem, since it can be very non-obvious where the non-Sync/Sendness is coming from. Notably, this example demonstrates it reaching through privacy barriers into the implementation details of Sender, and, just looking at Bar, one can't determine which field is causing issues without manually digging through the types.

use std::sync::mpsc::Sender;

struct Foo {
    x: Sender<()>,
}

struct SomethingComplicated; /* lots of fields ... */

struct Bar {
    y: SomethingComplicated,
    z: Vec<Foo>,
    // etc.
}

fn test_sync<T: Sync>() {}

fn main() {
    test_sync::<Bar>();
}

<anon>:18:5: 18:21 error: the trait `core::marker::Sync` is not implemented for the type `core::cell::UnsafeCell<std::sync::mpsc::Flavor<()>>` [E0277]
<anon>:18     test_sync::<Bar>();
              ^~~~~~~~~~~~~~~~
<anon>:18:5: 18:21 note: `core::cell::UnsafeCell<std::sync::mpsc::Flavor<()>>` cannot be shared between threads safely
<anon>:18     test_sync::<Bar>();
              ^~~~~~~~~~~~~~~~

It would be nice to do a "call stack", maybe a little like:

error: the trait `core::marker::Sync` is not implemented for type `Bar` because ...
// code snippet/span of call site
error: ... it is not implemented for type `Vec<Foo>` stored in field `z` because ...
// code snippet/span of Bar::z
error: ... it is not implemented for type `Foo` because ...
// code snippet/span of the Foo in Vec<Foo>
error: ... it is not implemented for type `Sender` stored in field `x`.
// code snippet/span of Foo::x

(All the becauses are a little ridiculous...)

In that model, I'm stopping at crate boundaries, but it may also make sense to continue to stop at the first explicit negative impl.

[nikomatsakis]

At some point @flaper87 and I did include a full stack trace. I'm not sure at what point it got lost.

[flaper87]

@nikomatsakis we did it when we landed the negative trait implementation support. I'll check if that code changed but in theory it should still be there.

[Manishearth]

If you point me to it I can probably reimplement it.

[Manishearth]

I got some similar errors when playing with OIBIT

#![feature(optin_builtin_traits)]

fn main() {
println!("{} {}", 1u8.foo(), <u32 as SizeOf>::foo(&1u64))
}


trait SizeOf {
    fn foo(&self) -> u8;
}

trait SizeOfOI {}
impl SizeOfOI for .. {
}

impl<T> SizeOf for T where T: SizeOfOI {
    fn foo(&self) -> u8 {0}
}

impl !SizeOfOI for u8 {}

impl SizeOf for u8{
    fn foo(&self) -> u8 {1}
}

impl !SizeOfOI for u32 {}

playpen

(I'm using this code for a heap-size deriving which needed an overridable blanket impl)

Instead of telling me that SizeOf isn't implemented for u64, it tells me that SizeOfOI isn't implemented for u64, which is pretty confusing when found in a larger context.

[arielb1]

On nightly, the error message is

<anon>:5:5: 5:36 error: the trait `core::marker::Send` is not implemented for the type `alloc::rc::Rc<()>` [E0277]
<anon>:5     foo::<BTreeMap<Rc<()>, Rc<()>>>();
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<anon>:5:5: 5:36 help: see the detailed explanation for E0277
<anon>:5:5: 5:36 note: `alloc::rc::Rc<()>` cannot be sent between threads safely
<anon>:5     foo::<BTreeMap<Rc<()>, Rc<()>>>();
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<anon>:5:5: 5:36 note: required because it appears within the type `collections::btree::node::Node<alloc::rc::Rc<()>, alloc::rc::Rc<()>>`
<anon>:5     foo::<BTreeMap<Rc<()>, Rc<()>>>();
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<anon>:5:5: 5:36 note: required because it appears within the type `collections::btree::map::BTreeMap<alloc::rc::Rc<()>, alloc::rc::Rc<()>>`
<anon>:5     foo::<BTreeMap<Rc<()>, Rc<()>>>();
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<anon>:5:5: 5:36 note: required by `foo`
<anon>:5     foo::<BTreeMap<Rc<()>, Rc<()>>>();
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

Slightly verbose (e.g., we can avoid repeating the span every time) but I think this is solved.

[jdm]

#28378 has a testcase that shows poor behaviour on a rustc from ~12 days ago; is that any better now?