Bump MSRV to 1.80

[Manishearth]

No description provided.

[Manishearth]

n.b. I kept the rustdoc nightly and the LLVM nightly separate to keep an indicator that they can be separate. However I could homogenize them if desired.

[sffc]

Let's wait on #5935 first. Sorry.

[sffc]

There's a lot of good stuff in here. I think we can get to Rust 1.75 at least, and maybe Rust 1.76, without bumping LLVM. It sadly doesn't get us slice_at_checked, but I agree that if we're going to be upgrading MSRV, doing so at the major version boundary seems like a good call.

That said, if there isn't anything in 1.76 that we care about, then we should lean toward lower MSRV when possible.

[sffc]

Also, for the specific problem of split_at_checked, I previously found that the following code compiles to exactly the same assembly.

if i <= my_slice.len() {
    Some(my_slice.split_at(i))
} else {
    None
}

In other words, the bounds check inside split_at goes away once the code is inlined.

So, although I would be very happy to use split_at_checked, I'm not convinced it is a strong enough reason to break Xcode for the next 9 months.

[Manishearth]

Also, for the specific problem of split_at_checked, I previously found that the following code compiles to exactly the same assembly.

Yeah I proposed this before, I don't recall what Henri felt about that. I'll comment on the other issue.

[Manishearth]

I actually feel that the reason of "we should start 2.0 with a relatively upgraded rustc so that future upgrades are rarer" is a more compelling reason than this one API. I consider the ability to run a pair of niche FFI tests on a default Mac install to be negligible in value.

[sffc]

I actually feel that the reason of "we should start 2.0 with a relatively upgraded rustc so that future upgrades are rarer" is a more compelling reason than this one API.

I agree with this and am okay temporarily relaxing the Xcode constraint in order to reduce the number of MSRV changes in the 2.x stream.

I consider the ability to run a pair of niche FFI tests on a default Mac install to be negligible in value.

Discussed in #5945; it's about how a prototypical ICU4X iOS developer, one who is expected to care about binary size, should use ICU4X, not just "running niche FFI tests on a default Mac install."

[hsivonen]

Also, for the specific problem of split_at_checked, I previously found that the following code compiles to exactly the same assembly.

Yeah I proposed this before, I don't recall what Henri felt about that. I'll comment on the other issue.

Changed in the PR.