Remove string content from panics by ConradIrwin · Pull Request #153677 · rust-lang/rust

ConradIrwin · 2026-03-10T22:39:31Z

String content can be useful for debugging panics, particularly when you are working on a small codebase where you can infer more about the path taken through your program based on the content of the string.

In production deployments that upload crashes for centralized debugging, string content poses a risk to user privacy. The string can accidentally contain information that the user is not expecting to share with the development team.

On balance it seems like the risks outweigh the benefits. It is easy to add a dbg!() statement to gather more information in development; but comparatively tricky to ensure panics are sanitized by every rust app that monitors their production deployments.

Ref https://internals.rust-lang.org/t/stop-including-string-content-in-index-panics/24067

r? @scottmcm

TKanX · 2026-03-11T01:50:24Z

library/core/src/wtf8.rs


-/// Copied from core::str::raw::slice_error_fail
 #[inline(never)]
 fn slice_error_fail(s: &Wtf8, begin: usize, end: usize) -> ! {


warning: unused variable: `s` --> library/core/src/wtf8.rs:488:21 | 488 | fn slice_error_fail(s: &Wtf8, begin: usize, end: usize) -> ! { | ^ help: if this is intentional, prefix it with an underscore: `_s`

@ConradIrwin

library/core/src/wtf8.rs

            // SAFETY: is_code_point_boundary checks that the index is valid
            unsafe { slice_unchecked(self, range.start, range.end) }
        } else {
            slice_error_fail(self, range.start, range.end)


library/core/src/wtf8.rs

            // SAFETY: is_code_point_boundary checks that the index is valid
            unsafe { slice_unchecked(self, range.start, self.len()) }
        } else {
            slice_error_fail(self, range.start, self.len())


library/core/src/wtf8.rs

            // SAFETY: is_code_point_boundary checks that the index is valid
            unsafe { slice_unchecked(self, 0, range.end) }
        } else {
            slice_error_fail(self, 0, range.end)


String content can be useful for debugging panics, particularly when you are working on a small codebase where you can infer more about the path taken through your program based on the content of the string. In production deployments that upload crashes for centralized debugging, string content poses a risk to user privacy. The string can accidentally contain information that the user is not expecting to share with the development team. On balance it seems like the risks outweigh the benefits. It is easy to add a `dbg!()` statement to gather more information in development; but comparatively tricky to ensure panics are sanitized by every rust app that monitors their production deployments. Ref https://internals.rust-lang.org/t/stop-including-string-content-in-index-panics/24067

library/core/src/wtf8.rs

 #[inline(never)]
 fn slice_error_fail(s: &Wtf8, begin: usize, end: usize) -> ! {
-    assert!(begin <= end);
-    panic!("index {begin} and/or {end} in `{s:?}` do not lie on character boundary");
+    let len = s.len();
+    if end > len {
+        panic!("end byte index {end} is out of bounds for string of length {len}");
+    }
+    if begin > end {
+        panic!("byte range starts at {begin} but ends at {end}");
+    }
+    if !s.is_code_point_boundary(begin) {
+        panic!("byte index {begin} is not a code point boundary");
+    }
+    panic!("byte index {end} is not a code point boundary");
 }


TKanX · 2026-03-11T02:31:10Z

The job aarch64-gnu-llvm-20-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

Executing "/scripts/stage_2_test_set1.sh"
+ /scripts/stage_2_test_set1.sh
PR_CI_JOB set; skipping tidy
+ '[' 1 == 1 ']'
+ echo 'PR_CI_JOB set; skipping tidy'
+ SKIP_TIDY='--skip tidy'
+ ../x.py --stage 2 test --skip tidy --skip compiler --skip src
##[group]Building bootstrap
    Finished `dev` profile [unoptimized] target(s) in 0.04s
##[endgroup]
downloading https://static.rust-lang.org/dist/2026-03-05/rustfmt-nightly-aarch64-unknown-linux-gnu.tar.xz
---
Saved the actual run.stderr to `/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/intrinsics/const-eval-select-backtrace-std/const-eval-select-backtrace-std.run.stderr`
diff of run.stderr:

1 
2 thread 'main' ($TID) panicked at $DIR/const-eval-select-backtrace-std.rs:6:8:
- start byte index 1 is out of bounds of ``
+ start byte index 1 is out of bounds for string of length 0
4 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
5 


The actual run.stderr differed from the expected run.stderr

@ConradIrwin use --bless

String panics are unfortunately common at Zed, and doubly unfortunately they may incidentally include the contents of a user's buffer. Although this hasn't happened yet (to my knowledge), I don't want to be in the position of having received sensitive information this way. See also rust-lang/rust#153677

Co-authored-by: TKanX <124454788+TKanX@users.noreply.github.com>

String panics are a non-trivial percentage of the crashes we see at Zed, and doubly unfortunately they may incidentally include the contents of a user's buffer. Although this hasn't happened yet (to my knowledge), I don't want to be in the position of having received sensitive information this way. See also rust-lang/rust#153677 Release Notes: - N/A

ConradIrwin · 2026-03-11T03:16:13Z

Thanks @TKanX!

scottmcm · 2026-03-11T03:39:54Z

Hello libs and libs-api folks! Not sure which team would be responsible for this, so nominating for both.

I think that not reflecting more that one USV in the panic message makes sense, like how indexing a vec doesn't show the elements of the vec. But wanted to run it by teams as a user-visible change.

How do you feel about it?

RalfJung · 2026-03-11T15:49:50Z

library/core/src/str/mod.rs

        let ch = s[floor..ceil].chars().next().unwrap();
        panic!(
-            "start byte index {begin} is not a char boundary; it is inside {ch:?} (bytes {range:?}) of `{s_trunc}`{ellipsis}"
+            "start byte index {begin} is not a char boundary; it is inside {ch:?} (bytes {range:?} of string)"


Suggested change

"start byte index {begin} is not a char boundary; it is inside {ch:?} (bytes {range:?} of string)"

"start byte index {begin} is not a char boundary; it is inside {ch:?} (bytes {range:?})"

"of string" sounds odd to me -- is it needed? (Same for similar messages)

I like including the word string because the problem is due to mis-use of a str/String API, which may not otherwise be obvious

TKanX · 2026-03-11T18:04:45Z

library/core/src/str/mod.rs

        let ch = s[floor..ceil].chars().next().unwrap();
        panic!(
-            "end byte index {end} is not a char boundary; it is inside {ch:?} (bytes {range:?}) of `{s_trunc}`{ellipsis}"
+            "end byte index {end} is not a char boundary; it is inside {ch:?} (bytes {range:?} of string)"


"of string" sounds odd to me -- is it needed? (Same for similar messages)
@RalfJung

Suggested change

"end byte index {end} is not a char boundary; it is inside {ch:?} (bytes {range:?} of string)"

"end byte index {end} is not a char boundary; it is inside {ch:?} (bytes {range:?})"

1, 2, 6 describe the type so not redundant right?

joshtriplett · 2026-03-17T15:48:30Z

library/core/src/wtf8.rs

-    assert!(begin <= end);
-    panic!("index {begin} and/or {end} in `{s:?}` do not lie on character boundary");
+    let len = s.len();
+    if begin > len {
+        panic!("start byte index {begin} is out of bounds for string of length {len}");
+    }
+    if end > len {
+        panic!("end byte index {end} is out of bounds for string of length {len}");
+    }
+    if begin > end {
+        panic!("byte range starts at {begin} but ends at {end}");
+    }
+    if !s.is_code_point_boundary(begin) {
+        panic!("byte index {begin} is not a code point boundary");
+    }
+    panic!("byte index {end} is not a code point boundary");


🎉 This looks like a huge improvement to usability.

nia-e · 2026-03-17T15:55:43Z

This was discussed in today's @rust-lang/libs-api meeting; our conclusion was that we'd like to implement this as a usability improvement. We do not believe that this is sufficient or even necessarily useful for sanitisation of panic messages, but it is a much more readable panic message. +1 from us.

If someone would in the future want to expand this to also e.g. print the character indexed into, that would be welcome but this PR is already an improvement as-is.

@rustbot label -I-libs-nominated -I-libs-api-nominated

scottmcm · 2026-03-18T06:42:03Z

With the nod from libs-api on changing the messages, the change looks fine code-review wise, so
@bors r+

(Note that we can always tweak things further in other PRs if people so wish.)

rust-bors · 2026-03-18T06:42:06Z

📌 Commit 7ec050a has been approved by scottmcm

It is now in the queue for this repository.

rust-bors · 2026-03-18T07:34:53Z

⌛ Testing commit 7ec050a with merge 686fce3...

Workflow: https://github.com/rust-lang/rust/actions/runs/23234002650

@scottmcm

Remove string content from panics String content can be useful for debugging panics, particularly when you are working on a small codebase where you can infer more about the path taken through your program based on the content of the string. In production deployments that upload crashes for centralized debugging, string content poses a risk to user privacy. The string can accidentally contain information that the user is not expecting to share with the development team. On balance it seems like the risks outweigh the benefits. It is easy to add a `dbg!()` statement to gather more information in development; but comparatively tricky to ensure panics are sanitized by every rust app that monitors their production deployments. Ref https://internals.rust-lang.org/t/stop-including-string-content-in-index-panics/24067 r? @scottmcm

Zalathar · 2026-03-18T07:38:32Z

@bors yield (to encoding rollup)

rust-bors · 2026-03-18T07:38:36Z

Auto build was cancelled. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/23234002650

The next pull request likely to be tested is #154035.

Rollup of 3 pull requests Successful merges: - #153677 (Remove string content from panics) - #153945 (Change `?Sized` to `PointeeSized` in `UnwindSafe` impls for pointers) - #153985 (doc: clarify allocator invariant)

ConradIrwin · 2026-03-19T05:39:54Z

Thanks @nia-e and @scottmcm

rustbot assigned scottmcm Mar 10, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Mar 10, 2026

This comment has been minimized.

Sign in to view

TKanX reviewed Mar 10, 2026

View reviewed changes

library/core/src/wtf8.rs

// SAFETY: is_code_point_boundary checks that the index is valid

unsafe { slice_unchecked(self, range.start, range.end) }

} else {

slice_error_fail(self, range.start, range.end)

This comment was marked as resolved.

Sign in to view

TKanX reviewed Mar 10, 2026

View reviewed changes

library/core/src/wtf8.rs

// SAFETY: is_code_point_boundary checks that the index is valid

unsafe { slice_unchecked(self, range.start, self.len()) }

} else {

slice_error_fail(self, range.start, self.len())

This comment was marked as resolved.

Sign in to view

TKanX reviewed Mar 10, 2026

View reviewed changes

library/core/src/wtf8.rs

// SAFETY: is_code_point_boundary checks that the index is valid

unsafe { slice_unchecked(self, 0, range.end) }

} else {

slice_error_fail(self, 0, range.end)

This comment was marked as resolved.

Sign in to view

ConradIrwin force-pushed the sanitary-string-panics branch from 534370d to 05ac9d4 Compare March 11, 2026 01:36

TKanX reviewed Mar 11, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

ConradIrwin mentioned this pull request Mar 11, 2026

Redact string panics zed-industries/zed#51248

Merged

Fix tests and tidy up wtf-8 failures

7ec050a

Co-authored-by: TKanX <124454788+TKanX@users.noreply.github.com>

scottmcm added I-libs-nominated Nominated for discussion during a libs team meeting. I-libs-api-nominated Nominated for discussion during a libs-api team meeting. labels Mar 11, 2026

RalfJung reviewed Mar 11, 2026

View reviewed changes

TKanX reviewed Mar 11, 2026

View reviewed changes

joshtriplett reviewed Mar 17, 2026

View reviewed changes

rustbot removed I-libs-api-nominated Nominated for discussion during a libs-api team meeting. I-libs-nominated Nominated for discussion during a libs team meeting. labels Mar 17, 2026

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 18, 2026

Zalathar mentioned this pull request Mar 18, 2026

Rollup of 3 pull requests #154035

Merged

rust-bors bot merged commit 04e7f2f into rust-lang:main Mar 18, 2026
11 of 12 checks passed

rustbot added this to the 1.96.0 milestone Mar 18, 2026

	"start byte index {begin} is not a char boundary; it is inside {ch:?} (bytes {range:?} of string)"
	"start byte index {begin} is not a char boundary; it is inside {ch:?} (bytes {range:?})"

	"end byte index {end} is not a char boundary; it is inside {ch:?} (bytes {range:?} of string)"
	"end byte index {end} is not a char boundary; it is inside {ch:?} (bytes {range:?})"

Uh oh!

Conversation

ConradIrwin commented Mar 10, 2026

Uh oh!

This comment has been minimized.

This comment was marked as resolved.

Uh oh!

TKanX Mar 11, 2026

Choose a reason for hiding this comment

Uh oh!

This comment was marked as resolved.

Uh oh!

This comment was marked as resolved.

Uh oh!

This comment was marked as resolved.

Uh oh!

This comment was marked as resolved.

Uh oh!

This comment has been minimized.

TKanX commented Mar 11, 2026

Uh oh!

ConradIrwin commented Mar 11, 2026

Uh oh!

scottmcm commented Mar 11, 2026

Uh oh!

RalfJung Mar 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ConradIrwin Mar 19, 2026

Choose a reason for hiding this comment

Uh oh!

TKanX Mar 11, 2026

Choose a reason for hiding this comment

Uh oh!

TKanX Mar 11, 2026

Choose a reason for hiding this comment

Uh oh!

joshtriplett Mar 17, 2026

Choose a reason for hiding this comment

Uh oh!

nia-e commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

scottmcm commented Mar 18, 2026

Uh oh!

rust-bors bot commented Mar 18, 2026

Uh oh!

rust-bors bot commented Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Zalathar commented Mar 18, 2026

Uh oh!

rust-bors bot commented Mar 18, 2026

Uh oh!

Uh oh!

ConradIrwin commented Mar 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

RalfJung Mar 11, 2026 •

edited

Loading

nia-e commented Mar 17, 2026 •

edited

Loading

rust-bors bot commented Mar 18, 2026 •

edited

Loading