Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Auto merge of rust-lang#112875 - compiler-errors:negative-coherence-r…
…ework, r=lcnr Rework negative coherence to properly consider impls that only partly overlap This PR implements a modified negative coherence that handles impls that only have partial overlap. It does this by: 1. taking both impl trait refs, instantiating them with infer vars 2. equating both trait refs 3. taking the equated trait ref (which represents the two impls' intersection), and resolving any vars 4. plugging all remaining infer vars with placeholder types these placeholder-plugged trait refs can then be used normally with the new trait solver, since we no longer have to worry about the issue with infer vars in param-envs. We use the **new trait solver** to reason correctly about unnormalized trait refs (due to deferred projection equality), since this avoid having to normalize anything under param-envs with infer vars in them. This PR then additionally: * removes the `FnPtr` knowable hack by implementing proper negative `FnPtr` trait bounds for rigid types. --- An example: Consider these two partially overlapping impls: ``` impl<T, U> PartialEq<&U> for &T where T: PartialEq<U> {} impl<F> PartialEq<F> for F where F: FnPtr {} ``` Under the old algorithm, we would take one of these impls and replace it with infer vars, then try unifying it with the other impl under identity substitutions. This is not possible in either direction, since it either sets `T = U`, or tries to equate `F = &?0`. Under the new algorithm, we try to unify `?0: PartialEq<?0>` with `&?1: PartialEq<&?2>`. This gives us `?0 = &?1 = &?2` and thus `?1 = ?2`. The intersection of these two trait refs therefore looks like: `&?1: PartialEq<&?1>`. After plugging this with placeholders, we get a trait ref that looks like `&!0: PartialEq<&!0>`, with the first impl having substs `?T = ?U = !0` and the second having substs `?F = &!0`[^1]. Then we can take the param-env from the first impl, and try to prove the negated where clause of the second. We know that `&!0: !FnPtr` never holds, since it's a rigid type that is also not a fn ptr, we successfully detect that these impls may never overlap. [^1]: For the purposes of this example, I just ignored lifetimes, since it doesn't really matter.
- Loading branch information