Rollup of 6 pull requests
Successful merges:
- #127092 (Change return-type-notation to use `(..)`)
- #127184 (More refactorings to rustc_interface)
- #127190 (Update LLVM submodule)
- #127253 (Fix incorrect suggestion for extra argument with a type error)
- #127280 (Disable rmake test rustdoc-io-error on riscv64gc-gnu)
- #127294 (Less magic number for corountine)
r? `@ghost`
`@rustbot` modify labels: rollup
Disable rmake test rustdoc-io-error on riscv64gc-gnu
In https://github.com/rust-lang/rust/pull/126917 we disabled `inaccessible-temp-dir` on `riscv64gc-gnu` because the container runs the build as `root` (just like the `armhf-gnu` builds). Tests creating an inaccessible test directory are not possible, since `root` can always touch those directories.
553a69030e/src/ci/docker/host-x86_64/disabled/riscv64gc-gnu/Dockerfile (L99)
This means the tests are run as `root`. As `root`, it's perfectly normal and reasonable to violate permission checks this way:
```bash
$ sudo mkdir scratch
$ sudo chmod o-w scratch
$ sudo mkdir scratch/backs
$
```
Because of this, this PR makes the test ignored on `riscv64gc` (just like on `armhf-gnu`) for now.
As an alternative, I believe the best long-term strategy would be to not run the tests as `root` for this job. Some preliminary exploration was done in https://github.com/rust-lang/rust/pull/126917#issuecomment-2189933970, however that appears a larger lift.
## 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! This change should only ignore `inaccessible-temp-dir` and not affect other tests.
You can test out the job locally:
```sh
DEPLOY=1 ./src/ci/docker/run.sh riscv64gc-gnu
```
r? `@jieyouxu`
linker: Link dylib crates by path
Linkers seem to support linking dynamic libraries by path.
Not sure why the previous scheme with splitting the path into a directory (passed with `-L`) and a name (passed with `-l`) was used (upd: likely due to https://github.com/rust-lang/rust/pull/126094#issuecomment-2155063414).
When we split a library path `some/dir/libfoo.so` into `-L some/dir` and `-l foo` we add `some/dir` to search directories for *all* libraries looked up by the linker, not just `foo`, and `foo` is also looked up in *all* search directories not just `some/dir`.
Technically we may find some unintended libraries this way.
Therefore linking dylibs via a full path is both simpler and more reliable.
It also makes the set of search directories more easily reproducible when we need to lookup some native library manually (like in https://github.com/rust-lang/rust/pull/123436).
Migrate `volatile-intrinsics`, `weird-output-filenames`, `wasm-override-linker`, `wasm-exceptions-nostd` to `rmake`
Also refactors `wasm-abi` and `compressed-debuginfo`.
Part of #121876.
r? ``@jieyouxu``
try-job: x86_64-gnu-debug
try-job: dist-various-2
Stabilize `PanicInfo::message()` and `PanicMessage`
Resolves#66745
This stabilizes the [`PanicInfo::message()`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicInfo.html#method.message) and [`PanicMessage`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicMessage.html).
Demonstration of [custom panic handler](https://github.com/StackOverflowExcept1on/panicker):
```rust
#![no_std]
#![no_main]
extern crate libc;
#[no_mangle]
extern "C" fn main() -> libc::c_int {
panic!("I just panic every time");
}
#[panic_handler]
fn my_panic(panic_info: &core::panic::PanicInfo) -> ! {
use arrayvec::ArrayString;
use core::fmt::Write;
let message = panic_info.message();
let location = panic_info.location().unwrap();
let mut debug_msg = ArrayString::<1024>::new();
let _ = write!(&mut debug_msg, "panicked with '{message}' at '{location}'");
if debug_msg.try_push_str("\0").is_ok() {
unsafe {
libc::puts(debug_msg.as_ptr() as *const _);
}
}
unsafe { libc::exit(libc::EXIT_FAILURE) }
}
```
```
$ cargo +stage1 run --release
panicked with 'I just panic every time' at 'src/main.rs:8:5'
```
- [x] FCP: https://github.com/rust-lang/rust/issues/66745#issuecomment-2198143725
r? libs-api
Add a run-make test that LLD is not being used by default on the x64 beta/stable channel
https://github.com/rust-lang/rust/pull/126701 showed that the handling of `lld` in bootstrap is currently not ideal. While it would be nice to refactor it eventually, we should also make sure that we have a test that checks that `lld` is not used (yet!) by default on the x64 Linux stable channel.
CC ``@lqd``
r? ``@onur-ozkan``
Migrate `run-make/override-aliased-flags` to `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
I voluntarily didn't use the helper methods to make it obvious what's tested.
r? `@jieyouxu`
Migrate `pdb-alt-path`, `mismatching-target-triples` and `mingw-export-call-convention` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Needs MSVC try jobs.
try-job: x86_64-mingw
try-job: x86_64-msvc
Migrate `unknown-mod-stdin`, `issue-68794-textrel-on-minimal-lib`, `raw-dylib-cross-compilation` and `used-cdylib-macos` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Seriously needs OSX/Windows try-jobs. If it fails, restore `only-linux` in `textrel-on-minimal-lib` and try again.
try-job: x86_64-mingw
try-job: x86_64-msvc
