Change:
// the last byte of the utf8 encoded needle let last_byte = unsafe { *self.utf8_encoded.get_unchecked(self.utf8_size - 1) }; if let Some(index) = memchr::memrchr(last_byte, bytes) { <ins> // we searched a slice that was offset by self.finger, // add self.finger to recoup the original index let index = self.finger + index; </ins> // memrchr will return the index of the byte we wish to // find. In case of an ASCII character, this is indeed // were we wish our new finger to be ("after" the found

Discussion:
Hello When playing with some development versions of tower-grpc-build (), I discovered a strange crash of the build script. I managed to shring it a bit, but I don't think this is minimal case (I just don't know how to continue pinning it down further). Few observations: The string it talks about in the backtrace seems like random junk (which isn't always the same). I'm not sure how it got there, but in general, Rust probably should prevent creation of strings with uninitialized content. It doesn't happen on stable. It happens on today's and yesterday's nightly (exact version below). It doesn't happen on approx. a week old nightly, but I'm not at the computer that has the older version, I'll look exact version when I get to it in few hours. As I needed to pin exact commits in to make the branches and crates from git to compile together, I have the example as a whole repository: Steps to reproduce (I moved the failing code from build script to ordinary , therefore the ): The backtrace: It is likely something fishy is happening in some of the development branches, but I still suspect something strange happening in the compiler, both because of the uninitialized memory (or, memory looking uninitialized) and because it passes on stable, but not nightly.
cc -- any chance somebody can bisect this a bit to see where the problem started?
triage: P-high
If it helps, this one goes through (): And this one fails (): Anything more exact would need setting up of some non-trivial infrastructure on my own computer.
Given the range ... I'm pretty sure it is , but let me bisect anyway... Edit: failed due to procmacro` ಠಠ needs to reduce it first.
cc
Reductions: <details<summaryReducing dependency to <codeprost_build</code.</summary</detailsall dependencies. Repro on playground. Edit: Hold on, this program affects beta (1.24.0-beta.1) as well
Bisecting in the range ... Test script: ( has content shown in ) Bisect result: So yeah the cause is definitely , and since it slips into beta it affects 1.24 beta as well.
Huh. Wat. I'll fix this tomorrow.
Okay, so the bug seems to be a discrepancy in how I thought the searcher API is supposed to work.

in old Rust this returns Some(1,2) and None, in new Rust it returns the same thing twice. I was under the impression that double ended searchers had independent fingers, but this seems to be wrong. We really need to overhaul this API so that it actually makes sense.
Fixed in r?
Our build is crashing through this bug. Nightly is green again after this PR was merged, however beta is still red. Will beta still be rolled out to stable and break our build in a few weeks? Or will there be a beta hotfix with this PR included?
Yes we are going to backport to 1.24 beta.
It's been marked beta-nominated, so it will be included before we make a stable release. I don't know if it will be included in a new beta before that. Either way, I'm the wrong person to ask, would know
Yes, we will (likely) publish a new beta with this backport. There's 5(?) weeks before the next release, so we'll need at least 2-3 more betas probably
Awesome! Thanks for clarifying.
I believe the latest beta should have the fix (.2).