Add windows-targets crate to std's sysroot
With this PR, when backtrace is used as a crate from crates.io it will (once updated) use the real [windows-targets](https://crates.io/crates/windows-targets) crate. But when used from std it'll use std's replacement version.
This allows sharing our customized `windows_tagets::link!` macro between std proper and the backtrace crate when used as part of std, ensuring a consistent linking story. This will be especially important once we move to using [`raw-dylib`](https://doc.rust-lang.org/reference/items/external-blocks.html#dylib-versus-raw-dylib) by default.
Migrate `remap-path-prefix-dwarf` `run-make` test 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).
Possibly my proudest branch name yet.
try-job: aarch64-apple
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-gnu-llvm-18
Shrink `TyKind::FnPtr`.
By splitting the `FnSig` within `TyKind::FnPtr` into `FnSigTys` and `FnHeader`, which can be packed more efficiently. This reduces the size of the hot `TyKind` type from 32 bytes to 24 bytes on 64-bit platforms. This reduces peak memory usage by a few percent on some benchmarks. It also reduces cache misses and page faults similarly, though this doesn't translate to clear cycles or wall-time improvements on CI.
r? `@compiler-errors`
Greatly speed up doctests by compiling compatible doctests in one file
Fixes#75341.
Take 2 at https://github.com/rust-lang/rust/pull/123974. It should now be much simpler to review since it's based on https://github.com/rust-lang/rust/pull/125798.
I split the changes as much as possible to make it as easy as possible to review (even though it's a huge lot of code changes...).
The following tests are not included into the combined doctests:
* `compile_fail`
* If there are crate attributes (`deny`/`allow`/`warn` are ok)
* have invalid AST
* `test_harness`
* no capture
* `--show-output` (because the output is nicer without the extra code surrounding it)
Everything else is merged into one file. If this one file fails to compile, we go back to the current strategy: compile each doctest separately.
Because of the `edition` codeblock attribute, I couldn't make them all into one file directly so I grouped them by edition, but it should be pretty anecdotic.
In case the users want a specific doctest to be opted-out from this doctest merge, I added the `standalone` codeblock attribute:
```rust
/// ```rust,standalone
/// // This doctest will be run in its own process!
/// ```
```
Now the interesting part, I ran it on a few crates and here are the results (with `cargo test --doc` to only include doctests):
| crate | nb doctests | before this PR | with this PR |
| - | - | - | - |
| sysinfo | 227 | 4.6s | 1.11s |
| geos | 157 | 3.95s | 0.45s |
| core | 4604 | 54.08s | 13.5s (merged: 0.9s, standalone: 12.6s) |
| std | 1147 | 12s | 3.56s (merged: 2.1s, standalone: 1.46s) |
r? `@camelid`
try-job: x86_64-msvc
try-job: aarch64-apple
Fix one usage of target triple in bootstrap
This bug was introduced in https://github.com/rust-lang/rust/pull/128983. In this one case, the `TargetSelection` was also used as `Display` (not just as `Path`), which I did not notice in the original PR. If the target contained a custom file, it would be included in its `Display` formatting, even though only the triple should be used.
Found [here](https://github.com/rust-lang/rust/pull/128983#issuecomment-2286601889).
r? `@onur-ozkan`
Emit a warning instead of an error if `--generate-link-to-definition` is used with other output formats than HTML
Fixes https://github.com/rust-lang/docs.rs/issues/2581.
It's a bit weird to emit an error in this case anyway, a warning is more than enough.
r? ``@notriddle``
compiletest: Don't panic on unknown JSON-like output lines
The `json::extract_rendered` function is called for both compiler output and non-compiler output, so it's inappropriate to panic just because a line starting with `{` didn't contain a compiler output message.
It is called from two places: when checking the output of a `ui` test process, and when printing the output of an arbitrary non-passing `ProcRes`. So unfortunately there's currently no easy way to know for sure whether it is seeing compiler output or not. Fortunately, neither call site appears to be relying on this panic; it's just an overzealous internal check.
Fixes#126373.
Add `#[must_use]` attribute to `Coroutine` trait
[Coroutines tracking issue](https://github.com/rust-lang/rust/issues/43122)
Like closures (`FnOnce`, `AsyncFn`, etc.), coroutines are lazy and do nothing unless called (resumed). Closure traits like `FnOnce` have `#[must_use = "closures are lazy and do nothing unless called"]` to catch likely bugs for users of APIs that produce them. This PR adds such a `#[must_use]` attribute to `trait Coroutine`.
Allow to customize `// TODO:` comment for deprecated safe autofix
Relevant for the deprecation of `CommandExt::before_exit` in #125970.
Tracking:
- #124866
Optimize integer `pow` by removing the exit branch
The branch at the end of the `pow` implementations is redundant with multiplication code already present in the loop. By rotating the exit check, this branch can be largely removed, improving code size and reducing instruction cache misses.
Testing on my machine (`x86_64`, 11th Gen Intel Core i5-1135G7 @ 2.40GHz), the `num::int_pow` benchmarks improve by some 40% for the unchecked operations and show some slight improvement for the checked operations as well.
