Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 10 pull requests #110359

Closed
wants to merge 32 commits into from
Closed

Conversation

aliemjay
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

jsha and others added 30 commits April 4, 2023 22:36
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.
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 rustbot added A-meta Area: Issues & PRs about the rust-lang/rust repository itself A-rustdoc-json Area: Rustdoc JSON backend S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-release Relevant to the release subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Apr 15, 2023
@aliemjay aliemjay closed this Apr 15, 2023
@aliemjay aliemjay deleted the rollup-gldpxm5 branch April 15, 2023 14:11
@pietroalbini
Copy link
Member

Please don't rollup #110349, as rolling that up would break our infrastructure.

@aliemjay
Copy link
Member Author

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.

@pietroalbini
Copy link
Member

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
Labels
A-meta Area: Issues & PRs about the rust-lang/rust repository itself A-rustdoc-json Area: Rustdoc JSON backend rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-release Relevant to the release subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.