Skip to content

Conversation

aliemjay
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

cuviper and others added 28 commits April 6, 2023 17:41
Co-authored-by: Mark Rousskov <[email protected]>
Co-authored-by: Eric Huss <[email protected]>
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!
```
…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 labels Apr 15, 2023
@rustbot rustbot added 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
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Apr 15, 2023

📌 Commit 9176505 has been approved by aliemjay

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 15, 2023
@bors
Copy link
Collaborator

bors commented Apr 15, 2023

⌛ Testing commit 9176505 with merge 41cf10d122f0815cc310bdded4724823c5017ba7...

@bors
Copy link
Collaborator

bors commented Apr 15, 2023

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Apr 15, 2023
@aliemjay aliemjay closed this Apr 15, 2023
@aliemjay aliemjay deleted the rollup-omw6ktw branch April 15, 2023 15:50
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.

10 participants