This patch has been extracted from #123720. It specifically enhances
`Sccs` to allow tracking arbitrary commutative properties of SCCs, including
- reachable values (max/min)
- SCC-internal values (max/min)
This helps with among other things universe computation: we can now identify
SCC universes as a straightforward "find max/min" operation during SCC construction.
It's also more or less zero-cost; don't use the new features, don't pay for them.
This commit also vastly extends the documentation of the SCCs module, which I had a very hard time following.
Rollup of 16 pull requests
Successful merges:
- #123374 (DOC: Add FFI example for slice::from_raw_parts())
- #124514 (Recommend to never display zero disambiguators when demangling v0 symbols)
- #125978 (Cleanup: HIR ty lowering: Consolidate the places that do assoc item probing & access checking)
- #125980 (Nvptx remove direct passmode)
- #126187 (For E0277 suggest adding `Result` return type for function when using QuestionMark `?` in the body.)
- #126210 (docs(core): make more const_ptr doctests assert instead of printing)
- #126249 (Simplify `[T; N]::try_map` signature)
- #126256 (Add {{target}} substitution to compiletest)
- #126263 (Make issue-122805.rs big endian compatible)
- #126281 (set_env: State the conclusion upfront)
- #126286 (Make `storage-live.rs` robust against rustc internal changes.)
- #126287 (Update a cranelift patch file for formatting changes.)
- #126301 (Use `tidy` to sort crate attributes for all compiler crates.)
- #126305 (Make PathBuf less Ok with adding UTF-16 then `into_string`)
- #126310 (Migrate run make prefer rlib)
- #126314 (fix RELEASES: we do not support upcasting to auto traits)
r? `@ghost`
`@rustbot` modify labels: rollup
fix RELEASES: we do not support upcasting to auto traits
#119338 does not actually support casts from `dyn Trait` to `dyn Auto`, only from `dyn Trait` to `dyn Trait + Auto`. The following test does not compile
```rust
trait Trait: Send {}
impl<T: Send> Trait for T {}
fn foo() {
let x: &i32 = &1;
let y = x as &dyn Trait as &dyn Send;
}
```
it actually also doesn't compile with `feature(trait_upcasting)`, opened #126313 for that
r? `@Mark-Simulacrum` `@cuviper`
Make PathBuf less Ok with adding UTF-16 then `into_string`
Fixes#126291 which is, as far as I can tell, a regression introduced by #96869.
try-job: x86_64-msvc
Use `tidy` to sort crate attributes for all compiler crates.
We already do this for a number of crates, e.g. `rustc_middle`, `rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`.
For the ones we don't, in many cases the attributes are a mess.
- There is no consistency about order of attribute kinds (e.g. `allow`/`deny`/`feature`).
- Within attribute kind groups (e.g. the `feature` attributes), sometimes the order is alphabetical, and sometimes there is no particular order.
- Sometimes the attributes of a particular kind aren't even grouped all together, e.g. there might be a `feature`, then an `allow`, then another `feature`.
This commit extends the existing sorting to all compiler crates, increasing consistency. If any new attribute line is added there is now only one place it can go -- no need for arbitrary decisions.
Exceptions:
- `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`, because they have no crate attributes.
- `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's ignored in `rustfmt.toml`).
r? `@davidtwco`
Update a cranelift patch file for formatting changes.
PR #125443 will reformat all the use declarations in the repo. This would break a patch kept in `rustc_codegen_cranelift` that gets applied to `library/std/src/sys/pal/windows/rand.rs`.
So this commit formats the use declarations in `library/std/src/sys/pal/windows/rand.rs` in advance of #125443 and updates the patch file accordingly.
The motivation is that #125443 is a huge change and we want to get fiddly little changes like this out of the way so it can be nothing more than an `x fmt --all`.
r? ``@bjorn3``
Make `storage-live.rs` robust against rustc internal changes.
Currently it can be made to fail by rearranging code within `compiler/rustc_mir_transform/src/lint.rs`.
This is a precursor to #125443.
r? ```@lqd```
set_env: State the conclusion upfront
People tend to skim or skip over long explanations so we should be very upfront that `set_var` and `remove_var` are being made unsafe for a very good reason.
This is just the conclusion restated almost verbatim but earlier in the docs and separated from the explanation:
0c960618b5/library/std/src/env.rs (L338-L339)
I think this may help with people who may not be entirely comfortable with #125937 being rejected.
Make issue-122805.rs big endian compatible
Instead of not generating the function at all on big endian (which makes the CHECK lines fail), instead use to_le() on big endian, so that we essentially perform a bswap for both endiannesses.
Add {{target}} substitution to compiletest
In ferrocene we have ui tests testing the cli interface of the compiler, one of which tests the `--target` flag. To be able to run this on all targets we require a way to specify a valid target in the `compile-flags` directive that is target independent, as otherwise we can only run the test against the one target we choose to supply in the flags. See 383cbc80f4/tests/ui/ferrocene/compiler-arguments/target/target.rs
We figured the project might be able to make use of this substitution as well in the future.
try-job: dist-x86_64-msvc
Simplify `[T; N]::try_map` signature
People keep making fun of this signature for being so gnarly.
Associated type bounds admit a much simpler scribbling.
r? ````@scottmcm````
For E0277 suggest adding `Result` return type for function when using QuestionMark `?` in the body.
Adding suggestions for following function in E0277.
```rust
fn main() {
let mut _file = File::create("foo.txt")?;
}
```
to
```rust
fn main() -> Result<(), Box<dyn std::error::Error>> {
let mut _file = File::create("foo.txt")?;
return Ok(());
}
```
According to the issue #125997, only the code examples in the issue are targeted, but the issue covers a wider range of situations.
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Nvptx remove direct passmode
This PR does what should have been done in #117671. That is fully avoid using the `PassMode::Direct` for `extern "C" fn` for `nvptx64-nvidia-cuda` and enable the compatibility test. `@RalfJung` [pointed me in the right direction](https://github.com/rust-lang/rust/issues/117480#issuecomment-2137712501) for solving this issue.
There are still some ABI bugs after this PR is merged. These ABI tests are created based on what is actually correct, and since they continue passing with even more of them enabled things are improving. I don't have the time to tackle all the remaining issues right now, but I think getting these improvements merged is very valuable in themselves and plan to tackle more of them long term.
This also doesn't remove the use of `PassMode::Direct` for `extern "ptx-kernel" fn`. This was also not trivial to make work. And since the ABI is hidden behind an unstable feature it's less urgent.
I don't know if it's correct to request `@RalfJung` as a reviewer (due to team structures), but he helped me a lot to figure out this stuff. If that's not appropriate then `@davidtwco` would be a good candidate since he know about this topic from #117671
r? `@RalfJung`
Cleanup: HIR ty lowering: Consolidate the places that do assoc item probing & access checking
Use `probe_assoc_item` (for hygienically probing an assoc item and checking if it's accessible wrt. visibility and stability) for assoc item constraints, too, not just for assoc type paths and make the privacy error translatable.
Recommend to never display zero disambiguators when demangling v0 symbols
This PR extends the [v0 symbol mangling documentation](https://doc.rust-lang.org/rustc/symbol-mangling/v0.html) with the strong recommendation that demanglers should never display zero-disambiguators, especially when dealing with `crate-root`.
Being able to rely on `C3foo` to be rendered as `foo` (i.e. without explicit disambiguator value) rather than as `foo[0]` allows the compiler to encode things like new basic types in a backward compatible way. This idea has been originally proposed by `@eddyb` in [the discussion around supporting `f16` and `f128` in the v0 mangling scheme](https://github.com/rust-lang/rust/pull/122106). It is a generally useful mechanism for supporting a certain class of new elements in the v0 mangling scheme in a backward compatible way (whether as a temporary workaround until downstream tooling has picked up grammar changes or as a permanent encoding).
cc `@tgross35`
Tait must be constrained if in sig
r? `@compiler-errors`
kind of reverts https://github.com/rust-lang/rust/pull/62423, but that PR only removed cycles in cases that we want to forbid now anyway.
see https://rust-lang.zulipchat.com/#narrow/stream/315482-t-compiler.2Fetc.2Fopaque-types/topic/lcnr.20oli.20meeting/near/370712246 for related discussion and motivating example
a TAIT showing up in a signature doesn't just mean it can register a hidden type, but that it must.
This is the [design the types team decided upon](https://hackmd.io/QOsEaEJtQK-XDS_xN4UyQA#Proposal-preferred) for the following reasons
* avoids a hypothetical situation where getting smarter in trait solving could cause new cycle errors or new inference errors to show up, where today something is treated as opaque.
* avoids having the situation where a (minor?) change to a function body causes an error, because its TAIT usage suddenly isn't "opaque enough" anymore.
* avoids having to explain why in some cases you need to put a Tait into a tiny module together with its defining usages. Now you basically gotta always do this, the moment a Tait is in a signature that isn't in the defining scope.
* avoids false-cycle errors
* anything diverging from this pattern needs to either
* move the TAIT declaration and defining function into their own helper sub module
* use the attributes we'll provide in the future to explicitly opt in or out of being in the defining scope
fixes#117861
reverts #125362 cc `@Nilstrieb` `@joboet`
Update cargo
14 commits in b1feb75d062444e2cee8b3d2aaa95309d65e9ccd..4dcbca118ab7f9ffac4728004c983754bc6a04ff
2024-06-07 20:16:17 +0000 to 2024-06-11 16:27:02 +0000
- Add local registry overlays (rust-lang/cargo#13926)
- docs(change): Don't mention non-existent workspace.badges (rust-lang/cargo#14042)
- test: migrate binary_name to snapbox (rust-lang/cargo#14041)
- Bump to 0.82.0; update changelog (rust-lang/cargo#14040)
- tests: Migrate alt_registry to snapbox (rust-lang/cargo#14031)
- fix: proc-macro example from dep no longer affects feature resolution (rust-lang/cargo#13892)
- chore: Bump cargo-util-schemas to 0.5 (rust-lang/cargo#14038)
- chore(deps): update rust crate pulldown-cmark to 0.11.0 (rust-lang/cargo#14037)
- fix: remove `__CARGO_GITOXIDE_DISABLE_LIST_FILES` env var (rust-lang/cargo#14036)
- chore(deps): update rust crate itertools to 0.13.0 (rust-lang/cargo#13998)
- fix(toml): remove `lib.plugin` key support and make it warning (rust-lang/cargo#13902)
- chore(deps): update compatible (rust-lang/cargo#13995)
- fix: using `--release/debug` and `--profile` together becomes an error (rust-lang/cargo#13971)
- fix(toml): Convert warnings that `licence` and `readme` files do not exist into errors (rust-lang/cargo#13921)
r? ghost
We already do this for a number of crates, e.g. `rustc_middle`,
`rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`.
For the ones we don't, in many cases the attributes are a mess.
- There is no consistency about order of attribute kinds (e.g.
`allow`/`deny`/`feature`).
- Within attribute kind groups (e.g. the `feature` attributes),
sometimes the order is alphabetical, and sometimes there is no
particular order.
- Sometimes the attributes of a particular kind aren't even grouped
all together, e.g. there might be a `feature`, then an `allow`, then
another `feature`.
This commit extends the existing sorting to all compiler crates,
increasing consistency. If any new attribute line is added there is now
only one place it can go -- no need for arbitrary decisions.
Exceptions:
- `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`,
because they have no crate attributes.
- `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's
ignored in `rustfmt.toml`).
Make `ObligationEmittingRelation`s emit `Goal` rather than `Obligation`
Helps avoid needing to uplift `Obligation` into the solver. We still can't get rid of `ObligationCause`, but we can keep it as an associated type for `InferCtxtLike` and just give it a `dummy` function.
There's some shuttling between `Goal` and `Obligation` that may be perf-sensitive... Let's see what rust-timer says.
r? lcnr
Edition 2024: Make `!` fall back to `!`
This PR changes never type fallback to be `!` (the never type itself) in the next, 2024, edition.
This makes the never type's behavior more intuitive (in 2024 edition) and is the first step of the path to stabilize it.
r? `@compiler-errors`
PR #125443 will reformat all the use declarations in the repo. This
would break a patch kept in `rustc_codegen_cranelift` that gets applied
to `library/std/src/sys/pal/windows/rand.rs`.
So this commit formats the use declarations in
`library/std/src/sys/pal/windows/rand.rs` in advance of #125443 and
updates the patch file accordingly.
The motivation is that #125443 is a huge change and we want to get
fiddly little changes like this out of the way so it can be nothing more
than an `x fmt --all`.
Rollup of 6 pull requests
Successful merges:
- #115974 (Split core's PanicInfo and std's PanicInfo)
- #125659 (Remove usage of `isize` in example)
- #125669 (CI: Update riscv64gc-linux job to Ubuntu 22.04, rename to riscv64gc-gnu)
- #125684 (Account for existing bindings when suggesting `pin!()`)
- #126055 (Expand list of trait implementers in E0277 when calling rustc with --verbose)
- #126174 (Migrate `tests/run-make/prefer-dylib` to `rmake.rs`)
r? `@ghost`
`@rustbot` modify labels: rollup
Account for existing bindings when suggesting `pin!()`
When we encounter a situation where we'd suggest `pin!()`, we now account for that expression existing as part of an assignment and provide an appropriate suggestion:
```
error[E0599]: no method named `poll` found for type parameter `F` in the current scope
--> $DIR/pin-needed-to-poll-3.rs:19:28
|
LL | impl<F> Future for FutureWrapper<F>
| - method `poll` not found for this type parameter
...
LL | let res = self.fut.poll(cx);
| ^^^^ method not found in `F`
|
help: consider pinning the expression
|
LL ~ let mut pinned = std::pin::pin!(self.fut);
LL ~ let res = pinned.as_mut().poll(cx);
|
```
Fix#125661.
CI: Update riscv64gc-linux job to Ubuntu 22.04, rename to riscv64gc-gnu
Together with joshua.zivkovic@codethink.co.uk, we've been starting to explore improving the state of the `riscv64gc-unknown-linux-gnu` target. Additionally, I'm looking to add support for this platform in [Ferrocene](https://github.com/ferrocene/ferrocene) ([Related PR](https://github.com/ferrocene/ferrocene/pull/618)).
There currently exists a `src/ci/docker/host-x86_64/disabled/riscv64gc-linux` job for the CI, however it is currently experiencing errors.
<details>
<summary>Errors</summary>
```bash
$ DEPLOY=1 ./src/ci/docker/run.sh riscv64gc-linux
# ...
[RUSTC-TIMING] addr2line test:false 0.371
[RUSTC-TIMING] gimli test:false 3.159
[RUSTC-TIMING] object test:false 4.249
error: linking with `riscv64-linux-gnu-gcc` failed: exit status: 1
|
= note: LC_ALL="C" PATH="/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/bin:/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/bin:/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" VSLANG="1033" "riscv64-linux-gnu-gcc" "-Wl,--version-script=/tmp/rustcQaIpWi/list" "-Wl,--no-undefined-version" "/tmp/rustcQaIpWi/symbols.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/std-ff89a9732cd5d858.std.1b5d59225ff40bd2-cgu.0.rcgu.o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/std-ff89a9732cd5d858.dalhl7sfna1ffn4nhy6pyfa7f.rcgu.rmeta" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/std-ff89a9732cd5d858.ef0znsdf1ihn2bjkmclodhclp.rcgu.o" "-Wl,--as-needed" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/release/deps" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/build/compiler_builtins-9e9a40064e2f2bd3/out" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/libpanic_unwind-d968371aba64a26c.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/libobject-da5b6473912e89d6.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/libmemchr-9cfa08d2baa3643e.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/libaddr2line-06e0d2153cecb6ce.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/libgimli-6fdf5551cec83840.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/librustc_demangle-8ada6466f763fa2e.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/libstd_detect-edc0d12d029c4c86.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/libhashbrown-9c782935934c8c14.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/librustc_std_workspace_alloc-b6984e43b381efa4.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/libminiz_oxide-37ee29bf49ccaa96.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/libadler-591133f6804fa0f4.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/libunwind-94d98075f42175f3.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/libcfg_if-e267a7b9dd7af3a7.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/liblibc-503571a038f8d9fd.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/liballoc-e36c72a5cf0ee45f.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/librustc_std_workspace_core-076c2b8501e25f03.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/libcore-c446fff80486d0bb.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/libcompiler_builtins-26dc6b5e31e1fdb9.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/libstd-ff89a9732cd5d858.so" "-shared" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-nodefaultlibs" "-Wl,-z,origin" "-Wl,-rpath,$ORIGIN/../lib"
# ...
/usr/lib/gcc-cross/riscv64-linux-gnu/9/../../../../riscv64-linux-gnu/bin/ld: failed to merge target specific data of file /checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/libcompiler_builtins-26dc6b5e31e1fdb9.rlib(compiler_builtins-26dc6b5e31e1fdb9.compiler_builtins.74504a151a6bdbbf-cgu.124.rcgu.o)
/usr/lib/gcc-cross/riscv64-linux-gnu/9/../../../../riscv64-linux-gnu/bin/ld: -march=rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0: unsupported ISA subset `z'
/usr/lib/gcc-cross/riscv64-linux-gnu/9/../../../../riscv64-linux-gnu/bin/ld: failed to merge target specific data of file /checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/riscv64gc-unknown-linux-gnu/release/deps/libcompiler_builtins-26dc6b5e31e1fdb9.rlib(compiler_builtins-26dc6b5e31e1fdb9.compiler_builtins.74504a151a6bdbbf-cgu.004.rcgu.o)
collect2: error: ld returned 1 exit status
[RUSTC-TIMING] std test:false 15.138
error: could not compile `std` (lib) due to 1 previous error
Building bootstrap
Build completed unsuccessfully in 0:04:41
local time: Tue May 28 16:25:09 UTC 2024
network time: Tue, 28 May 2024 16:25:17 GMT
```
</details>
This PR fixes the breakage enough to get the tests running. It does so through bringing the `riscv64gc-unknown-linux-gnu` related test job in line with other related jobs, adopting many of the recent changes present in `src/ci/docker/host-x86_64/armhf-gnu` such as:
* Using Ubuntu 22.04
* Installing a more narrowly scoped package set
* Using `curl` instead of `debootstrap` to set up the root
* No longer patching `busybox`
* Removing the `cmake.sh` script related steps
## Justifying Renaming `riscv64gc-linux` to `riscv64gc-gnu`
The `src/ci/docker/host-x86_64/disabled/riscv64gc-linux` job runs the tests for `risv64gc-unknown-linux-gnu`, it is based off `src/ci/docker/host-x86_64/armhf-gnu`.
There are other jobs that follow a `$arch-gnu` naming scheme:
* `src/ci/docker/host-x86_64/armhf-gnu`
* `src/ci/docker/host-x86_64/x86_64-gnu`
* `src/ci/docker/host-aarch64/aarch64-gnu`
It follows that the name `src/ci/docker/host-x86_64/disabled/riscv64gc-linux` should be `src/ci/docker/host-x86_64/disabled/riscv64gc-gnu`, like the others.
## Testing
> [!NOTE]
> `riscv64gc-unknown-linux-gnu` is a [**Tier 2 with Host Tools** platform](https://doc.rust-lang.org/beta/rustc/platform-support.html), all tests may not necessarily pass! There is work in https://github.com/rust-lang/rust/pull/125220 which helps fix several related tests.
You can test out the renamed job:
```sh
DEPLOY=1 ./src/ci/docker/run.sh riscv64gc-gnu
```
`DEPLOY=1` helps reproduce the CI's environment and also avoids the chance of a `llvm-c/BitReader.h` error (detailed in https://github.com/rust-lang/rust/issues/85424 and https://github.com/rust-lang/rust/issues/56650).
<details>
<summary>Sample of output (expected test failure)</summary>
```bash
$ DEPLOY=1 ./src/ci/docker/run.sh riscv64gc-gnu
# ...
test [ui] tests/ui/where-clauses/where-clause-method-substituion-rpass.rs ... ok
failures:
---- [ui] tests/ui/debuginfo/debuginfo-emit-llvm-ir-and-split-debuginfo.rs stdout ----
error: test compilation failed although it shouldn't!
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/debuginfo/debuginfo-emit-llvm-ir-and-split-debuginfo.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2" "--target=riscv64gc-unknown-linux-gnu" "--check-cfg" "cfg(FALSE)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/debuginfo/debuginfo-emit-llvm-ir-and-split-debuginfo" "-A" "unused" "-A" "internal_features" "-Crpath" "-Lnative=/checkout/obj/build/riscv64gc-unknown-linux-gnu/native/rust-test-helpers" "-Clinker=riscv64-linux-gnu-gcc" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/debuginfo/debuginfo-emit-llvm-ir-and-split-debuginfo/auxiliary" "-g" "--emit=llvm-ir" "-Csplit-debuginfo=unpacked"
stdout: none
--- stderr -------------------------------
error: `-Csplit-debuginfo=unpacked` is unstable on this platform
error: aborting due to 1 previous error
------------------------------------------
failures:
[ui] tests/ui/debuginfo/debuginfo-emit-llvm-ir-and-split-debuginfo.rs
test result: FAILED. 5 passed; 1 failed; 16897 ignored; 0 measured; 0 filtered out; finished in 410.99ms
Some tests failed in compiletest suite=ui mode=ui host=x86_64-unknown-linux-gnu target=riscv64gc-unknown-linux-gnu
local time: Tue May 28 16:28:22 UTC 2024
network time: Tue, 28 May 2024 16:28:30 GMT
```
</details>
try-job: riscv64gc-gnu
Split core's PanicInfo and std's PanicInfo
`PanicInfo` is used in two ways:
1. As argument to the `#[panic_handler]` in `no_std` context.
2. As argument to the [panic hook](https://doc.rust-lang.org/stable/std/panic/fn.set_hook.html) in `std` context.
In situation 1, the `PanicInfo` always has a *message* (of type `fmt::Arguments`), but never a *payload* (of type `&dyn Any`).
In situation 2, the `PanicInfo` always has a *payload* (which is often a `String`), but not always a *message*.
Having these as the same type is annoying. It means we can't add `.message()` to the first one without also finding a way to properly support it on the second one. (Which is what https://github.com/rust-lang/rust/issues/66745 is blocked on.)
It also means that, because the implementation is in `core`, the implementation cannot make use of the `String` type (which doesn't exist in `core`): 0692db1a90/library/core/src/panic/panic_info.rs (L171-L172)
This also means that we cannot easily add a useful method like `PanicInfo::payload_as_str() -> Option<&str>` that works for both `&'static str` and `String` payloads.
I don't see any good reasons for these to be the same type, other than historical reasons.
---
This PR is makes 1 and 2 separate types. To try to avoid breaking existing code and reduce churn, the first one is still named `core::panic::PanicInfo`, and `std::panic::PanicInfo` is a new (deprecated) alias to `PanicHookInfo`. The crater run showed this as a viable option, since people write `core::` when defining a `#[panic_handler]` (because they're in `no_std`) and `std::` when writing a panic hook (since then they're definitely using `std`). On top of that, many definitions of a panic hook don't specify a type at all: they are written as a closure with an inferred argument type.
(Based on some thoughts I was having here: https://github.com/rust-lang/rust/pull/115561#issuecomment-1725830032)
---
For the release notes:
> We have renamed `std::panic::PanicInfo` to `std::panic::PanicHookInfo`. The old name will continue to work as an alias, but will result in a deprecation warning starting in Rust 1.82.0.
>
> `core::panic::PanicInfo` will remain unchanged, however, as this is now a *different type*.
>
> The reason is that these types have different roles: `std::panic::PanicHookInfo` is the argument to the [panic hook](https://doc.rust-lang.org/stable/std/panic/fn.set_hook.html) in std context (where panics can have an arbitrary payload), while `core::panic::PanicInfo` is the argument to the [`#[panic_handler]`](https://doc.rust-lang.org/nomicon/panic-handler.html) in no_std context (where panics always carry a formatted *message*). Separating these types allows us to add more useful methods to these types, such as `std::panic::PanicHookInfo::payload_as_str()` and `core::panic::PanicInfo::message()`.
Print `token::Interpolated` with token stream pretty printing.
This is a step towards removing `token::Interpolated` (#124141). It unavoidably changes the output of the `stringify!` macro, generally for the better.
r? `@petrochenkov`
run-make-support: add wrapper for `fs` operations
Suggested by #125728.
The point of this wrapper is to stop silent fails caused by forgetting to `unwrap` `fs` functions. However, functions like `fs::read` which return something and get stored in a variable should cause a failure on their own if they are not unwrapped (as the `Result` will be stored in the variable, and something will be done on that `Result` that should have been done to its contents). Is it still pertinent to wrap `fs::read_to_string`, `fs::metadata` and so on?
Closes: https://github.com/rust-lang/rust/issues/125728
try-job: x86_64-msvc
try-job: i686-mingw
