check WF of HRTB args even if there are escaping bound vars

[sjwang05]

We previously retained only Terms that didn't have escaping bound vars when collecting WF obligations, leading us to wrongly accepting code like this:

trait Bound {}

struct W<'a, T: Bound>(&'a T);

fn wf<T>() where for<'a> W<'a, T>: Sized {}

as T: Bound does not hold in wf's where-clauses. Immediately turning this into a hard error caused substantial crater breakage (#122501), so for now we collect these kinds of obligations separately and prove them in a forked param env, emitting an FCW if the proof fails and there are no other errors from wfchecking.

cc https://rust-lang.zulipchat.com/#narrow/channel/618216-t-types.2Fcall-for-participation/topic/check.20WF.20of.20trait.20args.20even.20with.20escaping.20bound.20vars/with/621059871
cc #162200

[rustbot]

changes to the core type system

cc @lcnr

[rustbot]

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 75 candidates
• Random selection from 20 candidates

[sjwang05]

I'm a bit unhappy with how messy the diag formatting code here is, but I couldn't think of a better way 🤔

View changes since the review

[sjwang05]

A bit concerned about perf since this runs on the Ok paths, even though we have the fcw_obligations.is_empty check, and I don't expect to encounter such obligations in practice very much

View changes since the review

[lcnr]

@bors try @rust-timer queue

can you change the FCW to also point to the self-type when applicable, rn the diagnostic is kinda meh

[rust-bors]

☀️ Try build successful (CI)
Build commit: 147db73 (147db73b7d06617e530e16c926faf196f536caa4)
Base parent: 745de6e (745de6eca673de5329ec68f2689629a5ca45ab35)

[rust-timer]

Finished benchmarking commit (147db73): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.1%, 0.6%]	38
Regressions ❌ (secondary)	0.4%	[0.2%, 0.9%]	27
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.1%, 0.6%]	38

Max RSS (memory usage)

Results (primary 0.4%, secondary -2.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.4%, 0.7%]	6
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.4%	[-0.4%, -0.4%]	1
Improvements ✅ (secondary)	-2.7%	[-2.7%, -2.7%]	1
All ❌✅ (primary)	0.4%	[-0.4%, 0.7%]	7

Cycles

Results (primary 0.1%, secondary 0.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.8%	[0.4%, 2.0%]	8
Regressions ❌ (secondary)	4.6%	[4.6%, 4.6%]	1
Improvements ✅ (primary)	-0.8%	[-1.1%, -0.6%]	6
Improvements ✅ (secondary)	-3.7%	[-3.7%, -3.7%]	1
All ❌✅ (primary)	0.1%	[-1.1%, 2.0%]	14

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 478.441s -> 478.264s (-0.04%)
Artifact size: 403.53 MiB -> 403.70 MiB (0.04%)