Add more debug assertions to unsafe functions

[pitaj]

related to #51713

[rustbot]

r? @m-ou-se

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

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[saethlin]

FYI, in #92686 I deliberately avoided adding assertions to some functions because their preconditions were shared with a callee. It's quite possible this decision has aged poorly.

[pitaj]

I'm having trouble reproducing the CI failure locally. What config and command do I need to run to emulate the CI run? I've tried the library, compiler, and codegen profiles (with llvm download) with and without incremental. I've tried ./x.py build and ./x.py build --stage 2 but haven't seen that panic.

[pitaj]

Actually, on second look, it appears the Arc/Rc debug assertions would be too strict, so I've reverted that change.

[saethlin]

./x.py test --stage 0 library/std is probably what you want to see a test failure. I don't think you can run the tests for the whole library? But also ./x.py test if you have patience will build the library and compiler and run a much larger test suite, which is often good for finding these corner cases.

[pitaj]

I deliberately avoided adding assertions to some functions because their preconditions were shared with a callee.

Are you referring to anything in particular in this PR?

[saethlin]

No, I'm just offering a potential explanation of why some of the unsafe fn you found didn't have any. My initial approach was probably not resilient with regard to refactoring, thank you for your work improving the situation.

[pitaj]

FYI for anyone coming to this: I have removed the problematic assertions previously discussed.

Now this PR only adds a bounds check to str::get_unchecked(_mut) and slice::split_at_unchecked. There was a refactor of various SliceIndex<str> impls to limit duplication of the checks.

[the8472]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 09f8885 with merge d2d06001a083c00f1d66b9dcdf0e98f128499dc0...

[the8472]

@rust-timer build d2d06001a083c00f1d66b9dcdf0e98f128499dc0

[rust-timer]

Finished benchmarking commit (d2d06001a083c00f1d66b9dcdf0e98f128499dc0): comparison URL.

Overall result: ✅ improvements - no 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.

@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
Improvements ✅ (primary)	-1.1%	[-1.2%, -1.0%]	2
Improvements ✅ (secondary)	-2.2%	[-2.6%, -2.0%]	6
All ❌✅ (primary)	-1.1%	[-1.2%, -1.0%]	2

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

Cycles

This benchmark run did not return any relevant results for this metric.

[the8472]

@bors r+

[bors]

📌 Commit cd35794 has been approved by the8472

It is now in the queue for this repository.

[bors]

⌛ Testing commit cd35794 with merge 7820b62...

[bors]

☀️ Test successful - checks-actions
Approved by: the8472
Pushing 7820b62 to master...

[rust-timer]

Finished benchmarking commit (7820b62): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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)	1.0%	[0.9%, 1.1%]	2
Regressions ❌ (secondary)	2.3%	[2.0%, 2.7%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.0%	[0.9%, 1.1%]	2

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

Cycles

This benchmark run did not return any relevant results for this metric.

[the8472]

Previous perf run looked good and those benchmarks are bimodal.

@rustbot label: +perf-regression-triaged