Commit Graph

261 Commits

Author SHA1 Message Date
David Tolnay
6a02e20fb5
Update since stability attributes in tests 2023-10-23 13:04:47 -07:00
David Tolnay
01b909174b
Fix stable feature names in tests 2023-10-23 13:03:11 -07:00
Michael Howell
94b39e8c86 rustdoc: move ICE test to rustdoc-ui 2023-10-16 18:02:11 -07:00
Michael Howell
43b493ebc0 Add URL to test cases 2023-10-16 18:01:02 -07:00
Michael Howell
69dc19043b Rename issue-\d+.rs tests to have meaningful names 2023-10-16 18:01:02 -07:00
Michael Howell
df5ea58287 Add crate_name to test so that it can be renamed 2023-10-16 15:41:04 -07:00
Matthias Krüger
4dd4d9b489
Rollup merge of #115439 - fmease:rustdoc-priv-repr-transparent-heuristic, r=GuillaumeGomez
rustdoc: hide `#[repr(transparent)]` if it isn't part of the public ABI

Fixes #90435.

This hides `#[repr(transparent)]` when the non-1-ZST field the struct is "transparent" over is private.

CC `@RalfJung`

Tentatively nominating it for the release notes, feel free to remove the nomination.
`@rustbot` label needs-fcp relnotes A-rustdoc-ui
2023-10-14 19:22:16 +02:00
Michael Goulet
59315b8a63 Stabilize AFIT and RPITIT 2023-10-13 21:01:36 +00:00
Oli Scherer
6724f9926c hide host param from generic parameter list of ~const bounds 2023-10-12 17:14:19 +00:00
Oli Scherer
cfb6afa296 Add regression test for generic args showing host param 2023-10-12 16:49:23 +00:00
Oli Scherer
8f2af7e010 Test cross crate 2023-10-12 16:44:37 +00:00
Oli Scherer
c4e61faf2e Hide host effect params from docs 2023-10-12 16:14:54 +00:00
Oli Scherer
20363f40a9 Add regression tests 2023-10-12 15:55:23 +00:00
Guillaume Gomez
bd59fc603f Add tests for enum discriminant value display with repr 2023-10-11 23:44:12 +02:00
bors
6d05c430d2 Auto merge of #115948 - notriddle:notriddle/logo-lockup, r=fmease
rustdoc: show crate name beside smaller logo

*Blocked on https://github.com/rust-lang/cargo/pull/12800*

## Summary

In this PR, the crate name and version are always shown in the sidebar, even in subpages, and the lateral navigation is always shown in the sidebar, even in modules.

