Codegen ZSTs without an allocation
This makes sure that &[] is equivalent to unsafe code (from_raw_parts(dangling, 0)). No new stable guarantee is intended about whether or not we do this, this is just an optimization.
This regressed in #67000 (no comments I can see about that regression in the PR, though it did change the test modified here). We had previously performed this optimization since #63635.
Remove libc from rust_get_test_int uses
`rust_test_helpers.c` has a few unfortunate signatures which have made some of our UI tests _technically_ need the `libc` crate. This is my attempt to evict the need of `libc` for `rust_get_test_int`.
I've deleted `tests/ui/abi/foreign/foreign-no-abi.rs` because the test was originally written to check that `native mod` will compile without an ABI specifier. `native mod` was removed years before 1.0 and the test hasn't checked for anything for a long time.
interpret: pass MemoryKind to adjust_alloc_base_pointer
Another puzzle piece for https://github.com/rust-lang/miri/pull/3475.
The 2nd commit renames base_pointer -> root_pointer; that's how Tree Borrows already calls them and I think the term is more clear than "base pointer". In particular, this distinguishes it from "base address", since a root pointer can point anywhere into an allocation, not just its base address.
https://github.com/rust-lang/rust/pull/124018 has been rolled up already so I couldn't add it there any more.
r? ```@oli-obk```
Document overrides of `clone_from()` in core/std
As mentioned in https://github.com/rust-lang/rust/pull/96979#discussion_r1379502413
Specifically, when an override doesn't just forward to an inner type, document the behavior and that it's preferred over simply assigning a clone of source. Also, change instances where the second parameter is "other" to "source".
I reused some of the wording over and over for similar impls, but I'm not sure that the wording is actually *good*. Would appreciate feedback about that.
Also, now some of these seem to provide pretty specific guarantees about behavior (e.g. will reuse the exact same allocation iff the len is the same), but I was basing it off of the docs for [`Box::clone_from`](https://doc.rust-lang.org/1.75.0/std/boxed/struct.Box.html#method.clone_from-1) - I'm not sure if providing those strong guarantees is actually good or not.
meta: notify #t-rustdoc Zulip stream on backport nominations
In July '23, it was decided to handle rustdoc-specific backport nominations in t-rustdoc meetings going forward ([Zulip announcement](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/T-rustdoc.20backports/near/374828518)). However, t-rustdoc meetings are far too infrequent for them to address nominations on time (contrary to the weekly t-compiler meetings).
Hence GuillaumeGomez and I came to the conclusion that {beta,stable}-nominated rustdoc PRs should be dealt with on a case by case basis, e.g. on Zulip.
This PR attempts to partially automate this process. ~~Sadly, `triagebot` is not quite as flexible has I've hoped. Blocked on `triagebot` improvements (see the `FIXME`s in this PR).~~ (Fixed in rust-lang/triagebot#1791).
r? GuillaumeGomez
fix: Replace Just the variable name in Unused Variable Diagnostic Fix
Changes Unused Variable diagnostic to just look at the variable name, not the entire syntax range.
Also added a test for an unused variable in an array destructure.
Closes#17053
This comment was historically inside a block guarded by
`if let Some(otherwise_block) = otherwise`.
When #120978 made the otherwise block non-optional, it also flattened that
region of code. Doing so left this comment awkwardly stranded above an
unrelated line of code, without its original context.
We can restore that context by moving it above the declaration of `otherwise`.
directly call handle_alloc_error
Also test more codepaths. There's like 5 different things that can happen on allocation failure! Between `-Zoom`, `#[alloc_error_handler]`, and `set_alloc_error_hook`, we have 3 layers of behavior overrides. It's all a bit messy.
https://github.com/rust-lang/rust/pull/112331 seems intended to clean this up, but has not yet reached consensus.
