Prefer T::SIZE over size_of::<T>() in core

[Lars-Schumann]

Some context: #t-libs > Make more use of `SizedTypeProperties`

This only touches core and only changes size_of::<_>() -> _::SIZE to keep the scope manageable.

The motivation is mainly possible compile time wins and it's slightly more readable.

Since these were done mostly programmatically I will go over all changes again to make sure they are semantic no-ops and that no public docs were affected.

[hanna-kruppe]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 6261a9a (6261a9af143fa3d0be4e3bec0d53bb7fceb13bc6)
Base parent: da86f4d (da86f4d0726be475afbbffe40cb2f65741c51ad3)

[rust-timer]

Finished benchmarking commit (6261a9a): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@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
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 1.8%, secondary 2.1%)

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

	mean	range	count
Regressions ❌ (primary)	5.6%	[5.6%, 5.6%]	1
Regressions ❌ (secondary)	4.4%	[2.3%, 6.4%]	2
Improvements ✅ (primary)	-2.0%	[-2.0%, -2.0%]	1
Improvements ✅ (secondary)	-2.4%	[-2.4%, -2.4%]	1
All ❌✅ (primary)	1.8%	[-2.0%, 5.6%]	2

Cycles

Results (secondary -3.4%)

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

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

Binary size

Results (primary -0.0%, secondary -0.1%)

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

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.0%	[-0.1%, -0.0%]	2
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.0%]	3
All ❌✅ (primary)	-0.0%	[-0.1%, -0.0%]	2

Bootstrap: 489.287s -> 487.746s (-0.31%)
Artifact size: 387.73 MiB -> 387.66 MiB (-0.02%)

[rustbot]

Some changes occurred in float parsing

cc @tgross35

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred in integer formatting

cc @tgross35

[rustbot]

r? @JohnTitor

rustbot has assigned @JohnTitor.
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: libs
• libs expanded to 12 candidates
• Random selection from Darksonn, JohnTitor, Mark-Simulacrum, clarfonthey, jhpratt

[Lars-Schumann]

r? @workingjubilee
Perf numbers seem fine, although I don't actually know if these changes would have any effect on the benchmarks.

[rustbot]

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

[clarfonthey]

r? clarfonthey

Since there appears to be a perf improvement, and there wasn't really any objection to doing this, I think we can just call this okay.

@bors r+ rollup=iffy Modifies several different files, so, prone to merge conflicts.

[rust-bors]

📌 Commit 95236c6 has been approved by clarfonthey

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.

Reason for tree closure: spurious failures

[clarfonthey]

@bors r-

Gonna preemptively cancel just because this isn't necessarily a big win. My thought process was that because this could have any performance impact, it would be nice to make them prevalent enough for people to know about them, but that is a kind of weak argument. Will wait for more discussion on Zulip.

[rust-bors]

This pull request was unapproved.

View changes since this unapproval

[Lars-Schumann]

Yeah, given that the perf wins aren't really significant and that this would be quite some churn, I'll close the PR.