Delay interning errors to after validation
fixes https://github.com/rust-lang/rust/issues/122398fixes#122548
This improves diagnostics since validation errors are usually more helpful compared with interning errors that just make broad statements about the entire constant
r? `@RalfJung`
Update how WASI toolchains are used in CI and bootstrap
This commit updates how the WASI targets are configured with their toolchain. Long ago a `config.toml` option of `wasi-root` was added to enable building with the WASI files produced by wasi-libc. Additionally for CI testing and release building the Rust toolchain has been using a hard-coded commit of wasi-libc which is bundled with the release of the `wasm32-wasip1` target, for example.
Nowadays though the wasi-sdk project, the C/C++ toolchain for WASI, is the go-to solution for compiling/linking WASI code and contains the more-or-less official releases of wasi-libc. This commit migrates CI to using wasi-sdk releases and additionally updates `bootstrap` to recognize when this is configured. This means that with `$WASI_SDK_PATH` configured there's no further configuration necessary to get a working build. Notably this also works better for the new targets of WASI as well, such as `wasm32-wasip2` and `wasm32-wasip1-threads` where the wasi-sdk release now has libraries for all targets bundled within it.
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
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`.