make std::intrinsics functions actually be intrinsics

[RalfJung]

Most of the functions in std::intrinsics are actually intrinsics, but some are not: for historical reasons, std::intrinsics::{copy,copy_nonoverlapping,write_bytes} are accessible on stable, and the versions in std::ptr are just re-exports. These functions are not intrinsics, but wrappers around the intrinsic, because they add extra debug assertions.

This PR makes the functions in std::intrinsics actually be intrinsics.

• The advantage is that we can now use it in tests that need to directly call the intrinsic, thus removing a footgun for compiler development. We also remove the extended user-facing doc comments of these functions out of a file that should be largely internal documentation.
• The downside is that if users are using those functions directly, they will not get the debug assertions any more. Note however that those users are already ignoring a deprecation warning, so I think this is fine. Furthermore, if someone imports the intrinsic name of this function and turns that into a function pointer, that will no longer work, since only the wrapper functions can be turned into a function pointer. I would be rather surprised if anyone did this, though... and again, they must have already ignored a deprecation warning. Still, seems worth a crater run, if there's general agreement that we want to go ahead with this change.

(intrinsics::drop_in_place also remains not-an-intrinsic, which bugs me, but oh well, not much we can do about it; we can't remove it from the module as the path is accidentally-stable.)

Cc @rust-lang/libs-api @saethlin

[rustbot]

r? @Mark-Simulacrum

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

[rustbot]

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

The Miri subtree was changed

cc @rust-lang/miri

[jhpratt]

(intrinsics::drop_in_place also remains not-an-intrinsic, which bugs me, but oh well, not much we can do about it; we can't remove it from the module as the path is accidentally-stable.)

I'd be interested in seeing a crater run on that, to be honest. We've pulled the rug on things that were accidentally stabilized before, even long after the fact.

[Mark-Simulacrum]

r=me with test confirmed to be adjusted as expected

[RalfJung]

Since this is a slight breaking change (of accidentally-stable API surface), does it need an FCP of some sort -- from @rust-lang/libs-api, I assume?

[Amanieu]

FCP since this is very slightly breaking, though unlikely to cause any issues in practice.

@rfcbot merge

[rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[RalfJung]

@bors try

[bors]

⌛ Trying commit 5d60226 with merge b8c67c6...

[bors]

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

[bors]

📌 Commit 5d60226 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[bors]

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

1. git checkout intrinsic-wrappers (switch to your branch)
2. git fetch upstream master (retrieve the latest master)
3. git rebase upstream/master -p (rebase on top of it)
4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
5. git push self intrinsic-wrappers --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

Auto-merging tests/ui/consts/missing_span_in_backtrace.stderr Auto-merging tests/ui/consts/copy-intrinsic.stderr Auto-merging tests/ui/consts/copy-intrinsic.rs Auto-merging tests/ui/consts/const-eval/raw-pointer-ub.stderr Auto-merging tests/ui/consts/const-eval/raw-pointer-ub.rs Auto-merging library/core/src/ptr/mod.rs Auto-merging library/core/src/intrinsics/mod.rs CONFLICT (content): Merge conflict in library/core/src/intrinsics/mod.rs Automatic merge failed; fix conflicts and then commit the result. 

[RalfJung]

@bors r=Mark-Simulacrum

[bors]

📌 Commit a29756d has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[bors]

⌛ Testing commit a29756d with merge f8e9e76...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing f8e9e76 to master...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing a8e4c68 (parent) -> f8e9e76 (this PR)

Test differences

Show 404 test diffs

404 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \ test-dashboard f8e9e7636aabcbc29345d9614432d15b3c0c4ec7 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. x86_64-apple-1: 8379.4s -> 6780.8s (-19.1%)
2. x86_64-msvc-ext2: 5673.9s -> 6649.6s (17.2%)
3. x86_64-msvc-1: 9994.1s -> 8343.2s (-16.5%)
4. dist-aarch64-apple: 5276.9s -> 5937.4s (12.5%)
5. dist-apple-various: 7229.0s -> 7975.2s (10.3%)
6. aarch64-apple: 4704.3s -> 4340.6s (-7.7%)
7. dist-android: 2724.3s -> 2560.2s (-6.0%)
8. dist-powerpc-linux: 5157.0s -> 5455.3s (5.8%)
9. dist-ohos-armv7: 4243.4s -> 4478.0s (5.5%)
10. dist-x86_64-msvc-alt: 8029.8s -> 7586.5s (-5.5%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (f8e9e76): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

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

Max RSS (memory usage)

Results (primary 0.6%, secondary 0.1%)

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)	2.9%	[0.7%, 4.5%]	4
Regressions ❌ (secondary)	5.5%	[5.5%, 5.5%]	1
Improvements ✅ (primary)	-2.5%	[-3.5%, -1.6%]	3
Improvements ✅ (secondary)	-0.8%	[-2.5%, -0.4%]	6
All ❌✅ (primary)	0.6%	[-3.5%, 4.5%]	7

Cycles

Results (secondary -0.7%)

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)	-0.7%	[-0.8%, -0.6%]	3
All ❌✅ (primary)	-	-	0

Binary size

Results (primary -0.1%)

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

Bootstrap: 776.444s -> 775.927s (-0.07%)
Artifact size: 365.63 MiB -> 365.55 MiB (-0.02%)