Rollup of 3 pull requests
Successful merges:
- #130485 (Do not expect infer/bound/placeholder/error in v0 symbol mangling)
- #130567 (Register tool docs for compiletest)
- #130582 (rustdoc: use the correct span for doctests)
r? `@ghost`
`@rustbot` modify labels: rollup
Register tool docs for compiletest
This PR registers tool docs for `src/tools/compiletest`, meaning that
```
$ ./x doc src/tools/compiletest
```
or
```
$ ./x doc compiletest
```
will now generate docs, like for `run-make-support`.
Fixes#130564.
Do not expect infer/bound/placeholder/error in v0 symbol mangling
Infer/bound/placeholder/error are not encounterable during codegen. Let's make sure v0 symbol mangling doesn't "accidentally" handle them.
As for aliases (namely: projections and uv consts) these may still be encounterable because of the way that we render the def paths of items. Specifically, when we have something like:
```
struct W<T>(T);
impl<T> W<T> {
fn x() {
fn y() {}
}
}
```
The path of `y` is rendered like `crate_name::W<T>:❌:y`. Specifically, since `y` doesn't inherit the generics of the impl, we use the *identity* substitutions for that impl. If the impl has any aliases, they will remain unnormalized if they're rigid.
r? `@BoxyUwU`
[perf] skip normalizing param env if it is already normalized
If the param env is already normalized after elaboration, then we can skip a bunch of expensive operations.
> [!note]
> This makes it so that outlives predicates are no longer sorted after non-outlives predicates. Surely this won't make a semantic difference.
r? ghost
Rollup of 5 pull requests
Successful merges:
- #128001 (Improve documentation for <integer>::from_str_radix)
- #130553 ([Clippy] Get rid of most `std` `match_def_path` usage, swap to diagnostic items.)
- #130554 (`pal::unsupported::process::ExitCode`: use an `u8` instead of a `bool`)
- #130556 (Mark the `link_cfg` feature as internal)
- #130558 (Support 128-bit atomics on s390x)
r? `@ghost`
`@rustbot` modify labels: rollup
Mark the `link_cfg` feature as internal
This PR marks the `link_cfg` feature as internal because it's a perme-unstable feature, only used by `core`/`std`and `unwind`.
`pal::unsupported::process::ExitCode`: use an `u8` instead of a `bool`
`ExitCode` should “represents the status code the current process can return to its parent under normal termination”, but is currently represented as a `bool` on unsupported platforms, making the `impl From<u8> for ExitCode` lossy.
Fixes#130532.
History: [IRLO thread](https://internals.rust-lang.org/t/mini-pre-rfc-redesigning-process-exitstatus/5426) (`ExitCode` as a `main` return), #48618 (initial impl), #93445 (`From<u8>` impl).
[Clippy] Get rid of most `std` `match_def_path` usage, swap to diagnostic items.
Part of https://github.com/rust-lang/rust-clippy/issues/5393.
This was going to remove all `std` paths, but `SeekFrom` has issues being cleanly replaced with a diagnostic item as the paths are for variants, which currently cannot be diagnostic items.
This also, as a last step, categories the paths to help with future path removals.
Improve documentation for <integer>::from_str_radix
Two improvements to the documentation:
- Document `-` as a valid character for signed integer destinations
- Make the documentation even more clear that extra whitespace and non-digit characters is invalid. Many other languages, e.g. c++, are very permissive in string to integer routines and simply try to consume as much as they can, ignoring the rest. This is trying to make the transition for developers who are used to the conversion semantics in these languages a bit easier.
Stabilize const `MaybeUninit::as_mut_ptr`
This PR stabilizes the following APIs as const stable as of rust `1.83`:
```rs
impl<T> MaybeUninit<T> {
pub const fn as_mut_ptr(&mut self) -> *mut T;
}
```
This is made possible by const_mut_refs being stabilized (yay).
FCP: #75251 [(comment)](https://github.com/rust-lang/rust/issues/75251#issuecomment-2356197443)
Never patterns constitute a read for unsafety
This code is otherwise unsound if we don't emit an unsafety error here. Noticed when fixing #130528, but it's totally unrelated.
r? `@Nadrieril`
