Check predicates from blanket trait impls while testing if they apply

[Nemo157]

fixes #78673

[rust-highfive]

r? @ollie27

(rust_highfive has picked a reviewer for you, use r? to override)

[Nemo157]

I've built the std docs before and after this change and diffed them, this results in these impls disappearing:

• std::collections::BinaryHeap (and all other collections, Option, Result, mpsc::Receiver)

   impl<I> IntoIterator for I where I: Iterator

• std::ffi::CStr (and OsStr, Path, slice, str):

  impl<T> ToOwned for T where T: Clone

• char:

  impl<'a, F> Pattern<'a> for F where F: FnMut(char) -> bool

These all seem correct, so this isn't excluding any impls from std that shouldn't have been excluded.

[jyn514]

r? @lcnr

The rustdoc side of this looks fine, is the way Nemo is using evaluate_obligation going to cause ICEs?

[lcnr]

I don't expect it to cause any ICE, though why do we drop the obligations from eq in line 59?

What happens if we try to evaluate them instead of the impl predicates? I guess cc @eddyb

[jyn514]

why do we drop the obligations from eq in line 59?

I'm not sure, but since that's pre-existing does it need to block this change?

[Nemo157]

why do we drop the obligations from eq in line 59?

That being wrong was my first suspicion too, but during my testing those obligations were always empty 🤷.

[lcnr]

hmm, though a bit about this and it definitely makes sense to me.

@bors r+

about the obligations of the eq, afaict we try to equate ?0 = Foo<?T, ?U> which can fail if there are obligations on ?0 but probably just doesn't add any new obligations, so that might be fine. Would be interesting to assert that obligations is always empty in a followup PR to see where my thinking is incorrect 🤔 @Nemo157 do you have the time and are interested to try this out?

[bors]

📌 Commit 0e2af5c has been approved by lcnr

[bors]

⌛ Testing commit 0e2af5c with merge b63d05a...

[bors]

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing b63d05a to master...