[generator] Special cases for match guard when analyzing interior types in generators
Fix#72651
This proposes one of ways to fix the mentioned issue. One cause of #72651 is that the interior type analysis misses out types of match pattern locals. Those locals are manifested as temporary borrows in the scopes of match arm guards. If uses of these locals appear after yield points, the borrows from them were not considered live across the yield points. However, this is not the case since the borrowing always happens at the very beginning of the match guard.
This calls for special treatment to analysis of types appearing in the match guard. Those borrows are recorded as the HIR tree is walked by `InteriorVisitor` and their uses are recorded whenever a yield point is crossed.
Certain platforms need to limit the DWARF version emitted (oxs, *bsd). This
change adds a dwarf_version entry to the options that allows a platform to
specify the dwarf version to use. By default this option is none and the default
DWARF version is selected.
Also adds an option for printing Option<u32> json keys
Dist build manifest
This PR makes two changes that should remove a significant chunk of the time spent in our release process: cloning the `rust-lang/rust` monorepo, all its submodules, and building `bootstrap` to then invoke `build-manifest`:
* `build-manifest` doesn't rely on a clone of the monorepo being present anymore. The only remaining bit of information it fetched from it (the Rust version) is instead bundled in the binary.
* A new "component" is added, `build-manifest`. That component includes a prebuilt version of the tool, and it's *not* included in the Rustup manifest. This will allow `promote-release` to directly invoke the tool without interacting with our build system.
* The Linux x86_64 CI is changed to also build the component mentioned above. It's the only CI builder tasked to do so, and to cleanly support this a new `--include-default-paths` flag was added to `./x.py`.
* The `BUILD_MANIFEST_NUM_THREADS` environment variable is added to configure the number of threads at runtime.
This PR is best reviewed commit-by-commit.
r? `@Mark-Simulacrum`
ci: Fix riscv64gc linux test QEMU fault, plus doc link fix
Newer versions of the `qemu` package (used for riscv64gc-unknown-linux-gnu testing) don't work with the version of the RISC-V bootloader we were using. a4a0342cf5 bumps to a revision which should fix the problem.
e0b033e965 fixes a documentation failure I encountered while running the tests.
Stabilize slice_partition_at_index
This stabilizes slice_partition_at_index, including renaming `partition_at_index*` -> `select_nth_unstable*`.
Closes#55300
r? `@Amanieu`
rustdoc: skip #[allow(missing docs)] for docs in coverage report
During the document coverage reporting with:
```bash
rustdoc something.rs -Z unstable-options --show-coverage
```
the coverage report counts code that is marked with `#[allow(missing_docs)]` for the calculation, which outputs lower numbers in the coverage report even though these parts should be ignored for the calculation.
Right now I'm not sure how this can be tested (CI)? (I verified it by hand and ran the unit tests)
r? `@jyn514`
**Reference:** Fixes#76121
Use tracing spans in rustc_trait_selection
Spans are very helpful when debugging this code. It's also hot enough to make a good benchmark.
r? `@oli-obk`
Rollup of 10 pull requests
Successful merges:
- #77550 (add shims for WithOptConstParam query calls)
- #77699 (Add word wrap for short descriptions)
- #77724 (Implement `AsRawFd` for `StdinLock` etc. on WASI.)
- #77746 (Fix `x.py setup` sets `changelog-seen`)
- #77784 (Fix intra-docs link in core::ffi::VaList)
- #77811 (rustdoc: Make some functions private that don't need to be public)
- #77818 (Mono collector: replace pair of ints with Range)
- #77831 (Use std methods on char instead of open coding them)
- #77852 (update url in bootstrap README (gcc-rs -> cc-rs))
- #77863 (Remove `mark-i-m` from rustc-dev-guide maintainers)
Failed merges:
r? `@ghost`
Mono collector: replace pair of ints with Range
I found the initial PR (#33171) that introduced this piece of code but I didn't find any information about why a tuple was preferred over a `Range<usize>`.
I'm hoping there are no technical reasons to not do this.
