fix negative impls inference

[lcnr]

fixes #74383

r? @nikomatsakis @matthewjasper

[lcnr]

So we end up here if we have exactly one impl candidate which is negative.

We only have a negative impl for Foo<()> here, while the self type is actually more generic (Foo<_>).
So if Send is an auto trait we should return ambiguous in this case, as Foo can still implement Send, e.g. Foo<u8>.

I don't know how we can detect that the impl is at least as general as the current self type rn though, need some help for this. (I don't think I have to write a new type relation for this 🤔 )

[nikomatsakis]

Ah, interesting.

[nikomatsakis]

So actually I'm not sure there is a bug here. There has been a long-standing debate about the correct semantics of auto traits in the face of negative impls, but the current semantics (not, perhaps 100% settled) is that

• If the user writes ANY explicit impl, positive or negative, then the compiler generates NO automatic impl

This was perhaps to be paired with disallowing negative impls that were overly narrow, such as !Foo for Bar<()>.

So in this case, writing impl !Send for Bar<()> (for example) would mean that the compiler does not add an automatic Send for Bar impl at all.

It's debatable what's more intuitive. I personally prefer the current rules -- I would prefer that if you write anything explicit, you must write everything explicit. But also this avoids having a setup (which specialization/coherence currently do not permit) where you have a "base impl" that accepts lots of things and then "negative impls" that cut out "exceptions" where that base impl no longer applies.

In other words, given specialization (and auto traits as currently implemented and specified), if you know that a "base impl" applies, you know that the trait is implemented, and no specialization can make that "untrue".

[lcnr]

hmm, I think this makes sense 🤔

disallowing negative impls that were overly narrow, such as !Foo for Bar<()>.

While negative impls are still unstable, this seems like a restriction we should probably enforce automatically.

Quite interestingly (or much rather, a logical consequence of how this is implemented rn), we can currently "fix" this inference issue by adding another nonsensical impl:

#![feature(negative_impls)]

struct Foo<T>(T);

struct IDontCare;

impl !Send for Foo<()> {}
unsafe impl Send for Foo<IDontCare> {}

fn test<T>() -> T where Foo<T>: Send { todo!() }

fn main() {
    let _: u8 = test();
}

I would love to use this to forbid calling array_chunks::<0>() in #74373 until we implement const where bounds,
but that may stop us from fixing negative impls (as we now need the broken version in std, even if only for an unstable method).

[nikomatsakis]

While negative impls are still unstable, this seems like a restriction we should probably enforce automatically.

these has been an open bug on this forever -- well, no, it's the first checkbox on #13231. It'd be easy enough to do, we can use the same code we use for Drop impls.

[lcnr]

thanks, might look into this in the following weeks 🤔 let's see how much time I have for this.