library: Use size_of from the prelude instead of imported

[thaliaarchi]

Use std::mem::{size_of, size_of_val, align_of, align_of_val} from the prelude instead of importing or qualifying them.

These functions were added to all preludes in Rust 1.80.

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
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

[compiler-errors]

Please revert all the changes to tests. We don't typically "correct" tests for things like this, formatting, etc. It's simply unnecessary churn. Especially unless you want to verify that every test that was changed doesn't implicitly change the meaning or intention of the test that when it was originally committed (e.g. that the test wasn't exercising minutiae of resolver or path semantics or something else).

You also probably should split this out between library, compiler, and changes to the various tools in src/tools. Different parts of the repository are the responsibility of different teams, and right now the review-ability of a 444 file test is really not great.

@rustbot author

[rustbot]

Some changes occurred to the CTFE / Miri interpreter

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

Some changes occurred in src/tools/compiletest

cc @jieyouxu

Some changes occurred in coverage tests.

cc @Zalathar

This PR changes Stable MIR

cc @oli-obk, @celinval, @ouz-a

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

The Miri subtree was changed

cc @rust-lang/miri

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

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

Portable SIMD is developed in its own repository. If possible, consider making this change to rust-lang/portable-simd instead.

cc @calebzulawski, @programmerjake

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

Some changes occurred in const_evaluatable.rs

cc @BoxyUwU

Some changes occurred in tests/ui/sanitizer

cc @rust-lang/project-exploit-mitigations, @rcvalle

[thaliaarchi]

Please revert all the changes to tests.

I've removed changes to files in the following directories:

src/tools/clippy/tests/
src/tools/miri/tests/
src/tools/rustfmt/tests/
tests/

[thaliaarchi]

Roughly by team, the distribution is now:

library/: 124 files
compiler/: 31 files
src/tools/rust-analyzer/: 11 files
src/tools/clippy/: 4 files
src/bootstrap/: 2 files
src/tools/compiletest/: 1 file
src/tools/miri/: 1 file

Unless I'm splitting library/ somehow, compiler/ might not even be worth splitting out. It's just a lot of files. But, I'm open if you have ideas on how to split it well.

[compiler-errors]

By split, I mean there's no reason this needs to happen in a single PR, since it's not like this changes something that needs to be applied concurrently across all the repository in a singular PR. It's just a bunch of changes squashed into one by choice.

The 31 changes in compiler/ can get reviewed and approved by a compiler reviewer separately. Same with library/, which should have a dedicated reviewer, though that likely requires a bunch of CI back and forth with all the platform cfg's that aren't tested locally. What I mean is to split this into several PRs.

This PR also touches several tools that really should have PRs made to their own repositories, like rust-analyzer, rustfmt, etc (pls re-read the rustbot ping list for some of those submodules by name), since this is not a critical change or something that breaks rust-analyzer or rustfmt in CI or anything.

[jieyouxu]

I can review the bootstrap/compiletest bits if you split those out. But the rust-analyzer, rustfmt, clippy changes need (well, really should) to be sent against their own repos since they're subtrees and does not otherwise need compiler changes to minimize subtree sync conflicts.

[thaliaarchi]

I've now split it into several PRs:

• library: Use size_of from the prelude instead of imported #138034
• compiler: Use size_of from the prelude instead of imported #138040
• bootstrap and compiletest: Use size_of_val from the prelude instead of imported #138041
• Use size_of from the prelude instead of imported miri#4219
• Use size_of from the prelude instead of imported rust-analyzer#19288
• Use size_of from the prelude instead of imported rust-clippy#14355

This PR is now only changes to library/. If you'd like me to split it further, perhaps by crate, just let me know.

r? libs

@rustbot review

[thaliaarchi]

I have checked it with x check library on all tier 1 and tier 2 with host tools targets, as well as a few odd targets. Some tier 3 targets fail to build tests for unrelated reasons.

List of targets checked

# Tier 1:
x check library --target=aarch64-apple-darwin
x check library --target=aarch64-unknown-linux-gnu
x check library --target=i686-pc-windows-gnu
x check library --target=i686-pc-windows-msvc
x check library --target=i686-unknown-linux-gnu
x check library --target=x86_64-apple-darwin
x check library --target=x86_64-pc-windows-gnu
x check library --target=x86_64-pc-windows-msvc
x check library --target=x86_64-unknown-linux-gnu

# Tier 2 with host tools:
x check library --target=aarch64-pc-windows-msvc
x check library --target=aarch64-unknown-linux-musl
x check library --target=arm-unknown-linux-gnueabi
x check library --target=arm-unknown-linux-gnueabihf
x check library --target=armv7-unknown-linux-gnueabihf
x check library --target=loongarch64-unknown-linux-gnu
x check library --target=loongarch64-unknown-linux-musl
x check library --target=powerpc-unknown-linux-gnu
x check library --target=powerpc64-unknown-linux-gnu
x check library --target=powerpc64le-unknown-linux-gnu
x check library --target=powerpc64le-unknown-linux-musl
x check library --target=riscv64gc-unknown-linux-gnu
x check library --target=riscv64gc-unknown-linux-musl
x check library --target=s390x-unknown-linux-gnu
x check library --target=x86_64-unknown-freebsd
x check library --target=x86_64-unknown-illumos
x check library --target=x86_64-unknown-linux-musl
x check library --target=x86_64-unknown-netbsd

# Other:
x check library --target=wasm32-wasip1
x check library --target=wasm32-wasip1-threads
x check library --target=wasm32-wasip2
x check library --target=x86_64-fortanix-unknown-sgx

# Fail (but unrelated):
x check library --target=aarch64-kmc-solid_asp3
x check library --target=aarch64-unknown-teeos
x check library --target=riscv32im-risc0-zkvm-elf
x check library --target=riscv32imac-unknown-xous-elf
x check library --target=wasm32-unknown-unknown
x check library --target=x86_64-unknown-hermit
x check library --target=x86_64-unknown-uefi

[tgross35]

Notes from my initial quick pass, mostly use statements that could be removed. Based on CI it seems like there may be other instances that aren't picked up by ./x c library?

[Sky9x]

why does this change some docs to use turbofish syntax? (second commit)

[compiler-errors]

Because it's not valid rust, perhaps?

[thaliaarchi]

why does this change some docs to use turbofish syntax? (second commit)

That was at Jubilee's suggestion: #138034 (comment)

Because it's not valid rust, perhaps?

Exactly

[thaliaarchi]

@tgross35 I've now fixed (what should be) all the now-unnecessary imports for doc tests. Running x check library --doc caught everything you found and some more.

[thaliaarchi]

…and now benches are fixed

[thaliaarchi]

This round caught some tests in library/coretests, which I couldn't check locally with x check library/coretests, because of “can't find crate for std”.

All this CI bouncing isn't really inspiring confidence, so while this run is going, I'll do a manual review of the imports.

[thaliaarchi]

I reviewed every file to check whether a use {std, core, crate}::mem became unused, gated or always, and found a few which weren't uncovered by CI or local testing. I think this covers everything.

I was hoping to wait until the previus CI run finished, but builders weren't picking up the last two jobs, since the tree is currently closed, so I've pushed the fixes I found. But the jobs which actually did run passed, so that's a good sign.