add #[rustc_no_writable] to slice::get_unchecked_mut

[quiode]

This PR adds the #[rustc_no_writable] attribute introduced in #155207 to the slice::get_unchecked_mut function.

Two library functions already received this attribute, as they were known to cause problems with the llvm writable attribute and tree borrows. Since that PR, I ran Miri on the 30'000 most downloaded crates to see what kind of code is now UB under Tree Borrows + implicit writes, using the detection implemented in rust-lang/miri#4947. Adding this attribute to ignore checking for this function reduced the new UB introduced by more than 75%, meaning that instead of 19000 tests in 1700 crates having a difference, now only 3500 in 350 crates show a difference (measurement still running).

[rustbot]

r? @Mark-Simulacrum

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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 7 candidates
• Random selection from Mark-Simulacrum, jhpratt

[quiode]

r? @RalfJung

[rustbot]

RalfJung is not on the review rotation at the moment.
They may take a while to respond.

[Mark-Simulacrum]

Should this get an annotation of some kind (e.g., "FIXME: #xxx")? I assume the intent is not to guarantee that we don't have compiler-added writes of the full slice, maybe with the long-term intent being that users move to using raw pointer functions where they need that (https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.get_unchecked_mut)?

View changes since the review

[RalfJung]

Personally I think this is fine to guarantee. But for now the attribute is experimental anyway.

[RalfJung]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[quiode]

The proposed test wasn't exactly the pattern I tried to fix (and also still fails with the attribute). It was more something like this: https://github.com/quiode/rust/blob/ignore-list/src/tools/miri/tests/fail/tree_borrows/implicit_writes/libc_recv.rs or https://github.com/quiode/rust/blob/ignore-list/src/tools/miri/tests/fail-dep/tree_borrows/implicit_writes/crates/fs-read.rs. I tried to replicate this in the new test, which fails without the attribute but passes with it.

@rustbot ready