Positive and Negative Trait Implementations Clash Unexpectedly

[Ez-FlawLess]

Code

#![allow(unused)]
#![feature(negative_impls)]

trait MyTrait {}

#[derive(Clone)]
struct MyString {
    string: String,
}

impl<T: Copy> !MyTrait for T { }

// Works
impl MyTrait for MyString { }
// Throws error but it should work
impl MyTrait for String { }

fn main() {
    
}

rustc --version --verbose:

rustc 1.85.0-nightly (5f23ef7d3 2024-12-20)
binary: rustc
commit-hash: 5f23ef7d3f7a8c3e0ca5c4e1978829c0448a3686
commit-date: 2024-12-20
host: aarch64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.6

Error output

error[E0751]: found both positive and negative implementation of trait `MyTrait` for type `String`:
  --> src/main.rs:16:1
   |
11 | impl<T: Copy> !MyTrait for T { }
   | ---------------------------- negative implementation here
...
16 | impl MyTrait for String { }
   | ^^^^^^^^^^^^^^^^^^^^^^^ positive implementation here

[compiler-errors]

So we aren't as good at explaining coherence errors for negative impls, but if you change this to a positive impl you'll get the justification you need:

error[E0119]: conflicting implementations of trait `MyTrait` for type `std::string::String`
 --> <source>:8:1
  |
5 | impl<T: Copy> MyTrait for T { }
  | --------------------------- first implementation here
...
8 | impl MyTrait for String { }
  | ^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `std::string::String`
  |
  = note: upstream crates may add a new impl of trait `std::marker::Copy` for type `std::string::String` in future versions

That is to say, according to the orphan rules, the standard library is is technically free to add a new impl Copy for String implementation in the future. This would break your downstream crate, so the compiler proactively rejects this impl overlap.

The reason it works for MyString is because that's a type that is local to your crate.

[Ez-FlawLess]

Thanks. So the only thing we need is changing the error message?
@compiler-errors