Less as * in library/core

[scottmcm]

cast/cast_const/cast_mut have been stable and const-stable for a while, so let's use them instead of as, for clarity about what the cast is doing and to emphasize as casts doing anything else.

After all, if it had existed back then, using .cast::<T>() instead of as *mut T might have helped catch the soundness bug back in https://blog.rust-lang.org/2017/02/09/Rust-1.15.1.html#whats-in-1151-stable, as the copy-paste wouldn't have compiled (since cast would have given a *const not a *mut).

I'm working on a lint to enforce this in future, which I used to find all these places.

Old zulip conversation about moving things off as where feasible: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Adding.20methods.20as.20more.20specific.20versions.20of.20.60as.60/near/238374585.

[rustbot]

r? @joshtriplett

(rustbot has picked a reviewer for you, use r? to override)

[est31]

Personally I'm not the greatest fan of cast and friends, because the turbofish makes it too easy to just omit the type. With as you at least have to type the _ explicitly and it gives you a bad taste while cast() looks way too beautiful and you know way too little what is going on. The only advantage it has is const correctness which is nice but type confusions are another very big source of bugs in unsafe code. It would be nice to have a lint that warns about using cast without a turbofish, and even better to re-introduce an improved version of the as syntax in a future edition that has safety features added like using Into instead of the unsafe casting that it does now.

[scottmcm]

(Nominated in case libs wants to give their 2¢ on whether this is a desired change for core in the first place.)

[Amanieu]

I have some concerns about performance since this now instantiates a lot of small inline functions.

@bors try @rust-timer queue

[bors]

⌛ Trying commit 6c65e34 with merge e473c2a4f4c5b4fed05b510c8070ac086bcde415...

[scottmcm]

Running perf makes sense.

I'll note that these are all inline(always) to avoid pessimizing debug builds as of #105262

rust/library/core/src/ptr/const_ptr.rs

Lines 107 to 110 in 439292b

	#[inline(always)]
	pub const fn cast_mut(self) -> *mut T {
	self as _
	}

(And hopefully the MIR inliner has already run by the time user code is instantiating anything that calls them.)

[bors]

☀️ Try build successful - checks-actions
Build commit: e473c2a4f4c5b4fed05b510c8070ac086bcde415 (e473c2a4f4c5b4fed05b510c8070ac086bcde415)

[bors]

☀️ Try build successful - checks-actions
Build commit: e473c2a4f4c5b4fed05b510c8070ac086bcde415 (e473c2a4f4c5b4fed05b510c8070ac086bcde415)

[rust-timer]

Finished benchmarking commit (e473c2a4f4c5b4fed05b510c8070ac086bcde415): comparison URL.

Overall result: ❌✅ regressions and improvements - 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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.7%	[0.7%, 0.7%]	1
Improvements ✅ (primary)	-0.8%	[-0.8%, -0.7%]	4
Improvements ✅ (secondary)	-0.6%	[-0.7%, -0.4%]	5
All ❌✅ (primary)	-0.8%	[-0.8%, -0.7%]	4

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)	0.4%	[0.4%, 0.4%]	1
Regressions ❌ (secondary)	1.4%	[0.5%, 3.8%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[0.4%, 0.4%]	1

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.5%	[0.4%, 0.6%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.4%	[-0.4%, -0.4%]	1
All ❌✅ (primary)	-	-	0

[scottmcm]

No primary regressions, overall more improvements than regressions.

@rustbot label: +perf-regression-triaged

[m-ou-se]

(Nominated in case libs wants to give their 2¢ on whether this is a desired change for core in the first place.)

This was discussed last week in the library team meeting. We're all in favor of this change, but a lint for this would be nice, to make sure we avoid adding new as * in the future to keep things consistent.

[scottmcm]

This is just going to bit-rot, so I'll close it until I can get back to a broader thing.