Mark str::is_char_boundary and str::split_at* unstably const.

[zachs18]

Tracking issues: #131516, #131518

First commit implements const_is_char_boundary, second commit implements const_str_split_at (which depends on const_is_char_boundary)

I used const_eval_select for is_char_boundary since there is a comment about optimizations that would theoretically not happen with the simple const-compatible version (since slice::get is not constifiable) cc #84751. I have not checked if this code difference is still required for the optimization, so it might not be worth the code complication, but 🤷.

This changes str::split_at_checked to use a new private helper function split_at_unchecked (copied from split_at_mut_unchecked) that does pointer stuff instead of get_unchecked, since that is not currently constifiable due to using the SliceIndex trait.

[rustbot]

r? @Noratrieb

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

[okaneco]

I found the commit f621193 that added the optimization comments mentioning avoiding a panic branch and touching memory when index was 0 which you can see here, comparing 1.8, 1.9, and nightly
https://rust.godbolt.org/z/GTx4Mc3G4

I don't think the last comment line rules out const-incompatibility. It looks like it's trying to reinforce that slice.get(..i) relies on that specific early return to optimize out checks, not that using get(i) in is_char_boundary is required for the optimization.

I would assume you'd get the same optimizations if the match+get() was converted to an if-else statement, but there should probably be codegen tests to make sure the 0-constant slicing behavior is unchanged.

if index == 0 { return true; }
if index < self.as_bytes().len() {
    self.as_bytes()[index].is_utf8_char_boundary()
} else {
    index == self.len()
}

[Noratrieb]

Yeah, I think you should do the check as @okaneco described, which is const-compatible and should produce the same code in the end.

[zachs18]

Latest push translates the prior code as literally as possible to a const-compatible version, without using const_eval_select

[Noratrieb]

thanks, that looks a lot better.

[bors]

📌 Commit aa493d0 has been approved by Noratrieb

It is now in the queue for this repository.

[RalfJung]

Why did you add rustc_allow_const_fn_unstable here? That makes no sense on an unstable const fn. (I'm cleaning this up in #132451.)

Also @Noratrieb please make sure to get wg-const-eval approval before adding any rustc_allow_const_fn_unstable.

[RalfJung]

Ideally we'd have a bot helping with this attribute policy... rust-lang/triagebot#1851

[Noratrieb]

ah, I didn't see this, yeah. I was a bit unsure whether I need to ping const eval here but I deemed that there wasn't anything weird enough going on to be problematic (which I guess is sort of true here, the attribute is just misplaced). will be more careful next time

[zachs18]

Why did you add rustc_allow_const_fn_unstable here? That makes no sense on an unstable const fn. (I'm cleaning this up in #132451.)

I added it because I got an error otherwise, though that was on an earlier version of the PR.