Clicking the crate name does the same thing clicking the logo always did: take you to the crate root (the crate's home page, at least within Rustdoc).

The Rust logo is also no longer shown by default for non-Rust docs.

### Screenshots

<details><summary>Before</summary>

| | Macro | Module |
|--|-------|--------|
| In crate | ![image](https://github.com/rust-lang/rust/assets/1593513/d5db0a46-2bb6-44a2-a3aa-2d915ecb8595) |![image](https://github.com/rust-lang/rust/assets/1593513/61f8c1ee-c298-4e2c-b791-18ecb79ab83b)
| In module[^1] | ![image](https://github.com/rust-lang/rust/assets/1593513/73abca59-0b69-4650-a1e2-7278ca34795c) | ![image](https://github.com/rust-lang/rust/assets/1593513/0baf02c2-2ec7-4674-80e5-a6a74a973376)

[^1]: This PR also includes a bug fix for derive macros not showing up in the lateral navigation part of the sidebar

</details>

#### Whole sidebar screenshots

| | Macro | Module |
|--|-------|--------|
| In crate | ![image](https://github.com/rust-lang/rust/assets/1593513/75d1bd07-41f7-4f11-ba24-fd5476e0586a) | ![image](https://github.com/rust-lang/rust/assets/1593513/52960259-2b65-4131-b380-01826f0a0eb7)
| In module | ![image](https://github.com/rust-lang/rust/assets/1593513/06e57928-8cb0-41bd-b152-be16cc53e5ec) | ![image](https://github.com/rust-lang/rust/assets/1593513/37291c69-2a07-4467-a382-d9b029084a47)

#### Different logo configurations

|         | Short crate name | Long crate name |
|---------|------------------|-----------------|
| Root    | ![short-root]    | ![long-root]
| Subpage | ![short-subpage] | ![long-subpage]

[short-root]: https://github.com/rust-lang/rust/assets/1593513/9e2b4fa8-f581-4106-b562-1e0372c13f79
[short-subpage]: https://github.com/rust-lang/rust/assets/1593513/8331cdb8-fa13-4671-a1e2-dcc1cdca7451
[long-root]: https://github.com/rust-lang/rust/assets/1593513/7d377fec-0f1d-4343-9f82-0e35a8f58056
[long-subpage]: https://github.com/rust-lang/rust/assets/1593513/3b3094a4-63c9-477c-8c15-b6075837df30

##### Without a logo

![image](https://github.com/rust-lang/rust/assets/1593513/66672b79-6c59-4be8-a527-25ef6f0b04ab)

### Preview pages

https://notriddle.com/rustdoc-html-demo-5/sidebar-layout-rocket/rocket/index.html

https://notriddle.com/rustdoc-html-demo-5/sidebar-layout-rocket/rocket_sync_db_pools/index.html

https://notriddle.com/rustdoc-html-demo-5/sidebar-layout-rust-compiler/index.html

https://notriddle.com/rustdoc-html-demo-5/sidebar-layout-rust/std/index.html

https://notriddle.com/rustdoc-html-demo-5/sidebar-layout-rocket/tokio/index.html

## Motivation

This improves visual information density (the construct with the logo and crate name is *shorter* than the logo on its own, because it's not square) and navigation clarity (we can now see what clicking the Rust logo does, specifically).

Compare this with the layout at [Phoenix's Hexdocs] (which is what this proposal is closely based on), the old proposal on [Internals Discourse] (which always says "Rust standard library" in the sidebar, but doesn't do the side-by-side layout).

[Phoenix's Hexdocs]: https://hexdocs.pm/phoenix/1.7.7/overview.html
[Internals Discourse]: https://internals.rust-lang.org/t/poc-of-a-new-design-for-the-generated-rustdoc/11018

## Guide-level explanation

This PR cleans up some of the sidebar navigation.

It makes the logo in the desktop sidebar a bit smaller, and puts the crate name and version next to it (either beside it, or below it, depending on if there's space), making it clearer what clicking on it does: click the crate name to open the crate's home page. It also removes the Rust logo from non-official-Rust crates, again to make the navigation and supply chain clearer (since the crate name has been added, the logo is no longer necessary for navigation).

It adds a bit more clarifying information for lateral navigation. On items that don't add their own sidebar items, it just shows its siblings directly below the crate name and logo, but for other items, it shows "In crate alloc" instead of just "In alloc". It also shows the lateral navigation tools on module pages, making modules consistent with every other item.

## Drawbacks

While this actually takes up less screen real estate than the old layout on desktop, it takes up more HTML. It's also a bit more visually complex.

## Rationale and alternatives

I could do what the Internals POC did and keep the vertically stacked layout all the time, instead of doing a horizontal stack where possible. It would take up more screen real estate, though.

## Prior art

This design is lifted almost verbatim from Hexdocs. It seems to work for them. [`opentelemetry_process_propagator`], for example, has a long application name.

[`opentelemetry_process_propagator`]: https://hexdocs.pm/opentelemetry_process_propagator/OpentelemetryProcessPropagator.html

## Unresolved questions

Maybe we should encourage crate authors to include their own logo more often? It certainly helps give people a better sense of "place." This seems to be blocked on coming up with an API to do it without requiring them to host the file somewhere.

## Future possibilities

Beyond this, plenty of other changes could be made to improve the layout, like

* Fix things so that clicking an item in the sidebar doesn't cause it to scroll back to the top.
  * The [Internals demo](https://utherii.github.io/new.html) does this right: clicking an item in the sidebar changes the content area, but the sidebar itself does not change. This is nice, because clicking is cheap and I can skim the opening few paragraphs while browsing.
  * The layout of the docs sidebar causes trouble to implement this, because it's different on different pages, but at least fix this on the file browser.
* Come up with a less cluttered way to do disclosure. There's a lot of `[-]` on the page.
  * We don't lack ideas to fix this one. We have *too many*.
* Do a better job of separating local navigation (vec::Vec links to vec::IntoIter) and the table of contents (vec::Vec links to vec::Vec::new).
  * A possibility: add a Back arrow next to the "In [module]" header?
    ![image](https://github.com/rust-lang/rust/assets/1593513/e969faf7-7722-457a-b8c6-8d962e9e1e23)
* Give readers more control of how much rustdoc shows them, and giving doc authors more control of how much it generates. Basically, https://github.com/rust-lang/rust/pull/115660 is great, let's do it too.

But those are mostly orthogonal, not future possibilities unlocked by this change.
2023-10-11 06:28:36 +00:00
Guillaume Gomez
4be9cfabf2
Rollup merge of #109422 - notriddle:notriddle/impl-disambiguate-search, r=GuillaumeGomez
rustdoc-search: add impl disambiguator to duplicate assoc items

Preview (to see the difference, click the link and pay attention to the specific function that comes up):

| Before | After |
|--|--|
| [`simd<i64>, simd<i64> -> simd<i64>`](https://doc.rust-lang.org/nightly/std/?search=simd%3Ci64%3E%2C%20simd%3Ci64%3E%20-%3E%20simd%3Ci64%3E) | [`simd<i64>, simd<i64> -> simd<i64>`](https://notriddle.com/rustdoc-demo-html-3/impl-disambiguate-search/std/index.html?search=simd%3Ci64%3E%2C%20simd%3Ci64%3E%20-%3E%20simd%3Ci64%3E) |
| [`cow, vec -> bool`](https://doc.rust-lang.org/nightly/std/?search=cow%2C%20vec%20-%3E%20bool) | [`cow, vec -> bool`](https://notriddle.com/rustdoc-demo-html-3/impl-disambiguate-search/std/index.html?search=cow%2C%20vec%20-%3E%20bool)

Helps with #90929

This changes the search results, specifically, when there's more than one impl with an associated item with the same name. For example, the search queries `simd<i8> -> simd<i8>` and `simd<i64> -> simd<i64>` don't link to the same function, but most of the functions have the same names.

This change should probably be FCP-ed, especially since it adds a new anchor link format for `main.js` to handle, so that URLs like `struct.Vec.html#impl-AsMut<[T]>-for-Vec<T,+A>/method.as_mut` redirect to `struct.Vec.html#method.as_mut-2`. It's a strange design, but there are a few reasons for it:

* I'd like to avoid making the HTML bigger. Obviously, fixing this bug is going to add at least a little more data to the search index, but adding more HTML penalises viewers for the benefit of searchers.

* Breaking `struct.Vec.html#method.len` would also be a disappointment.

On the other hand:

* The path-style anchors might be less prone to link rot than the numbered anchors. It's definitely less likely to have URLs that appear to "work", but silently point at the wrong thing.

* This commit arranges the path-style anchor to redirect to the numbered anchor. Nothing stops rustdoc from doing the opposite, making path-style anchors the default and redirecting the "legacy" numbered ones.

### The bug

On the "Before" links, this example search calls for `i64`:

![image](https://github.com/rust-lang/rust/assets/1593513/9431d89d-41dc-4f68-bbb1-3e2704a973d2)

But if I click any of the results, I get `f64` instead.

![image](https://github.com/rust-lang/rust/assets/1593513/6d89c692-1847-421a-84d9-22e359d9cf82)

The PR fixes this problem by adding enough information to the search result `href` to disambiguate methods with different types but the same name.

More detailed description of the problem at:
https://github.com/rust-lang/rust/pull/109422#issuecomment-1491089293

> When a struct/enum/union has multiple impls with different type parameters, it can have multiple methods that have the same name, but which are on different impls. Besides Simd, [Any](https://doc.rust-lang.org/nightly/std/any/trait.Any.html?search=any%3A%3Adowncast) also demonstrates this pattern. It has three methods named `downcast`, on three different impls.
>
> When that happens, it presents a challenge in linking to the method. Normally we link like `#method.foo`. When there are multiple `foo`, we number them like `#method.foo`, `#method.foo-1`, `#method.foo-2`, etc.
>
> It also presents a challenge for our search code. Currently we store all the variants in the index, but don’t have any way to generate unambiguous URLs in the results page, or to distinguish them in the SERP.
>
> To fix this, we need three things:
>
> 1. A fragment format that fully specifies the impl type parameters when needed to disambiguate (`#impl-SimdOrd-for-Simd<i64,+LANES>/method.simd_max`)
> 2. A search index that stores methods with enough information to disambiguate the impl they were on.
> 3. A search results interface that can display multiple methods on the same type with the same name, when appropriate OR a disambiguation landing section on item pages?
>
> For reviewers: it can be hard to see the new fragment format in action since it immediately gets rewritten to the numbered form.
2023-10-10 18:44:43 +02:00
bors
be581d9f82 Auto merge of #116142 - GuillaumeGomez:enum-variant-display, r=fmease
[rustdoc] Show enum discrimant if it is a C-like variant

Fixes https://github.com/rust-lang/rust/issues/101337.

We currently display values for associated constant items in traits:

![image](https://github.com/rust-lang/rust/assets/3050060/03e566ec-c670-47b4-8ca2-b982baa7a0f4)

And we also display constant values like [here](file:///home/imperio/rust/rust/build/x86_64-unknown-linux-gnu/doc/std/f32/consts/constant.E.html).

I think that for coherency, we should display values of C-like enum variants.

With this change, it looks like this:

![image](https://github.com/rust-lang/rust/assets/3050060/b53fbbe0-bdb1-4289-8537-f2dd4988e9ac)

As for the display of the constant value itself, I used what we already have to keep coherency.

We display the C-like variants value in the following scenario:
 1. It is a C-like variant with a value set => all the time
 2. It is a C-like variant without a value set: All other variants are C-like variants and at least one them has its value set.

Here is the result in code:

```rust
// Ax and Bx value will be displayed.
enum A {
    Ax = 12,
    Bx,
}

// Ax and Bx value will not be displayed
enum B {
    Ax,
    Bx,
}

// Bx value will not be displayed
enum C {
    Ax(u32),
    Bx,
}

// Bx value will not be displayed, Cx value will be displayed.
#[repr(u32)]
enum D {
    Ax(u32),
    Bx,
    Cx = 12,
}
```

r? `@notriddle`
2023-10-09 13:18:47 +00:00
Guillaume Gomez
1210aac1c0 Add more complex test cases for enum discriminant display 2023-10-09 14:33:04 +02:00
Michael Howell
c6e6ecb1af rustdoc: remove rust logo from non-Rust crates 2023-10-08 20:17:53 -07:00
Michael Howell
6d6fa792ff rustdoc: clean up the layout for annotated version numbers
This should result in a layout for the actual standard library,
when built on CI, that looks like this:

    _____
   /     \ std
   |  R  | 1.74.0-nightly
   \_____/

   (203c57dbe 2023-09-17)

Having the whole version as one string caused it to flex wrap,
because the sidebar isn't wide enough to fit the whole thing.
2023-10-08 20:17:53 -07:00
Michael Howell
28ee5da4b7 rustdoc: show crate name beside small logo
This commit changes the layout to something a bit less "look at my logo!!!111"
gigantic, and makes it clearer where clicking the logo will actually take you.
It also means the crate name is persistently at the top of the sidebar, even
when in a sub-item page, and clicking that name takes you back to the root.

|         | Short crate name | Long crate name |
|---------|------------------|-----------------|
| Root    | ![short-root]    | ![long-root]
| Subpage | ![short-subpage] | ![long-subpage]

[short-root]: https://github.com/rust-lang/rust/assets/1593513/fe2ce102-d4b8-44e6-9f7b-68636a907f56
[short-subpage]: https://github.com/rust-lang/rust/assets/1593513/29501663-56c0-4151-b7de-d2637e167125
[long-root]: https://github.com/rust-lang/rust/assets/1593513/f6a385c0-b4c5-4a9c-954b-21b38de4192f
[long-subpage]: https://github.com/rust-lang/rust/assets/1593513/97ec47b4-61bf-4ebe-b461-0d2187b8c6ca

https://notriddle.com/rustdoc-html-demo-4/logo-lockup/image/index.html

https://notriddle.com/rustdoc-html-demo-4/logo-lockup/crossbeam_channel/index.html

https://notriddle.com/rustdoc-html-demo-4/logo-lockup/adler/struct.Adler32.html

https://notriddle.com/rustdoc-html-demo-4/logo-lockup/crossbeam_channel/struct.Sender.html

This improves visual information density (the construct with the logo and
crate name is *shorter* than the logo on its own, because it's not
square) and navigation clarity (we can now see what clicking the Rust logo
does, specifically).

Compare this with the layout at [Phoenix's Hexdocs] (which is what this
proposal is closely based on), the old proposal on [Internals Discourse]
(which always says "Rust standard library" in the sidebar, but doesn't do the
side-by-side layout).

[Phoenix's Hexdocs]: https://hexdocs.pm/phoenix/1.7.7/overview.html
[Internals Discourse]: https://internals.rust-lang.org/t/poc-of-a-new-design-for-the-generated-rustdoc/11018

In newer versions of rustdoc, the crate name and version are always shown in
the sidebar, even in subpages. Clicking the crate name does the same thing
clicking the logo always did: return you to the crate root.

While this actually takes up less screen real estate than the old layout on
desktop, it takes up more HTML. It's also a bit more visually complex.

I could do what the Internals POC did and keep the vertically stacked layout
all the time, instead of doing a horizontal stack where possible. It would
take up more screen real estate, though.

This design is lifted almost verbatim from Hexdocs. It seems to work for them.
[`opentelemetry_process_propagator`], for example, has a long application name.

[`opentelemetry_process_propagator`]: https://hexdocs.pm/opentelemetry_process_propagator/OpentelemetryProcessPropagator.html

Has anyone written the rationale on why the Rust logo shows up on projects that
aren't the standard library? If we turned it off on non-standard crates by
default, it would line wrap crate names a lot less often.

Or maybe we should encourage crate authors to include their own logo more
often? It certainly helps give people a better sense of "place."

I'm not sure of anything that directly follows up this one. Plenty of other
changes could be made to improve the layout, like

* coming up with a less cluttered way to do disclosure (there's a lot of `[-]`
  on the page)
* doing a better job of separating lateral navigation (vec::Vec links to
  vec::IntoIter) and the table of contents (vec::Vec links to vec::Vec::new)
* giving readers more control of how much rustdoc hows them, and giving doc
  authors more control of how much it generates
* better search that reduces the need to browse

But those are mostly orthogonal, not future possibilities unlocked by this change.
2023-10-08 20:17:40 -07:00
Guillaume Gomez
b0badc17cd Add cross-crate C-like variant test 2023-10-07 14:37:47 +02:00
Guillaume Gomez
1994d0b4a4 Update enum-variant-value test 2023-10-07 14:17:17 +02:00
Michael Howell
a46ccd8d3f Add URL to test case issues 2023-10-04 13:04:45 -07:00
Michael Howell
9266270ef5 Rename issue-\d+.rs tests to have meaningful names 2023-10-04 12:58:06 -07:00
Michael Howell
a198aff4a4 Add crate_name to test so that it can be renamed 2023-10-04 12:13:01 -07:00
Matthias Krüger
3e293634e2
Rollup merge of #116388 - fmease:rustdoc-fix-n-clean-up-x-crate-higher-ranked-params, r=notriddle
rustdoc: fix & clean up handling of cross-crate higher-ranked parameters

Preparatory work for the refactoring planned in #113015 (for correctness & maintainability).

---

1. Render the higher-ranked parameters of cross-crate function pointer types **(*)**.
2. Replace occurrences of `collect_referenced_late_bound_regions()` (CRLBR) with `bound_vars()`.
  The former is quite problematic and the use of the latter allows us to yank a lot of hacky code **(†)**
  as you can tell from the diff! :)
3. Add support for cross-crate higher-ranked types (`#![feature(non_lifetime_binders)]`).
  We were previously ICE'ing on them (see `inline_cross/non_lifetime_binders.rs`).

---

**(*)**: Extracted from test `inline_cross/fn-type.rs`:

```diff
- fn(_: &'z fn(_: &'b str), _: &'a ()) -> &'a ()
+ for<'z, 'a, '_unused> fn(_: &'z for<'b> fn(_: &'b str), _: &'a ()) -> &'a ()
```

**(†)**: It returns an `FxHashSet` which isn't *predictable* or *stable* wrt. source code (`.rmeta`) changes. To elaborate, the ordering of late-bound regions doesn't necessarily reflect the ordering found in the source code. It does seem to be stable across compilations but modifying the source code of the to-be-documented crates (like adding or renaming items) may result in a different order:

<details><summary>Example</summary>

Let's assume that we're documenting the cross-crate re-export of `produce` from the code below. On `master`, rustdoc would render the list of binders as `for<'x, 'y, 'z>`. However, once you add back the functions `a`–`l`, it would be rendered as `for<'z, 'y, 'x>` (reverse order)! Results may vary. `bound_vars()` fixes this as it returns them in source order.

```rs
// pub fn a() {}
// pub fn b() {}
// pub fn c() {}
// pub fn d() {}
// pub fn e() {}
// pub fn f() {}
// pub fn g() {}
// pub fn h() {}
// pub fn i() {}
// pub fn j() {}
// pub fn k() {}
// pub fn l() {}

pub fn produce() -> impl for<'x, 'y, 'z> Trait<'z, 'y, 'x> {}

pub trait Trait<'a, 'b, 'c> {}

impl Trait<'_, '_, '_> for () {}
```

</details>

Further, as the name suggests, CRLBR only collects *referenced* regions and thus we drop unused binders. `bound_vars()` contains unused binders on the other hand. Let's stay closer to the source where possible and keep unused binders.

Lastly, using `bound_vars()` allows us to get rid of

* the deduplication and alphabetical sorting hack in `simplify.rs`
* the weird field `bound_params` on `EqPredicate`

both of which were introduced by me in #102707 back when I didn't know better.

To illustrate, let's look at the cross-crate bound `T: for<'a, 'b> Trait<A<'a> = (), B<'b> = ()>`.

* With CRLBR + `EqPredicate.bound_params`, *before* bounds simplification we would have the bounds `T: Trait`, `for<'a> <T as Trait>::A<'a> == ()` and `for<'b> <T as Trait>::B<'b> == ()` which required us to merge `for<>`, `for<'a>` and `for<'b>` into `for<'a, 'b>` in a deterministic manner and without introducing duplicate binders.
* With `bound_vars()`, we now have the bounds `for<'a, b> T: Trait`, `<T as Trait>::A<'a> == ()` and `<T as Trait>::B<'b> == ()` before bound simplification similar to rustc itself. This obviously no longer requires any funny merging of `for<>`s. On top of that `for<'a, 'b>` is guaranteed to be in source order.
2023-10-04 05:02:06 +02:00
León Orell Valerian Liehr
ace85f0ae3
rustdoc: add support for cross-crate higher-ranked types 2023-10-03 17:41:25 +02:00
León Orell Valerian Liehr
67de1509f3
rustdoc: fix & clean up handling of cross-crate higher-ranked lifetimes 2023-10-03 17:16:51 +02:00
Michael Howell
0487237f12 rustdoc: add URLs for test issues 2023-09-27 17:22:18 -07:00
Michael Howell
7cd8b2c925 Rename issue-\d+.rs tests to have meaningful names 2023-09-27 17:15:37 -07:00
Michael Howell
79195d5cbb Add crate_name to test so that it can be renamed 2023-09-27 16:51:21 -07:00
bors
0288f2e195 Auto merge of #116084 - fmease:rustdoc-fix-x-crate-async-fn, r=GuillaumeGomez
rustdoc: correctly render the return type of cross-crate async fns

Fixes #115760.
2023-09-25 22:04:53 +00:00
León Orell Valerian Liehr
025a2cda0e
rustdoc: correctly render ret ty of cross-crate async fns 2023-09-25 15:57:04 +02:00
Guillaume Gomez
4a64c796ee Add test for enum variant value display 2023-09-25 15:01:14 +02:00
bors
8759de0a49 Auto merge of #114776 - fee1-dead-contrib:enable-effects-in-libcore, r=oli-obk
Enable effects for libcore

~~r? `@oli-obk~~`

forgot you are on vacation, oops
2023-09-22 07:00:52 +00:00
Michael Howell
3583e86674 rustdoc: update test cases for changes to the printing style
This whole thing changes it so that the JS and the UI both use
rustc's own path printing to handle the impl IDs. This results in
the format changing a little bit; full paths are used in spots
where they aren't strictly necessary, and the path sometimes uses
generics where the old system used the trait's own name, but it
shouldn't matter since the orphan rules will prevent it anyway.
2023-09-21 15:16:44 -07:00
Michael Howell
3fbfe2bca5 rustdoc-search: add impl disambiguator to duplicate assoc items
Helps with #90929

This changes the search results, specifically, when there's more than
one impl with an associated item with the same name. For example,
the search queries `simd<i8> -> simd<i8>` and `simd<i64> -> simd<i64>`
don't link to the same function, but most of the functions have the
same names.

This change should probably be FCP-ed, especially since it adds a new
anchor link format for `main.js` to handle, so that URLs like
`struct.Vec.html#impl-AsMut<[T]>-for-Vec<T,+A>/method.as_mut` redirect
to `struct.Vec.html#method.as_mut-2`. It's a strange design, but there
are a few reasons for it:

* I'd like to avoid making the HTML bigger. Obviously, fixing this bug
  is going to add at least a little more data to the search index, but
  adding more HTML penalises viewers for the benefit of searchers.

* Breaking `struct.Vec.html#method.len` would also be a disappointment.

On the other hand:

* The path-style anchors might be less prone to link rot than the numbered
  anchors. It's definitely less likely to have URLs that appear to "work",
  but silently point at the wrong thing.

* This commit arranges the path-style anchor to redirect to the numbered
  anchor. Nothing stops rustdoc from doing the opposite, making path-style
  anchors the default and redirecting the "legacy" numbered ones.
2023-09-21 15:16:44 -07:00
David Tolnay
3dcc8fcab5
Delete obsolete --disable-per-crate-search rustdoc flag 2023-09-20 22:09:48 -07:00
Deadbeef
7446012c1e fix rustdoc tests 2023-09-20 03:02:14 +00:00
León Orell Valerian Liehr
64fa12a4fb
rustdoc: hide repr(transparent) if it isn't part of the public ABI 2023-09-18 19:30:10 +02:00
Guillaume Gomez
7681f63cab Implement new eBNF for codeblock attributes 2023-09-15 21:32:28 +02:00
Guillaume Gomez
f5561842e3 Add tests for custom_code_classes_in_docs feature 2023-09-15 21:32:28 +02:00
Guillaume Gomez
755835ef3d Add test for the presence of "Aliased type" title in the sidebar 2023-09-11 14:17:39 +02:00
Michael Howell
d882b2118e rustdoc: add impl items from aliased type into sidebar 2023-09-08 14:59:54 -07:00
Guillaume Gomez
1fb672c738
Rollup merge of #115201 - notriddle:notriddle/type-alias-impl-list, r=GuillaumeGomez
rustdoc: list matching impls on type aliases

Fixes https://github.com/rust-lang/rust/issues/32077

Fixes #99952

Remake of https://github.com/rust-lang/rust/pull/112429

Partially reverts https://github.com/rust-lang/rust/pull/112543, but keeps the test case.

This version of the PR avoids the infinite loop by structurally matching types instead of using full unification. This version does not support type alias trait bounds, but the compiler does not enforce those anyway (https://github.com/rust-lang/rust/issues/21903).

r? `@GuillaumeGomez`

CC `@lcnr`
2023-09-08 14:10:51 +02:00
Matthias Krüger
403a18f13d
Rollup merge of #115604 - GuillaumeGomez:private-fields-tuple-struct, r=notriddle
rustdoc: Render private fields in tuple struct as `/* private fields */`

Reopening of https://github.com/rust-lang/rust/pull/110552. All that was missing was a test for the different cases so I added it into the second commit.

Description from the original PR:

> I've gotten some feedback that the current rustdoc rendering of...
>
> ```
> struct HasPrivateFields(_);
> ```
>
> ...is confusing, and I agree with that feedback, especially compared to the field struct case:
>
> ```
> struct HasPrivateFields { /* private fields */ }
> ```
>
> So this PR makes it so that when all of the fields of a tuple variant are private, just render it with the `/* private fields */` comment. We can't *always* render it like that, for example when there's a mix of private and public fields.

cc ````@jsha````
r? ````@notriddle````
2023-09-08 08:23:02 +02:00
bors
70c7e4d21c Auto merge of #114855 - Urgau:rustdoc-typedef-inner-variants, r=GuillaumeGomez
rustdoc: show inner enum and struct in type definition for concrete type

This PR implements the [Display enum variants for generic enum in type def page](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/Display.20enum.20variants.20for.20generic.20enum.20in.20type.20def.20page) #rustdoc/zulip proposal.

This proposal comes from looking at [`TyKind`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/sty/type.TyKind.html) typedef from the compiler. On that page, the documentation is able to show the layout for each variant, but not the variants themselves. This proposal suggests showing the fields and variants for those "concrete type". This would mean that instead of having many unresolved generics, like in `IrTyKind`:
```rust
    Array(I::Ty, I::Const),
    Slice(I::Ty),
    RawPtr(I::TypeAndMut),
    Ref(I::Region, I::Ty, I::Mutability),
    FnDef(I::DefId, I::GenericArgsRef),
```
those would be resolved with direct links to the proper types in the `TyKind` typedef page:
```rust
    Array(Ty<'tcx>, Const<'tcx>),
    Slice(Ty<'tcx>),
    RawPtr(TypeAndMut<'tcx>),
    Ref(Region<'tcx>, Ty<'tcx>, Mutability<'tcx>),
    FnDef(DefId<'tcx>, GenericArgsRef<'tcx>),
```
Saving both time and confusion.

-----

<details>

<summary>Old description</summary>

I've chosen to add the enums and structs under the "Show Aliased Type" details, as well as showing the variants and fields under the usual "Variants" and "Fields" sections. ~~*under new the `Inner Variants` and `Inner Fields` sections (except for their names, they are identical to the one found in the enum, struct and union pages). Those sections are complementary and do not replace anything else.*~~

This PR proposes the following condition for showing the aliased type (basically, has the aliased type some generics that are all of them resolved):
 - the typedef does NOT have any generics (modulo lifetimes)
 - AND the aliased type has some generics

</details>

### Examples

```rust
pub enum IrTyKind<'a, I: Interner> {
    /// Doc comment for AdtKind
    AdtKind(&'a I::Adt),
    /// and another one for TyKind
    TyKind(I::Adt, I::Ty),
    // no comment
    StructKind { a: I::Adt, },
}

pub type TyKind<'a> = IrTyKind<'a, TyCtxt>;
```
![TyKind](https://github.com/rust-lang/rust/assets/3616612/13307679-6d48-40d6-ad50-6db0b7f36ac7)

<details>
<summary>Old</summary>

![image](https://github.com/rust-lang/rust/assets/3616612/4147c049-d056-42d4-8a01-d43ebe747308)

![TyKind](https://user-images.githubusercontent.com/3616612/260988247-34831aa9-470d-4286-ad9f-3e8002153a92.png)

![TyKind](https://github.com/rust-lang/rust/assets/3616612/62381bb3-fa0f-4b05-926d-77759cf9115a)

</details>

```rust
pub struct One<T> {
    pub val: T,
    #[doc(hidden)]
    pub inner_tag: u64,
    __hidden: T,
}

/// `One` with `u64` as payload
pub type OneU64 = One<u64>;
```
![OneU64](https://github.com/rust-lang/rust/assets/3616612/d551b474-ce88-4f8c-bc94-5c88aba51424)

<details>
<summary>Old</summary>

![image](https://github.com/rust-lang/rust/assets/3616612/1a3f53c0-17bf-4aa7-894d-3fedc15b33da)

![OneU64](https://github.com/rust-lang/rust/assets/3616612/7b124a5b-e287-4efb-b9ca-fdcd1cdeeba8)

![OneU64](https://github.com/rust-lang/rust/assets/3616612/ddd962be-4f76-4ecd-81bd-531f3dd23832)

</details>

r? `@GuillaumeGomez`
2023-09-07 16:23:03 +00:00
Guillaume Gomez
c4bb70f51b Add regression test for private fields in tuple struct 2023-09-06 13:26:56 +02:00
Michael Goulet
1abbd4cd4f Render missing fields in tuple struct/enum as /* private fields */ 2023-09-06 11:16:05 +02:00