conflicting implementations when attempting to impl<S> Into<S> for ArbitraryStructWithNoOtherImpls<S>

[codyps]

At the very least (if this failure is expected), the error needs to be improved to actually point to the conflicting impl rather than simply printing the crate name and repeating the same function output that conflicts (if it is for some reason not possible to print better info about the previously declared conflicting impl, at the very least the compiler should stop repeating the output for the impl generating the error). On the diagnostics side, this appears related to #27218.

Note that simply changing the struct (in this case, GenX<T>) to a non-generic struct allows the build to proceed without issue (example: http://is.gd/lRAhBF).

It appears that somehow the impl<T, U> Into<U> for T where U: From<T> is considered to be conflicting with all Into<U> impls where U is a generic parameter even in cases where U does not impl From<T>.

error:

<anon>:6:1: 10:2 error: conflicting implementations for trait `core::convert::Into` [E0119]
<anon>: 6 impl<S> Into<S> for GenX<S> {
<anon>: 7     fn into(self) -> S {
<anon>: 8         self.inner
<anon>: 9     }
<anon>:10 }
<anon>:6:1: 10:2 help: see the detailed explanation for E0119
<anon>:6:1: 10:2 note: conflicting implementation in crate `core`
<anon>: 6 impl<S> Into<S> for GenX<S> {
<anon>: 7     fn into(self) -> S {
<anon>: 8         self.inner
<anon>: 9     }
<anon>:10 }
error: aborting due to previous error

source:

pub struct GenX<S> {
    inner: S,
}
impl<S> Into<S> for GenX<S> {
    fn into(self) -> S {
        self.inner
    }
}

playpen: http://is.gd/zrwjve

[eefriedman]

In your example, the compiler can't prove that S doesn't implement From<GenX<S>>. In the general case, S could come from a crate which depends on your crate.

I agree with your assessment of the diagnostic.

[codyps]

@eefriedman I suppose in that case I'd consider the conflict to come from the provider of the From impl, and give an error when that downstream crate attempted to build (ie: I'm declaring an impl of Into<S> that already exists when that crate builds).

It might be helpful to note that with the current way the compiler thinks about things, Into<S> can't be implemented for any S which I don't control (as the only way to implement it is by impl-ing From on S). This rather reduces the flexibility here, and means I'll probably end up just having into() methods that aren't members of trait Into. Perhaps we should have an IntoWithoutDefaults? That seems like an undesirable workaround.

Edit: note, I haven't thought about the above enough to know if it is possible.

Edit2: and just realized that the behavior I'm looking for in the first paragraph is similar in functionality to negative trait bounds.

[brson]

Op compiles successfully today.

[brson]

Just add a test case.

[Mark-Simulacrum]

One of the examples does compile, but the issue was reported about a different example which doesn't. Not E-needstest; not sure that I follow what could change with the diagnostic though.

pub struct GenX<S> {
    inner: S,
}

impl<S> Into<S> for GenX<S> {
    fn into(self) -> S {
        self.inner
    }
}

fn main() {
    println!("HI");
}