Remove unused from_method from rustc_on_unimplemented
Fixes#113439
`on_unimplemented_note` was calling `item_name` for RPITITs and that produced ICEs. I've added a regression test for that but also have removed `from_method` symbol entirely because it wasn't even used and by doing that the `item_name` call was also removed.
r? ``@compiler-errors``
Remove `variances_of` on RPITIT GATs, remove its one use-case
It doesn't make sense to implement variances on a GAT anyways, since we don't relate GATs with variance:
85bf07972a/compiler/rustc_middle/src/ty/relate.rs (L569-L579)
r? ``@spastorino``
Don't ICE in `resolve_bound_vars` when associated return-type bounds are in bad positions
I couldn't find a better way to avoid hitting this ICE, so let's just delay it.
The problem is that we really shouldn't even be *trying* to visit associated type bounds in `resolve_bound_vars` when they show up in impl headers, but we don't have enough context to do this.
Fixes#113423
Split `SelectionContext::select` into fns that take a binder and don't
*most* usages of `SelectionContext::select` don't need to use a binder, but wrap them in a dummy because of the signature. Let's split this out into `SelectionContext::{select,poly_select}` and limit the usages of the latter.
Right now, we only have 3 places where we're calling `poly_select` -- fulfillment, internally within the old solver, and the auto-trait finder.
r? `@lcnr`
Rollup of 8 pull requests
Successful merges:
- #111917 (Simplify duplicate checks for mir validator)
- #112008 (Fix incorrect documented default bufsize in bufreader/writer)
- #112825 (Don't call `type_of` on TAIT in defining scope in new solver)
- #113164 (Add a regression test for #109054)
- #113318 (Revert "alloc: Allow comparing Boxs over different allocators", add regression test)
- #113397 (Prefer object candidates in new selection)
- #113419 (Avoid calling item_name for RPITIT)
- #113421 (Do not assert >1 RPITITs on collect_return_position_impl_trait_in_trait_tys)
r? `@ghost`
`@rustbot` modify labels: rollup
Do not assert >1 RPITITs on collect_return_position_impl_trait_in_trait_tys
Fixes#113403
Assert on collect_return_position_impl_trait_in_trait_tys is not correct when we call it from type_of(GAT). The included test is an example of a situation that collector collects 0 types.
r? `@compiler-errors`
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.
Revert "alloc: Allow comparing Boxs over different allocators", add regression test
Temporary fix for #113283
Adds a test to fix the regression introduced in 001b081cc1 and revert that commit. The test fails without the revert.
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`
Use `llvm-config` instead of `download-ci-llvm` in PGO script
This should avoid CI breakage when the LLVM stamp is updated, and also it will avoid an unnecessary LLVM download from CI.
r? `@jyn514`
