Correct the const stabilization of <[T]>::last_chunk

[glandium]

<[T]>::first_chunk became const stable in 1.77, but <[T]>::last_chunk was left out. This was fixed in 3488679, which reached stable in 1.80, making <[T]>::last_chunk const stable as of that version, but it is documented as being const stable as 1.77. While this is what should have happened, the documentation should reflect what actually did happen.

[rustbot]

r? @scottmcm

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

[glandium]

error[E0711]: feature `slice_first_last_chunk` is declared stable since 1.80.0, but was previously declared stable since 1.77.0
   --> library/core/src/slice/mod.rs:525:5
    |
525 |     #[rustc_const_stable(feature = "slice_first_last_chunk", since = "1.80.0")]

huh. What would be the right way to fix this? Add a fake feature?

[folkertdev]

quick guess: you need to add #[cfg_attr(bootstrap, ...)] around anything you change (and the negation too I guess) For stage0 you should not change the state, but then stage0 is used to build stage1 and that is when the change is applied. I think just any ./x test tests/ui/ sort of command would verify that that works, because by default the standard library is recompiled.

https://rustc-dev-guide.rust-lang.org/building/bootstrapping/intro.html

I think these boostraps then get resolved at the next release? at least that is how it appears to work for features

[ChrisDenton]

huh. What would be the right way to fix this? Add a fake feature?

All libs features are fake. So yeah, just call the feature something unique. Maybe just stick _const on the end so it's still clearly related.

[tgross35]

quick guess: you need to add #[cfg_attr(bootstrap, ...)] around anything you change (and the negation too I guess) For stage0 you should not change the state, but then stage0 is used to build stage1 and that is when the change is applied. I think just any ./x test tests/ui/ sort of command would verify that that works, because by default the standard library is recompiled.

https://rustc-dev-guide.rust-lang.org/building/bootstrapping/intro.html

I think these boostraps then get resolved at the next release? at least that is how it appears to work for features

cfg(bootstrap) shenanigans are only needed when library changes rely on changes in the compiler, which isn't the case here. A new feature would suffice.

Not sure why I didn't do this originally (probably thinking about consistency more than the number in the docs). If you make a new feature gate, just update the original tracking issue to mention it so it is easier to search.

[glandium]

huh. What would be the right way to fix this? Add a fake feature?

All libs features are fake. So yeah, just call the feature something unique. Maybe just stick _const on the end so it's still clearly related.

Inconveniently, there's an existing const_slice_first_last_chunk. That would probably make things confusing. Maybe const_slice_last_chunk ?

[scottmcm]

yup, feature names are fake once stabilized (thankfully!), so just putting in whatever is good 👍

@bors r+ rollup

[bors]

📌 Commit 70ab51f has been approved by scottmcm

It is now in the queue for this repository.

[glandium]

Should this go to beta?

[scottmcm]

It's unclear to me whether it'd meet the beta gate, since it's just a how-it-shows-in-rustdoc fix. The only actually-reliable way to see what's in what release is to look at the docs from that release anyway, and https://doc.rust-lang.org/1.78.0/std/primitive.slice.html#method.last_chunk already correctly shows that it's not const-stable in 1.78, for example. But we'll see what the people who actually make the decisions about backports have to say.

[the8472]

We discussed this in a T-libs meeting today (not much attendance though). It's low-risk but also low importance. And since the incorrect documentation is already out with 1.80 there's not much of a reason to get this fixed asap.