Remove #[inline] from integer Debug impl

[hanna-kruppe]

The dynamic dispatch in core::fmt machinery prevents this code from being inlined in normal usage, but the method is still duplicated into every codegen units that constructs a dyn Debug vtable for integers.

[hanna-kruppe]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: f546fb8 (f546fb80f0d529d80342a65ad7f33975ecd30e49)
Base parent: 5ec56e3 (5ec56e3902656f2460259fc3ac0f6e2255f94417)

[rust-timer]

Finished benchmarking commit (f546fb8): comparison URL.

Overall result: ❌✅ regressions and improvements - 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.6%	[0.2%, 0.8%]	5
Regressions ❌ (secondary)	0.3%	[0.2%, 0.6%]	23
Improvements ✅ (primary)	-0.4%	[-0.7%, -0.2%]	8
Improvements ✅ (secondary)	-0.4%	[-0.4%, -0.4%]	2
All ❌✅ (primary)	-0.0%	[-0.7%, 0.8%]	13

Max RSS (memory usage)

Results (primary -0.6%, secondary 4.8%)

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

	mean	range	count
Regressions ❌ (primary)	1.3%	[1.0%, 1.7%]	2
Regressions ❌ (secondary)	4.8%	[4.5%, 5.1%]	2
Improvements ✅ (primary)	-1.8%	[-2.6%, -1.2%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.6%	[-2.6%, 1.7%]	5

Cycles

Results (primary 3.1%, secondary 20.2%)

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

	mean	range	count
Regressions ❌ (primary)	3.1%	[2.1%, 4.0%]	2
Regressions ❌ (secondary)	20.2%	[18.2%, 23.8%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.1%	[2.1%, 4.0%]	2

Binary size

Results (primary -0.2%, secondary -0.2%)

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

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.1%, 0.1%]	3
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-0.2%	[-0.9%, -0.0%]	136
Improvements ✅ (secondary)	-0.2%	[-0.5%, -0.0%]	119
All ❌✅ (primary)	-0.2%	[-0.9%, 0.1%]	139

Bootstrap: 487.044s -> 489.318s (0.47%)
Artifact size: 406.45 MiB -> 406.48 MiB (0.01%)

[hanna-kruppe]

That's unexpected. Extra weird that most of the regressions are check builds, which shouldn't be affected by this change at all 🤔 All the green is in benchmarks that actually generate code (though there's a few red ones too).

Well at least the binary size results seem confirm my thesis.

[hanna-kruppe]

Ah, this might be #t-compiler/performance > Suspiciously positive results (noise in get_module_children) yet again :/