rustdoc: render generic params & where-clauses of cross-crate assoc tys in impls
We used to only ever render generic parameters & where-clauses of cross-crate associated types when the item was located inside of a trait and we used to just drop them when it was inside of an impl block (trait or inherent).
Fixes#112904.
`@rustbot` label A-cross-crate-reexports
remove unused field
Followup to #104455. The field is no longer needed since ExtractIf (previously DrainFilter) doesn't keep draining in its drop impl.
`hir`: Add `Become` expression kind (explicit tail calls experiment)
This adds `hir::ExprKind::Become` alongside ast lowering. During hir-thir lowering we currently lower `become` as `return`, so that we can partially test `become` without ICEing.
cc `@scottmcm`
r? `@Nilstrieb`
Switch some more Steps to `builder.msg`
In particular, this hides compiletest suites under a dropdown - some builders are configured with `verbose-tests`, which makes the suites take up many thousands of lines.
before:
```
Documenting stage1 cargo (x86_64-unknown-linux-gnu)
Check compiletest suite=rustdoc-js mode=js-doc-test (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
```
after:
```
::group::Documenting stage1 cargo (x86_64-unknown-linux-gnu)
::group::Testing stage1 compiletest suite=rustdoc-js mode=js-doc-test (x86_64-unknown-linux-gnu)
```
found this from https://github.com/rust-lang-ci/rust/actions/runs/5366993848/jobs/9736792611
r? `@oli-obk`
doc: loongarch: Update maintainers
My colleague, `@zhaixiaojuan,` has been completely occupied with other matters and is no longer in charge of Rust. Consequently, I intend to update the maintainers in the platform documentation to avoid causing any disruptions for her and to ensure that relevant notifications regarding LoongArch are promptly directed to the appropriate developers.
Thanks your for contributions!
rust-installer: migrate to clap 4.2, change to 2021 edition and fix few clippy lints
Updated rust-installer to clap 4.2, dropping last user of clap v3; changes to 2021 edition, fixes few clippy warns.
Specialize `StepBy<Range<{integer}>>`
OLD
iter::bench_range_step_by_fold_u16 700.00ns/iter +/- 10.00ns
iter::bench_range_step_by_fold_usize 519.00ns/iter +/- 6.00ns
iter::bench_range_step_by_loop_u32 555.00ns/iter +/- 7.00ns
iter::bench_range_step_by_sum_reducible 37.00ns/iter +/- 0.00ns
NEW
iter::bench_range_step_by_fold_u16 49.00ns/iter +/- 0.00ns
iter::bench_range_step_by_fold_usize 194.00ns/iter +/- 1.00ns
iter::bench_range_step_by_loop_u32 98.00ns/iter +/- 0.00ns
iter::bench_range_step_by_sum_reducible 1.00ns/iter +/- 0.00ns
NEW + `-Ctarget-cpu=x86-64-v3`
iter::bench_range_step_by_fold_u16 22.00ns/iter +/- 0.00ns
iter::bench_range_step_by_fold_usize 80.00ns/iter +/- 1.00ns
iter::bench_range_step_by_loop_u32 41.00ns/iter +/- 0.00ns
iter::bench_range_step_by_sum_reducible 1.00ns/iter +/- 0.00ns
I have only optimized for walltime of those methods, I haven't tested whether it eliminates bounds checks when indexing into slices via things like `(0..slice.len()).step_by(16)`.
Rollup of 5 pull requests
Successful merges:
- #112976 (Add test for futures with HRTB)
- #113013 (rustdoc: get rid of extra line when line-wrapping fn decls with empty arg list)
- #113030 (Add a regression test for #109071)
- #113031 (Add a regression test for #110933)
- #113036 (Accept `ReStatic` for RPITIT)
r? `@ghost`
`@rustbot` modify labels: rollup
CI: do not run Bump dependencies workflow on forks
I haven't found a prettier way of doing this. We can possibly only use the condition on the `pr` job (to just disallow the creation of the PR), or only on the `not-waiting-on-bors` step, as if it doesn't run, the following job (probably) also shouldn't run.
Fixes: https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/.22Weekly.20cargo.20update.22.20on.20forks
r? `@Mark-Simulacrum`
rustdoc: handle assoc const equalities in cross-crate impl-Trait-in-arg-pos
Fixes FIXME (the added test previously lead to an ICE).
`@rustbot` label A-cross-crate-reexports
Test the cargo args generated by bootstrap.py
I recommend reviewing this commit-by-commit using the instructions in https://rustc-dev-guide.rust-lang.org/git.html#moving-large-sections-of-code.
- Test cargo arguments passed by bootstrap.py
This moves a lot of code around, but the logic itself is not too terribly complicated.
- Move almost all logic in `def bootstrap` to the `RustBuild` class, to avoid mixing setting configuration with running commands
- Update various doctests to the new (more complete) RustBuild config. In particular, don't pretend that `bin_root` supports `build` being unset.
- Change `parse_args` not to use a global, to allow testing it
- Set BUILD_DIR appropriately so bootstrap.py doesn't panic because cargo isn't found
- Allow passing arguments to `bootstrap_test.py`
Previous, it used the built-in test runner, which doesn't support options unless they're manually passed in the script.
- Fix progress messages for configure in bootstrap_test.py
Before it would unconditionally print `configure-args = []`.
r? `@albertlarsan68` cc https://github.com/rust-lang/rust/pull/112089https://github.com/rust-lang/rust/pull/111979#issuecomment-1568525699
In particular, this hides compiletest suites under a dropdown - some builders are configured with `verbose-tests`, which makes the suites take up many thousands of lines.
before:
```
Documenting stage1 cargo (x86_64-unknown-linux-gnu)
Check compiletest suite=rustdoc-js mode=js-doc-test (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
```
after:
```
::group::Documenting stage1 cargo (x86_64-unknown-linux-gnu)
::group::Testing stage1 compiletest suite=rustdoc-js mode=js-doc-test (x86_64-unknown-linux-gnu)
```
Revert "Structurally resolve correctly in check_pat_lit"
This reverts commit 54fb5a48b9. Also adds a couple of tests, and downgrades the existing `-Ztrait-solver=next` test to a known-bug.
Fixes#112993
Move windows-sys arm32 shim to c.rs
This moves the arm32 shim in to c.rs instead of appending to the generated file itself.
This makes it simpler to change these workarounds if/when needed. The downside is we need to exclude a couple of functions from being generated (see the comment). A metadata solution could help here but they'll be easy enough to add back if that happens.
Matthias Krüger