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 5 pull requests #110073

Closed
wants to merge 10 commits into from
Closed

Conversation

notriddle
Copy link
Contributor

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

notriddle and others added 10 commits April 6, 2023 16:25
* Stop checking `func` in `onEach`. It's always hard-coded right
  at the call site, so there's no point.
* Use the ternary operator in a few spots where it makes sense.
* No point in making `onEach` store `arr.length` in a variable if
  it's only used once anyway.
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.
I'm going to be unable to review for the next few weeks, so I'm
removing myself from the review queue. Once I'm back and able to review
again, I'll add myself back to the list.
…=GuillaumeGomez

rustdoc: clean up JS

* Stop checking `func` in `onEach`. It's always hard-coded right at the call site, so there's no point.
* Use the ternary operator in a few spots where it makes sense.
* No point in making `onEach` store `arr.length` in a variable if it's only used once anyway.
… r=GuillaumeGomez

rustdoc: add test and bug fix for theme defaults

Part of rust-lang#66181
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`
Fix wrong type in docs: i16 -> u16

`@rustbot` label +A-docs

r? docs
…iser

Temporarily remove myself from reviewers list

I'm going to be unable to review for the next few weeks, so I'm removing myself from the review queue. Once I'm back and able to review again, I'll add myself back to the list.

r? `@wesleywiser`
@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-libs Relevant to the library team, 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 8, 2023
@notriddle
Copy link
Contributor Author

@bors r+ p=5

@bors
Copy link
Contributor

bors commented Apr 8, 2023

📌 Commit a33fbd8 has been approved by notriddle

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 8, 2023
@bors
Copy link
Contributor

bors commented Apr 8, 2023

⌛ Testing commit a33fbd8 with merge 5a689a6ba409b35beba8ef95b0b2dddeea0c2e7f...

@bors
Copy link
Contributor

bors commented Apr 8, 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 8, 2023
@rust-log-analyzer
Copy link
Collaborator

The job dist-armhf-linux failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[RUSTC-TIMING] serde test:false 3.448
[RUSTC-TIMING] basic_toml test:false 0.638
   Compiling askama_derive v0.12.1
   Compiling rustdoc-json-types v0.1.0 (/checkout/src/rustdoc-json-types)
error[E0464]: multiple candidates for `rmeta` dependency `rustc_hash` found
  |
8 | extern crate rustc_hash;
  | ^^^^^^^^^^^^^^^^^^^^^^^^
  |
  |
  = note: candidate #1: /checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/arm-unknown-linux-gnueabihf/lib/librustc_hash-2127386464b12f48.rmeta
  = note: candidate #2: /checkout/obj/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/arm-unknown-linux-gnueabihf/lib/librustc_hash-6142df8766dda1c3.rmeta
[RUSTC-TIMING] serde test:false 3.710
[RUSTC-TIMING] basic_toml test:false 0.700
For more information about this error, try `rustc --explain E0464`.
[RUSTC-TIMING] rustdoc_json_types test:false 0.946

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-libs Relevant to the library team, 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.

6 participants