Do not register Self: AutoTrait when confirming auto trait (in old solver)

[compiler-errors]

Every built-in auto impl for a trait goal like Ty: Auto immediately registers another obligation of Ty: Auto as one of its nested obligations, leading to us stressing the cycle detection machinery a lot more than we need to. This is because all traits have a Self: Trait predicate.

To fix this, remove the call to impl_or_trait_obligations in vtable_auto_impl, since auto traits do not have where clauses.

r? lcnr

[compiler-errors]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 3129802 with merge 4e748eada6c10c5cf70f4f463d72c402cedbe007...

[bors]

☀️ Try build successful - checks-actions
Build commit: 4e748ea (4e748eada6c10c5cf70f4f463d72c402cedbe007)

[rust-timer]

Finished benchmarking commit (4e748ea): comparison URL.

Overall result: ✅ improvements - no 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.

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

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.7%	[-5.2%, -0.2%]	23
Improvements ✅ (secondary)	-1.5%	[-4.3%, -0.3%]	4
All ❌✅ (primary)	-1.7%	[-5.2%, -0.2%]	23

Max RSS (memory usage)

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

Cycles

Results (primary -2.4%, secondary -2.8%)

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)	-2.4%	[-3.9%, -1.3%]	8
Improvements ✅ (secondary)	-2.8%	[-3.7%, -1.9%]	2
All ❌✅ (primary)	-2.4%	[-3.9%, -1.3%]	8

Binary size

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

Bootstrap: 765.603s -> 765.667s (0.01%)
Artifact size: 361.95 MiB -> 362.01 MiB (0.02%)

[compiler-errors]

To be very clear, this impl_or_trait_obligations returns a single predicate, which is this one here:

rust/compiler/rustc_hir_analysis/src/collect/predicates_of.rs

Lines 43 to 70 in 446649d

	if tcx.is_trait(def_id) {
	// For traits, add `Self: Trait` predicate. This is
	// not part of the predicates that a user writes, but it
	// is something that one must prove in order to invoke a
	// method or project an associated type.
	//
	// In the chalk setup, this predicate is not part of the
	// "predicates" for a trait item. But it is useful in
	// rustc because if you directly (e.g.) invoke a trait
	// method like `Trait::method(...)`, you must naturally
	// prove that the trait applies to the types that were
	// used, and adding the predicate into this list ensures
	// that this is done.
	//
	// We use a DUMMY_SP here as a way to signal trait bounds that come
	// from the trait itself that *shouldn't* be shown as the source of
	// an obligation and instead be skipped. Otherwise we'd use
	// `tcx.def_span(def_id);`
	let span = DUMMY_SP;
	result.predicates = tcx.arena.alloc_from_iter(
	result
	.predicates
	.iter()
	.copied()
	.chain(std::iter::once((ty::TraitRef::identity(tcx, def_id).upcast(tcx), span))),
	);
	}

Arguably that predicate shouldn't even be in the predicates_of and perhaps should be put into the param_env of traits and trait items... but that seems a lot harder to do.

And we would still need to make sure to add the predicate in when calling methods and stuff.