Rollup of 10 pull requests #110359
Closed
Rollup of 10 pull requests #110359
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Scott Schafer <scott@scottschafer.dev>
Co-authored-by: Slanterns <slanterns.w@gmail.com>
Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>
Co-authored-by: Nilstrieb <48135649+Nilstrieb@users.noreply.github.com>
Co-authored-by: Eric Huss <eric@huss.org>
Co-authored-by: est31 <est31@users.noreply.github.com>
Co-authored-by: Eric Huss <eric@huss.org>
It is allowed both in cargo and clippy's triagebot.toml, and nomination does not automatically mean that the PR will be backported.
The original motivation was me trying to remove the `#![allow(rustc::default_hash_types)]`, as after rust-lang#108626, we should be using `FxHashMap` here. I then realized I should also be able to remove the `.into_iter().collect()`, as we no longer need to convert from `FxHashMap` to `std::HashMap`. However, this didn't work, and I got the following error ``` error[E0308]: mismatched types --> src/librustdoc/json/mod.rs:235:13 | 235 | index, | ^^^^^ expected `rustc_hash::FxHasher`, found `FxHasher` | = note: `FxHasher` and `rustc_hash::FxHasher` have similar names, but are actually distinct types note: `FxHasher` is defined in crate `rustc_hash` --> /cargo/registry/src/index.crates.io-6f17d22bba15001f/rustc-hash-1.1.0/src/lib.rs:60:1 note: `rustc_hash::FxHasher` is defined in crate `rustc_hash` --> /home/alona/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustc-hash-1.1.0/src/lib.rs:60:1 | 60 | pub struct FxHasher { | ^^^^^^^^^^^^^^^^^^^ = note: perhaps two different versions of crate `rustc_hash` are being used? ``` This is because `librustdoc` got it's `FxHashMap` via the sysroot `rustc-data-strucures`, whereas `rustdoc-json-types` got it via `rustc-hash` on crates.io. To avoid this, `rustdoc-json-types` now uses `#![feature(rustc_private)]` to load the same version as `librustdoc`. However, this needs to be placed behind a feature, as `rustdoc-json-types` is also dependency of `src/tools/jsondocck`, which means need needs to be buildable without nightly features.
Previously, this would give an error because the shell script had a different working directory: ``` test: basic_install $ sh /home/jyn/src/rust/src/tools/rust-installer/gen-installer.sh --image-dir=/home/jyn/src/rust/src/tools/rust-installer/test/image1 --work-dir=/home/jyn/src/rust/build/x86_64-unknown-linux-gnu/test/rust-installer/workdir --output-dir=/home/jyn/src/rust/build/x86_64-unknown-linux-gnu/test/rust-installer/outdir /home/jyn/src/rust/src/tools/rust-installer/gen-installer.sh: 15: ../rust3/build/host/stage2-tools-bin/cargo: not found TEST FAILED! ```
rustdoc: use a template to generate Hrefs Previously, href always returned a string, so each link incurred at least one allocation. We were also using `"../".repeat()`, and `.collect()` into strings to generate part of the paths. This abstracts away those repetitions into a couple of helper structs, ParentDirectories and PathComponents, and puts them together into an `Href` template, which should save some allocations. As a side benefit, I think it makes the logic of constructing links a little clearer. This removes the only call sites for certain methods of UrlPartsBuilder, so it also removes those methods. Also, remove the ItemType return value from `href` and friends; it was basically unused. Part of rust-lang#108868
…lbini Add 1.69.0 release notes cc `@rust-lang/release` r? `@Mark-Simulacrum`
Use same `FxHashMap` in `rustdoc-json-types` and `librustdoc`. The original motivation was me trying to remove the `#![allow(rustc::default_hash_types)]`, as after rust-lang#108626, we should be using `FxHashMap` here. I then realized I should also be able to remove the `.into_iter().collect()`, as we no longer need to convert from `FxHashMap` to `std::HashMap`. However, this didn't work, and I got the following error ``` error[E0308]: mismatched types --> src/librustdoc/json/mod.rs:235:13 | 235 | index, | ^^^^^ expected `rustc_hash::FxHasher`, found `FxHasher` | = note: `FxHasher` and `rustc_hash::FxHasher` have similar names, but are actually distinct types note: `FxHasher` is defined in crate `rustc_hash` --> /cargo/registry/src/index.crates.io-6f17d22bba15001f/rustc-hash-1.1.0/src/lib.rs:60:1 note: `rustc_hash::FxHasher` is defined in crate `rustc_hash` --> /home/alona/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustc-hash-1.1.0/src/lib.rs:60:1 | 60 | pub struct FxHasher { | ^^^^^^^^^^^^^^^^^^^ = note: perhaps two different versions of crate `rustc_hash` are being used? ``` This is because `librustdoc` got it's `FxHashMap` via the sysroot `rustc-data-strucures`, whereas `rustdoc-json-types` got it via `rustc-hash` on crates.io. To avoid this, `rustdoc-json-types` now uses `#![feature(rustc_private)]` to load the same version as `librustdoc`. However, this needs to be placed behind a feature, as `rustdoc-json-types` is also dependency of `src/tools/jsondocck`, which means need needs to be buildable without nightly features. r? `@jyn514`
bootstrap: drop some windows features They became unused after rust-lang#109960
…unds, r=aliemjay fix: skip implied bounds if unconstrained lifetime exists Fixes rust-lang#110161 r? `@aliemjay`
…ed, r=Mark-Simulacrum Allow everyone to set the beta-nominated label It is allowed both in cargo and clippy's triagebot.toml, and nomination does not automatically mean that the PR will be backported.
Add intra-doc links to size_of_* functions Also some smaller doc improvements.
…albini Bump to Rust 1.71.0
Add a UI test for rust-lang#79605 rust-lang#79605 was fixed somewhere between December 2020 and now, but it did not have a UI test. This PR adds a UI test for the error.
…anonur Fix `x test rust-installer` when `cargo` is set to a relative path Previously, this would give an error because the shell script had a different working directory: ``` test: basic_install $ sh /home/jyn/src/rust/src/tools/rust-installer/gen-installer.sh --image-dir=/home/jyn/src/rust/src/tools/rust-installer/test/image1 --work-dir=/home/jyn/src/rust/build/x86_64-unknown-linux-gnu/test/rust-installer/workdir --output-dir=/home/jyn/src/rust/build/x86_64-unknown-linux-gnu/test/rust-installer/outdir /home/jyn/src/rust/src/tools/rust-installer/gen-installer.sh: 15: ../rust3/build/host/stage2-tools-bin/cargo: not found TEST FAILED! ```
rustbot
added
A-meta
|
Please don't rollup #110349, as rolling that up would break our infrastructure. |
|
Sorry, it was just the default behavior for the "create rollup" button when no PRs was selected. The confirmation messages clearly says it create a rollup of 0 PRs, yet it rolls up all approved ones. |
|
Oh no worries, didn't know bors behaved that way! We should fix that... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
FxHashMapinrustdoc-json-typesandlibrustdoc. #110051 (Use sameFxHashMapinrustdoc-json-typesandlibrustdoc.)E0121hint has duplicated type param with lifetime #79605)x test rust-installerwhencargois set to a relative path #110356 (Fixx test rust-installerwhencargois set to a relative path)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup