Cleanup: Replace item names referencing GitHub issues or error codes with something more meaningful

[fmease]

lcnr in #117164 (review):

[…] while I know that there's precendent to name things Issue69420, I really dislike this as it requires looking up the issue to figure out the purpose of such a variant. Actually referring to the underlying issue, e.g. AliasMayNormToUncovered or whatever and then linking to the issue in a doc comment feels a lot more desirable to me. We should ideally rename all the functions and enums which currently use issue numbers.

I've grepped through compiler/ like crazy and think that I've found all instances of this pattern.
However, I haven't renamed compute_2229_migrations_*. Should I?

The first commit introduces an abhorrent and super long name for an item because naming is hard but also scary looking / unwelcoming names are good for things related to temporary-ish backcompat hacks. I'll let you discover it by yourself.

Contains a bit of drive-by cleanup and a diag migration bc that was the simplest option.

r? lcnr or compiler

[rustbot]

Some changes occurred in match checking

cc @Nadrieril

[lcnr]

r=me after nits

thanks ❤️

[lcnr]

Suggested change

	query self_ty_of_trait_impl_enabling_order_dep_trait_object_exploit(
	query self_ty_of_trait_impl_enabling_order_dep_trait_object_hack(

I think exploit is not a good fithere 🤔

[lcnr]

Suggested change

	#[instrument(level = "debug", skip_all)]
	fn self_ty_of_trait_impl_enabling_order_dep_trait_object_exploit(
	tcx:TyCtxt<'_>,
	def_id:DefId,
	) -> Option<EarlyBinder<Ty<'_>>> {
	debug!(?def_id);
	#[instrument(level = "debug", skip(tcx))]
	fn self_ty_of_trait_impl_enabling_order_dep_trait_object_exploit(
	tcx:TyCtxt<'_>,
	def_id:DefId,
	) -> Option<EarlyBinder<Ty<'_>>> {

was there a reason you didn't do this?

[fmease]

Yeah, I did that intentionally. There's a minor difference. If I just add it to the tracing span via #[instrument], the DefId doesn't get logged right away but only together with each debug! (and for context it wouldn't get logged at all if we didn't reach any debug! which won't be the case here).

I'm gonna check the actual output later since my knowledge is based on experiments I did in the past with the default tracing_subscriber setup and see how it actually fares in practice.

[fmease]

Output with #[instrument(skip_all)] & debug!(?def_id):

│ │ │ ├─┐rustc_ty_utils::ty::self_ty_of_trait_impl_enabling_order_dep_trait_object_hack │ │ │ │ ├─ 0ms DEBUG rustc_ty_utils::ty def_id=DefId(0:5 ~ lint_incoherent_auto_trait_objects[0a81]::{impl#1})
│ │ │ │ ├─ 0ms DEBUG rustc_ty_utils::ty trait_ref=<(dyn std::marker::Send + 'static) as Foo>
│ │ │ │ ├─ 0ms DEBUG rustc_ty_utils::ty MATCHES!
│ │ │ ├─┘

Output with #[instrument(skip(tcx)] & no debug call:

│ │ │ ├─┐rustc_ty_utils::ty::self_ty_of_trait_impl_enabling_order_dep_trait_object_hack def_id=DefId(0:5 ~ lint_incoherent_auto_trait_objects[0a81]::{impl#1})
│ │ │ │ ├─ 0ms DEBUG rustc_ty_utils::ty trait_ref=<(dyn std::marker::Send + 'static) as Foo>
│ │ │ │ ├─ 0ms DEBUG rustc_ty_utils::ty MATCHES!
│ │ │ ├─┘

Yeah, okay, in this case it doesn't matter. Taking your suggested approach.

[fmease]

@bors r=lcnr rollup

[bors]

📌 Commit 2a1d748 has been approved by lcnr

It is now in the queue for this repository.

[bors]

⌛ Testing commit 2a1d748 with merge f5355b9...

[bors]

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

[rust-timer]

Finished benchmarking commit (f5355b9): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

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)	1.7%	[1.0%, 2.3%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.7%	[1.0%, 2.3%]	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)	-1.3%	[-1.3%, -1.3%]	1
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 673.884s -> 672.879s (-0.15%)
Artifact size: 316.00 MiB -> 315.99 MiB (-0.00%)