rustdoc: fix & clean up handling of cross-crate higher-ranked parameters
Preparatory work for the refactoring planned in #113015 (for correctness & maintainability).
---
1. Render the higher-ranked parameters of cross-crate function pointer types **(*)**.
2. Replace occurrences of `collect_referenced_late_bound_regions()` (CRLBR) with `bound_vars()`.
The former is quite problematic and the use of the latter allows us to yank a lot of hacky code **(†)**
as you can tell from the diff! :)
3. Add support for cross-crate higher-ranked types (`#![feature(non_lifetime_binders)]`).
We were previously ICE'ing on them (see `inline_cross/non_lifetime_binders.rs`).
---
**(*)**: Extracted from test `inline_cross/fn-type.rs`:
```diff
- fn(_: &'z fn(_: &'b str), _: &'a ()) -> &'a ()
+ for<'z, 'a, '_unused> fn(_: &'z for<'b> fn(_: &'b str), _: &'a ()) -> &'a ()
```
**(†)**: It returns an `FxHashSet` which isn't *predictable* or *stable* wrt. source code (`.rmeta`) changes. To elaborate, the ordering of late-bound regions doesn't necessarily reflect the ordering found in the source code. It does seem to be stable across compilations but modifying the source code of the to-be-documented crates (like adding or renaming items) may result in a different order:
<details><summary>Example</summary>
Let's assume that we're documenting the cross-crate re-export of `produce` from the code below. On `master`, rustdoc would render the list of binders as `for<'x, 'y, 'z>`. However, once you add back the functions `a`–`l`, it would be rendered as `for<'z, 'y, 'x>` (reverse order)! Results may vary. `bound_vars()` fixes this as it returns them in source order.
```rs
// pub fn a() {}
// pub fn b() {}
// pub fn c() {}
// pub fn d() {}
// pub fn e() {}
// pub fn f() {}
// pub fn g() {}
// pub fn h() {}
// pub fn i() {}
// pub fn j() {}
// pub fn k() {}
// pub fn l() {}
pub fn produce() -> impl for<'x, 'y, 'z> Trait<'z, 'y, 'x> {}
pub trait Trait<'a, 'b, 'c> {}
impl Trait<'_, '_, '_> for () {}
```
</details>
Further, as the name suggests, CRLBR only collects *referenced* regions and thus we drop unused binders. `bound_vars()` contains unused binders on the other hand. Let's stay closer to the source where possible and keep unused binders.
Lastly, using `bound_vars()` allows us to get rid of
* the deduplication and alphabetical sorting hack in `simplify.rs`
* the weird field `bound_params` on `EqPredicate`
both of which were introduced by me in #102707 back when I didn't know better.
To illustrate, let's look at the cross-crate bound `T: for<'a, 'b> Trait<A<'a> = (), B<'b> = ()>`.
* With CRLBR + `EqPredicate.bound_params`, *before* bounds simplification we would have the bounds `T: Trait`, `for<'a> <T as Trait>::A<'a> == ()` and `for<'b> <T as Trait>::B<'b> == ()` which required us to merge `for<>`, `for<'a>` and `for<'b>` into `for<'a, 'b>` in a deterministic manner and without introducing duplicate binders.
* With `bound_vars()`, we now have the bounds `for<'a, b> T: Trait`, `<T as Trait>::A<'a> == ()` and `<T as Trait>::B<'b> == ()` before bound simplification similar to rustc itself. This obviously no longer requires any funny merging of `for<>`s. On top of that `for<'a, 'b>` is guaranteed to be in source order.
bootstrap: make copying linker binaries conditional
The change in #116276 breaks bootstrapping if you don't use `lld` for linking with your stage0 compiler. Making this copy conditional should be enough to fix it.
add notes about non-compliant FP behavior on 32bit x86 targets
Based on ton of prior discussion (see all the issues linked from https://github.com/rust-lang/unsafe-code-guidelines/issues/237), the consensus seems to be that these targets are simply cursed and we cannot implement the desired semantics for them. I hope I properly understood what exactly the extent of the curse is here, let's make sure people with more in-depth FP knowledge take a close look!
In particular for the tier 3 targets I have no clue which target is affected by which particular variant of the x86_32 FP curse. I assumed that `i686` meant SSE is used so the "floating point return value" is the only problem, while everything lower (`i586`, `i386`) meant x87 is used.
I opened https://github.com/rust-lang/rust/issues/114479 to concisely describe and track the issue.
Cc `@workingjubilee` `@thomcc` `@chorman0773` `@rust-lang/opsem`
Fixes https://github.com/rust-lang/rust/issues/73288
Fixes https://github.com/rust-lang/rust/issues/72327
Print GHA log groups to stdout instead of stderr
In all other places (e.g. `bootstrap.py`, `opt-dist`), we use stdout instead of stderr. I think that using stderr might be causing some discrepancies in the log, where sometimes the contents of a group "leak" outside the group. Let's see what happens if we use stdout instead. It's possible that it will be worse, since we print most stuff to stderr (?).
r? `@ghost`
bootstrap: copy self-contained linking components to `stage0-sysroot`
I hit this issue while trying to bootstrap using a rustc where `rust-lld` is used by default: this was the cause of the failure to profile rustc-perf's bootstrap benchmark in https://github.com/rust-lang/rust/pull/113382.
`stage0-sysroot` currently only has libs and self-contained objects, not the other self-contained linking components yet. Most notably, it does not contain the linker and wrappers that we build, and that rustup distributes.
If you try to bootstrap using the bootstrap compiler's `rust-lld`, it will fail to link std at stage0 because `rust-lld` and the `gcc-ld` wrappers, will not be found in `stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/bin`.
This PR copies the `bin` directory next to the `lib` directory when `rust.lld` is enabled in the config (though maybe it could be done unconditionally, the fact that we need it to link does not necessarily mean that we'd want to build and provide it at stage1).
cc `@Kobzol` who also encountered this issue while using lld during bootstrap.
bootstrap major change detection implementation
The use of `changelog-seen` and `bootstrap/CHANGELOG.md` has not been functional in any way for many years. We often do major/breaking changes but never update the changelog file or the `changelog-seen`. This is an alternative method for tracking major or breaking changes and informing developers when such changes occur.
Example output when bootstrap detects a major change:
Stdio support for UEFI
- Uses Simple Text Output Protocol and Simple Text Input Protocol
- Reading is done one character at a time
- Writing is done with max 4096 characters
# Quirks
## Output Newline
- UEFI uses CRLF for newline. So when running the application in UEFI shell (qemu VGA), the output of `println` looks weird.
- However, since the UEFI shell supports piping output, I am unsure if doing any output post-processing is a good idea. UEFI shell `cat` command seems to work fine with just LF.
## Input Newline
- `Stdin.read_line()` method is broken in UEFI shell. Pressing enter seems to be read as CR, which means LF is never encountered.
- Works fine with input redirection from file.
CC `@dvdhrm`
Build `rustc` with a single CGU on x64 Linux
This PR adds the `rust.codegen-units=1` setting when compiling the 64-bit Linux `rustc` artifact (the one used for try builds and Linux rustup distribution). This had mixed results in the past, however after the bump to LLVM 17, the results now seem pretty [incredible](https://github.com/rust-lang/rust/pull/115554#issuecomment-1706518199). Instruction counts, cycles, wall time, max RSS and even artifact sizes see large improvements.
The last [try build](https://github.com/rust-lang-ci/rust/actions/runs/6077686494/job/16487768049) with this setting took 1h 8m, which is basically the same duration for try builds that we have seen recently. So there shouldn't be any large hit to CI/build time.
I hope that this could potentially also reduce codegen noise of `rustc` a little bit, since small changes within a single `rustc` crate should no longer perturb optimizations because of CGU movement. We still do cross-crate LTO, so it won't eliminate it though.
r? `@Mark-Simulacrum`
otherwise bootstrap will fail to link the stdlib on a target using the
self-contained linker: rust-lld will not be found since it's currently
not in the stage0-sysroot.
Update location of `auxiliary/lint-plugin-test.rs`
**PR Summary**:
PR updates the location of `auxiliary/lint-plugin-test.rs` file which was moved in PR #110478.
warn if source is not either a git clone or a dist tarball
When the repository is downloaded directly via HTTP(as in #115041), builds may fail due to missing submodules.
This PR adds a check that warns people in such cases.
Partially outline code inside the panic! macro
This outlines code inside the panic! macro in some cases. This is split out from https://github.com/rust-lang/rust/pull/115562 to exclude changes to rustc.
Add integration for new bors
I think that the best way to test the [new bors](https://github.com/rust-lang/bors/tree/staging) implementation is to start using it in the wild. This PR integrates this repo with the bot (some more integration has to be done externally through GitHub). For now, I would suggest to integrate it e.g. under the ``@borsnew`` name, and start testing its try build functionality. The bot cannot do merges or approvals yet, and it doesn't touch `master` in any way, so hopefully it shouldn't cause any troubles for this repo.
r? `@Mark-Simulacrum`
Pass `-jN` from Make to `BOOTSTRAP_ARGS`
Enables the same functionality as `x -jN` in Make by passing the `-jN` arg from Make to the `BOOTSTRAP_ARGS` if it is specified.
Assorted improvements for `rustc_middle::mir::traversal`
r? `@cjgillot`
I'm not _entirely_ sure about all changes, although I do like all of them. If you'd like I can drop some commits. Best reviewed on a commit-by-commit basis, I think, since they are fairly isolated.
rustdoc: speed up processing of cross-crate fns to fix a perf regression
* The first commit doesn't affect perf but get's rid of a `.clone()` and a bunch of lines of code. I can drop it if you'd like me to
* The second commit, *“reduce the amount of `asyncness` query executions”*, addresses the perf regression introduced in #116084
r? `@ghost`
Prototype using const generic for simd_shuffle IDX array
cc https://github.com/rust-lang/rust/issues/85229
r? `@workingjubilee` on the design
TLDR: there is now a `fn simd_shuffle_generic<T, U, const IDX: &'static [u32]>(x: T, y: T) -> U;` intrinsic that allows replacing
```rust
simd_shuffle(a, b, const { stuff })
```
with
```rust
simd_shuffle_generic::<_, _, {&stuff}>(a, b)
```
which makes the compiler implementations much simpler, if we manage to at some point eliminate `simd_shuffle`.
There are some issues with this today though (can't do math without bubbling it up in the generic arguments). With this change, we can start porting the simple cases and get better data on the others.
