[Talha-Dmr]

During compaction, String::retain reads the next character with g.s.get_unchecked(read..len). This invokes String’s Deref, constructing a &str over the entire 0..len buffer before selecting the unread tail.

For example, removing 'é' from "éab" and moving 'a' left changes the buffer from C3 A9 61 62 to 61 A9 61 62. The next iteration reads the valid 'b' tail, but first converts the entire buffer, including the orphaned A9 continuation byte, to &str.

Constructing a non-UTF-8 &str is not immediate language-level UB under the Reference’s validity requirements. However, this conversion violates from_utf8_unchecked’s documented safety precondition. The libs discussion in #134598 is discussing which operations accept invalid UTF-8; str::get_unchecked is absent from the tentative list.

The fix slices read..len directly from the byte vector and converts only that untouched tail to &str. The original string was valid UTF-8, and read remains on a character boundary. #154583 uses the same approach for extract_if.

Related: #150067, #134598, #154583.

[rustbot]

Thanks for the pull request, and welcome! The Rust Project has assigned @JohnTitor (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks.

Please see the contribution instructions and our LLM policy for more information.

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from Darksonn, JohnTitor, Mark-Simulacrum, clarfonthey

[JohnTitor]

r? libs

[Mark-Simulacrum]

Hi! The code changes here look good.

However, we commit PR descriptions into history, and it's not particularly useful to note that you ran a specific amount of tests from a particular bucket: that number is not meaningful.

I also note that it seems like you're describing somewhat redundant validation: "A separate codegen comparison produced identical optimized x86-64 assembly for the tested predicates." and relatively simple inspection of the code changes implies that there cannot be any behavior differences, so stating that there was a bunch of differential comparison done is not useful.

Can you adjust your PR description to focus on the present review and future readers, rather than an exhaustive review of what you and/or your LLM helped do? Thank you!

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[Talha-Dmr]

Thanks for the feedback! I have updated the PR description to focus only on the change itself.

For transparency per the policy: an AI assistant initially noticed this potential issue during a verification attempt, after which I independently verified the finding and wrote the patch myself.

@rustbot ready