Error says std might implement Send for types which are defined as !Send

[RReverser]

I tried this code:

use std::marker::PhantomData;

struct MyType {
    _definitely_not_thread_safe: PhantomData<*mut ()>,
}

impl<T: Send> From<T> for MyType {
    fn from(_: T) -> MyType {
        todo!()
    }
}

I expected to see this happen: It compiles, because there is no conflict - MyType clearly doesn't implement Send, so blanket implementation for T: Send is valid and shouldn't conflict with From<MyType> for MyType.

Instead, this happened:

error[E0119]: conflicting implementations of trait `From<MyType>` for type `MyType`
 --> <source>:7:1
  |
7 | impl<T: Send> From<T> for MyType {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: conflicting implementation in crate `core`:
          - impl<T> From<T> for T;
  = note: upstream crates may add a new impl of trait `std::marker::Send` for type `std::marker::PhantomData<*mut ()>` in future versions

This error seems wrong or misleading at least. After all, the whole point of using marker type in this way is to make something as non-Send/non-Sync.

I know of the unstable negative_impls feature, which would have the intended behaviour here even without a marker, but I'd assume that at least Rust core would already use negative trait impls for built-in types. Indeed, what makes such error even more confusing is that negative trait impl is exactly what Rust docs renders for these types:

Meta

(applies to all versions of the compiler, it's a language issue)

[asquared31415]

PhantomData only has the implicit positive auto impl for Send and such, there's no negative impls for any trait. It would be possible for core to write unsafe impl<T> Send for PhantomData<T> {}. This would be a breaking change for a few reasons, but none of which are encoded in the impl overlap rules.

[asquared31415]

If you removed the PhantomData wrapper, I expect this code should work, since there is an explicit negative impl on the raw pointer?

[asquared31415]

actually it turns out i was mistaken, using the pointer directly does not help. and in fact, the diagnostic still says "upstream might implement Send for *mut ()" (despite this being impossible)

this is a diagnostics issue which unfortunately needs to get into the details of how auto traits work and explicit negative impls, which are unstable

[RReverser]

actually it turns out i was mistaken, using the pointer directly does not help. and in fact, the diagnostic still says "upstream might implement Send for *mut ()" (despite this being impossible)

Heh yeah, I tried that before submitting the issue too, but no luck.

[RReverser]

this is a diagnostics issue

Just to be clear, by diagnostic issue do you mean the error message here should be better or that it shouldn't be an error in the first place?

I'd hope it's the latter but I imagine the fix would be more involved.

[asquared31415]

I don't think this code can be made to compile, at least not without the nightly negative_impls and explicitly saying "i promise to never implement Send for MyType".

There's almost 3 states of auto traits:

• implements the trait
• does not implement the trait, because not all fields implement the trait (but might implement it in the future, either by fields changing or explicitly)
• explicitly unimplements the trait and will never implement it

The impl overlap checker would need to be able to prove that MyType falls into the third category, which requires an explicit impl !Send for MyType {}. right now MyType falls into the second category, even when using a direct *mut () field.

And I assume you can see how fitting this into a "help" in an error message might be tricky, especially given that it interacts with unstable features, even when your code is entirely stable.

[RReverser]

Oof, auto traits + negative traits are hurting my head 😅

I'd kind of assume that T: Send and T: !Send would be explicitly opposite states, just like they are (IIUC) for any other T: Trait and T: !Trait, and that compiler should treat them as such.

That is, that auto-trait is kinda like implicit derive(), so a type either implements it or not, and the rest of the type checking can rely on that "boolean" state. Having a third state that is special only for auto-traits sure throws a wrench into that mental model...