Clarify UB in get_unchecked(_mut)

[scottmcm]

Inspired by #116915, it was unclear to me what exactly "out-of-bounds index" means in get_unchecked.

One could potentially interpret it that get_unchecked is just another way to write offset, but I think get_unchecked(len) is supposed to be UB even though .offet(len) is well-defined (as is .get_unchecked(..len)), so write that more directly in the docs.

libs-api folks: Can you confirm whether this is what you expect this to mean? And is the situation any different for <*const [T]>::get_unchecked?

[rustbot]

r? @cuviper

(rustbot has picked a reviewer for you, use r? to override)

[the8472]

And is the situation any different for <*const [T]>::get_unchecked?

To add: One could interpret this as an offset, in which case one-past-the-end would be fine. But if we reserve the right to add intrinsics::assume(idx < len) here then it should also be UB.

[asquared31415]

"Out of bounds index" is almost certainly meant to mean exactly the same cases where you get the following panic with [idx]:

thread 'main' panicked at src/main.rs:2:3:
index out of bounds: the len is 1 but the index is 10

This same "out of bounds" phrasing is used all over docs, the Reference, and a bunch of other places, it would be surprising for it to mean anything else.

[scottmcm]

Yeah, I think it makes sense for it to be the same as the other places, but the codegen means that LLVM generally wouldn't have any problems with it today, and it's only caught by stacked borrows checks in MIRI (and it's not caught at all today by MIRI for <*const [T]>::get_unchecked because that doesn't make a ref). So people might be relying on it "working".

Some quick examples: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=e6c38266426650ec506f0a91f32cf264

[asquared31415]

Right, that's library UB not language UB for the raw pointer version. I forgot that that method exists!

[Amanieu]

We discussed this in the libs-api meeting: abusing get_unchecked_mut to get a pointer to the end of a slice is clearly UB since it involves creating an out-of-bounds reference.

@rfcbot fcp merge

[rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[cuviper]

LGTM!

@bors r+ rollup

[cuviper]

@bors r+ rollup

[bors]

📌 Commit 545175c has been approved by cuviper

It is now in the queue for this repository.