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`
- All attributes for an item need to be considered at once, they can't
be considered a line at a time.
- The top-level crate was not being visited. This bug was caught by
`extern-crate-used-only-in-link`, which I'm very glad I added.
- Make the loader private to the module, so that only one function is
exposed.
## What is an HTML root url?
It tells rustdoc where it should link when documentation for a crate is
not available locally; for example, when a crate is a dependency of a
crate documented with `cargo doc --no-deps`.
## What is the difference between `html_root_url` and `--extern-html-root-url`?
Both of these tell rustdoc what the HTML root should be set to.
`doc(html_root_url)` is set by the crate author, while
`--extern-html-root-url` is set by the person documenting the crate.
These are often different. For example, docs.rs uses
`--extern-html-root-url https://docs.rs/crate-name/version` to ensure
all crates have documentation, even if `html_root_url` is not set.
Conversely, crates such as Rocket set `doc(html_root_url =
"https://api.rocket.rs")`, because they prefer users to view the
documentation on their own site.
Crates also set `html_root_url` to ensure they have
documentation when building locally when offline. This is unfortunate to
require, because it's more work from the library author. It also makes
it impossible to distinguish between crates that want to be viewed on a
different site (e.g. Rocket) and crates that just want documentation to
be visible offline at all (e.g. Tokio). I have authored a separate
change to the API guidelines to no longer recommend doing this:
https://github.com/rust-lang/api-guidelines/pull/230.
## Why change the default?
In the past, docs.rs has been the main user of `--extern-html-root-url`.
However, it's useful for other projects as well. In particular, Cargo
wants to pass it by default when running `--no-deps`
(https://github.com/rust-lang/cargo/issues/8296).
Unfortunately, for these other use cases, the priority order is
inverted. They want to give *precedence* to the URL the crate picks, and
only fall back to the `--extern-html-root` if no `html_root_url` is
present. That allows passing `--extern-html-root` unconditionally,
without having to parse the source code to see what attributes are
present.
For docs.rs, however, we still want to keep the old behavior, so that
all links on docs.rs stay on the site.
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```
* 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: Restore --default-theme, etc, by restoring varname escaping
In #86157cd0f93193c
Use Tera templates for rustdoc.
dropped the following transformation from the keys of the default settings element's `data-` attribute names:
.map(|(k, v)| format!(r#" data-{}="{}""#, k.replace('-', "_"), Escape(v)))
The `Escape` part is indeed no longer needed, because Tera does that for us. But the massaging of `-` to `_` is needed, for the (bizarre) reasons explained in the new comments.
I have tested that the default theme function works again for me. I have also verified that passing (in shell syntax)
'--default-theme="zork&"'
escapes the value in the HTML.
Closes#87263
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`
Because specifying these flags multiple times will never be discernibly different in functionality from specifying them a single time, there is no reason to fail and report an error to the user.
This test does not test the output as well as I would like, but I think
I am limited by htmldocck. I would really just like to strip all the
HTML tags from the output for the sake of the different `@has` checks,
but that doesn't seem to be currently possible.
rustdoc: Render `<Self as X>::Y` type casts properly across crate bounds
My last PR that introduced the type casting did not work for cross-crate re-exported traits, which is fixed in this PR.
Fully resolves#85454
Properly render HRTBs
```rust
pub fn test<T>()
where
for<'a> &'a T: Iterator,
{}
```
This will now render properly including the `for<'a>`
I do not know if this covers all cases, it only covers everything that I could think of that includes `for` and lifetimes in where bounds.
Also someone need to mentor me on how to add a proper rustdoc test for this.
Resolves#78482
