| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
r=camelid,Manishearth
Display associated types of implementors
Fixes #86631.
Contrary to before, it doesn't display methods. I also had to "resurrect" the `auto-hide-trait-implementations` setting. :3
Only question at this point: should I move the `render_impl` boolean arguments into one struct? We're starting to have quite a lot of them...
cc `@cynecx`
r? `@camelid`
|
|
|
|
|
|
Remove bolding on associated constants
Associated types don't get bolded, so it looks off to have one kind
bolded and one not.
|
|
Associated types don't get bolded, so it looks off to have one kind
bolded and one not.
|
|
|
|
|
|
|
|
Followup of #83501, Fixes #86253.
|
|
|
|
|
|
|
|
Previously, rustdoc was making lots of copies of temporary owned values.
Now, it uses the owned value wherever possible.
|
|
|
|
[rustdoc] Wrap code blocks in <code> tag
This PR modifies Rustdoc output so that fenced code snippets, items and whole file source codes are wrapped in `<pre><code>` instead of just `<pre>`. This should improve the semantic meaning of the generated content.
I'm not sure what to do about `render_attributes_in_pre` and `render_attributes_in_code`. These functions were clearly expected to be used for things inside `<pre>` or `<code>`, and since I added `<code>` in this PR, some of them will be used in a different context than before. However, it seems to me that even before they were not consistent. For example, `item_constant` used `render_attributes_in_code` for its attributes, however there was no `<code>` used for constants before this PR...
Should I create some `rustdoc-gui` tests? For example to check that all `<pre>` tags have a `<code>` child?
Fixes: https://github.com/rust-lang/rust/issues/88020
|
|
|
|
[rustdoc] Copy only item path to clipboard rather than full `use` statement.
The (somewhat) recent addition of the "copy item import to clipboard" button is extremely nice.
However, i tend to write my code with fully qualified paths wherever feasible and only resort to `use` statements as a refactoring pass. This makes the "copy to clipboard" workflow awkward to use, as i would be copy-pasting that as, say
```rust
impl use std::ops::Add; for MyType {
```
and then go back and remove the `use ` and `;`.
This PR removes the `use ;` decorations, making it much nicer to use for fully-qualified items. I argue, however, that this does not noticeably degrade experience for those who prefer to import items, since the hard part about those is getting the path right, and writing the `use ;` decoration can be done by hand with little effort.
|
|
|
|
map builder
|
|
* Add Classifier::new_light_span to wrap LightSpan::new_in_file constructor
|
|
|
|
|
|
|
|
|
|
struct for better readability
|
|
|
|
|
|
* Add documentation on new arguments/functions
|
|
|
|
|
|
|
|
|
|
don't use .into() to convert types to identical types (clippy::useless_conversion)
Example:
let _x: String = String::from("hello world").into();
|
|
|
|
This way, we can show the plus and minus buttons on screens, while voice
control will read off actual words "Collapse" and "Expand" instead of reading
"open brace minus close brace" and "open brace plus close brace".
Part of #87059
|
|
(clippy::useless_conversion)
Example:
let _x: String = String::from("hello world").into();
|
|
Add support for tuple struct field documentation
Fixes #42615.
This is #80320 updated to new codebase and with added tests.
Part of https://github.com/rust-lang/rust/issues/83255.
cc ```@camelid``` (since you were involved on the original PR).
r? ```@jyn514```
|
|
Remove unnecessary `structhead` parameter from `render_union`
`structhead` is used for `render_struct` so that the logic for rendering
structs can be shared between struct variants and struct items. However,
`render_union` is not used anywhere except for rendering union items, so
its `structhead` parameter is unnecessary.
|
|
|
|
`structhead` is used for `render_struct` so that the logic for rendering
structs can be shared between struct variants and struct items. However,
`render_union` is not used anywhere except for rendering union items, so
its `structhead` parameter is unnecessary.
|
|
r=GuillaumeGomez
Rustdoc accessibility: use real headers for doc items
Part of #87059
Partially reverts #84703
Preview at: https://notriddle.com/notriddle-rustdoc-test/real-headers/std/index.html
|
|
Part of #87059
Partially reverts #84703
Preview at: https://notriddle.com/notriddle-rustdoc-test/real-headers/std/index.html
|
|
|
|
* The toggle adds visual clutter
* It's easy to miss that there are fields
* Tuple variant fields are always shown, so it is inconsistent to hide
struct variant fields
* It's annoying to have to click the toggle every time
|
|
rustdoc: show count of item contents when hidden
Resolves #85494
|
|
Part of #87059
Preview it at: https://notriddle.com/notriddle-rustdoc-test/rustdoc-sidebar-header/std/index.html
|
|
fix dead link for method in trait of blanket impl from third party crate
fix #86620
* changes `href` method to raise the actual error it had instead of an `Option`
* set the href link correctly in case of an error
I did not manage to make a small reproducer, I think it happens in a situation where
* crate A expose a trait with a blanket impl
* crate B use the trait from crate A
* crate C use types from crate B
* building docs for crate C without dependencies
r? `@jyn514`
|
|
|
|
Fix rendering of reexported macros 2.0 and fix visibility of reexported items
So, this PR grew a bit out of focus, it does the following things:
* Fixes #86276.
* Fixes visibility display for reexported items: it now takes the visibility of the "use" statement rather than the visibility of the reexported item itself).
* Fixes the display of reexported items if "--document-private-items" option is used. Before, they were simply skipped.
* Fixes inconsistency on typedef items: they didn't display their visibility contrary to other items.
I added tests to check everything listed above.
cc `@camelid` `@ollie27` (in case one of you want to review?)
r? `@jyn514`
|
