Rework upcasting confirmation to support upcasting to fewer projections in target bounds

[compiler-errors]

This PR implements a modified trait upcasting algorithm that is resilient to changes in the number of associated types in the bounds of the source and target trait objects.

It does this by equating each bound of the target trait ref individually against the bounds of the source trait ref, rather than doing them all together by constructing a new trait object.

The new way we do trait upcasting confirmation

1. Equate the target trait object's principal trait ref with one of the supertraits of the source trait object's principal.
   https://github.com/rust-lang/rust/blob/fdcab310b2a57a4e9cc0b2629abd27afda49cd80/compiler/rustc_trait_selection/src/traits/select/mod.rs#L2509-L2525

2. Make sure that every auto trait in the target trait object is present in the source trait ref's bounds.
   https://github.com/rust-lang/rust/blob/fdcab310b2a57a4e9cc0b2629abd27afda49cd80/compiler/rustc_trait_selection/src/traits/select/mod.rs#L2559-L2562

3. For each projection in the target trait object, make sure there is exactly one projection that equates with it in the source trait ref's bound. If there is more than one, bail with ambiguity.
   https://github.com/rust-lang/rust/blob/fdcab310b2a57a4e9cc0b2629abd27afda49cd80/compiler/rustc_trait_selection/src/traits/select/mod.rs#L2526-L2557

   • Since there may be more than one that applies, we probe first to check that there is exactly one, then we equate it outside of a probe once we know that it's unique.

4. Make sure the lifetime of the source trait object outlives the lifetime of the target.

Meanwhile, this is how we used to do upcasting:

1. For each supertrait of the source trait object, take that supertrait, append the source object's projection bounds, and the target trait object's auto trait bounds, and make this into a new object type:
   

   rust/compiler/rustc_trait_selection/src/traits/select/confirmation.rs

   Lines 915 to 929 in d12c6e9

   	let iter = Some(existential_predicate)
   	.into_iter()
   	.chain(
   	data_a
   	.projection_bounds()
   	.map(|b| b.map_bound(ty::ExistentialPredicate::Projection)),
   	)
   	.chain(
   	data_b
   	.auto_traits()
   	.map(ty::ExistentialPredicate::AutoTrait)
   	.map(ty::Binder::dummy),
   	);
   	let existential_predicates = tcx.mk_poly_existential_predicates_from_iter(iter);
   	let source_trait = Ty::new_dynamic(tcx, existential_predicates, r_b, repr_a);

2. Then equate it with the target trait object:
   

   rust/compiler/rustc_trait_selection/src/traits/select/confirmation.rs

   Line 936 in d12c6e9

   .sup(DefineOpaqueTypes::No, target, source_trait)

This will be a type mismatch if the target trait object has fewer projection bounds, since we compare the bounds structurally in relate:

rust/compiler/rustc_middle/src/ty/relate.rs

Lines 696 to 698 in d12c6e9

	if a_v.len() != b_v.len() {
	return Err(TypeError::ExistentialMismatch(expected_found(relation, a, b)));
	}

Fixes #114035
Also fixes #114113, because I added a normalize call in the old solver.

r? types

[rustbot]

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

[lcnr]

a bunch of somewhat involved cleanup suggestions

[bors]

☔ The latest upstream changes (presumably #113393) made this pull request unmergeable. Please resolve the merge conflicts.

[compiler-errors]

@bors try @rust-timer queueu

[compiler-errors]

@rust-timer queue

[bors]

⌛ Trying commit e6b5a9db9b20cb1ec59a08de9252c15eea250968 with merge 0a272aa2cb590369372a550e471024d5c98edccc...

[compiler-errors]

Let's try perf one more time. This new code path actually shouldn't ever be hit without trait upcasting -- dyn Tr + 'a => dyn Tr + 'b should go thru a separate codepath.

@bors try @rust-timer queue

[bors]

⌛ Trying commit 7c942cc with merge c6d58f5a53b24b41706d35d7118db315a699da6e...

[bors]

☀️ Try build successful - checks-actions
Build commit: c6d58f5a53b24b41706d35d7118db315a699da6e (c6d58f5a53b24b41706d35d7118db315a699da6e)

[rust-timer]

Finished benchmarking commit (c6d58f5a53b24b41706d35d7118db315a699da6e): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.4%	[0.3%, 0.5%]	4
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[0.3%, 0.5%]	4

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	4.8%	[4.8%, 4.8%]	1
Regressions ❌ (secondary)	1.9%	[1.5%, 2.3%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	4.8%	[4.8%, 4.8%]	1

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.9%	[0.9%, 0.9%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.2%	[-2.2%, -2.2%]	1
All ❌✅ (primary)	0.9%	[0.9%, 0.9%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 649.462s -> 649.886s (0.07%)

[lcnr]

This regression is small and affects just a single crate. The actual changes here pretty much exclusively affect unstable code so this feels like it may be noise.

I believe this to be some inlining change and don't think it's worth it to look deeper into it.

@bors r+ rollup=never

[bors]

📌 Commit 7c942cc has been approved by lcnr

It is now in the queue for this repository.

[bors]

⌛ Testing commit 7c942cc with merge 4f7bb98...

[bors]

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

[rust-timer]

Finished benchmarking commit (4f7bb98): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.3%, 0.3%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.3%, 0.3%]	1

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	4.4%	[4.4%, 4.5%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	1
All ❌✅ (primary)	4.4%	[4.4%, 4.5%]	2

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.0%	[-2.0%, -2.0%]	1
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 647.543s -> 647.162s (-0.06%)