Signed-off-by: Yuki Okushi <jtitor@2k36.org>

…li-obk

Simplify duplicate checks for mir validator

This removes unnecessary allocations & is less code.

Fix incorrect documented default bufsize in bufreader/writer

…e, r=lcnr

Don't call `type_of` on TAIT in defining scope in new solver

It's *never* productive to call `consider_auto_trait_candidate` on a TAIT in the defining scope, since it will always lead to a query cycle since we call `type_of` on the TAIT. So let's just don't.

I've reserved this behavior just to `SolverMode::Normal` just to avoid any future problems, since this is *technically* incomplete since we're discarding a candidate that could *theoretically* apply. But given such candidate assembly *always* leads to a query cycle, I think it's relatively low risk, and I could be convinced otherwise and make this apply to both solver mode. I assume it's far less likely to be encountered in coherence, though.

This is much more likely to encounter in the new solver, though it can also be encountered in the old solver too, so I'm happy to discuss whether this new behavior we even want in the first place...

I encountered this in a couple of failing UI tests:
* `tests/ui/type-alias-impl-trait/issue-62000-associate-impl-trait-lifetimes.rs`
* `tests/ui/type-alias-impl-trait/issue-93411.rs`

r? `@lcnr`

…-errors

Add a regression test for rust-lang#109054

Closes rust-lang#109054
r? `@compiler-errors`

…new-solver, r=lcnr

Reveal opaques in new solver

We were testing against the wrong reveal mode 😨

Also a couple of misc commits that I don't want to really put in separate prs

r? `@lcnr`

…obj, r=lcnr

Prefer object candidates in new selection

`dyn Any` shouldn't be using [this implementation](https://doc.rust-lang.org/std/any/trait.Any.html#impl-Any-for-T) during codegen.

Prefer object candidates over other candidates, except for other object candidates.