Unify impl blocks by wrapping them into a div
The blanket and "auto traits" sections are wrapped into a `div` with an ID. This PR fixes this incoherence by wrapping each impl section (the "deref impl" and the "inherent impl" sections were missing it). It'll also make some tests simpler to write.
r? `````@notriddle`````
Improve rustdoc const bounds
- Rustdoc no longer displays `~const` in trait bounds, because it currently means nothing for stable users, and because we still haven't decided on the final syntax yet.
- Rustdoc will hide trait bounds where the trait is `Drop` AND it is `~const`, i.e. `~const Drop` bounds because it has no effect on stable users as well.
- Because of additional logic that hides the whole `where` statement where it consists of `~const Drop` bounds (so it doesn't display `struct Foo<T>() where ;` like that), bounds that have no trait e.g. `where [T; N+1]: ;` are also hidden.
Cherry-picked from #92433.
rustdoc: Stop textually replacing `Self` in doc links before resolving them
Resolve it directly to a type / def-id instead.
Also never pass `Self` to `Resolver`, it is useless because it's guaranteed that no resolution will be found.
This is a pre-requisite for https://github.com/rust-lang/rust/issues/83761.
Support GATs in Rustdoc
Implements:
1. Rendering GATs in trait definitions and impl blocks
2. Rendering GATs in types (e.g. in the return type of a function)
Fixes#92341
This is my first rustdoc PR, so I have absolutely no idea how to produce tests for this. Advice from the rustdoc team would be wonderful!
I tested locally and things looked correct:
rustdoc: Add test for higher kinded functions generated by macros
Fixes#75564.
The problem has been solved apparently so adding a test to prevent a regression.
r? ```@notriddle```
Fix duplicated impl links
Fixes#78701.
The problem is that the blanket impl has the same ID as the other impl, except that we don't derive IDs when we generate the sidebar. We now do.
r? ``@notriddle``
Refactor sidebar printing code
This is the refactoring parts of #92660, plus the trait aliases capitalization
consistency fix. I think this will be necessary for #92658.
r? `@GuillaumeGomez`
Emit more valid HTML from rustdoc
Previously, tidy-html5 (`tidy`) would complain about a few things in our HTML. The main thing is that `<summary>` tags can't contain `<div>`s. That's easily fixed by changing out the `<div>`s for `<span>`s with `display: block`.
However, there's also a rule that `<span>`s can't contain heading elements. `<span>` permits only "phrasing content" https://developer.mozilla.org/en-US/docs/Web/HTML/Element/span, and `<h3>` (and friends) are "Flow content, heading content, palpable content". https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Heading_Elements
We have a wrapping `<div>` that goes around each `<h3>`/`<h4>`, etc. We turn that into a `<section>` rather than a `<span>` because `<section>` permits "flow content". https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section
After this change we get only three warnings from tidy, run on struct.String.html:
line 6 column 10790 - Warning: trimming empty <span>
line 1 column 1118 - Warning: <link> proprietary attribute "disabled"
line 1 column 1193 - Warning: <link> proprietary attribute "disabled"
The empty `<span>` is a known issue - there's a span in front of the search box to work around a strange Safari issue.
The `<link>` attributes are the non-default stylesheets. We can probably refactor theme application to avoid using this proprietary "disabled" attribute.
We can suppress those warnings with flags to tidy, and get a run that returns 0 (success):
```
tidy -o /dev/null -quiet --drop-empty-elements no --warn-proprietary-attributes no build/x86_64-unknown-linux-gnu/doc/std/string/trait.ToString.html
```
Note: this requires the latest version of tidy-html5, built from https://github.com/htacg/tidy-html5. Older versions (including the default version on Ubuntu 21.10) think `<section>` can't occur inside `<summary>`.
Demo: https://rustdoc.crud.net/jsha/fix-rustdoc-html/std/string/struct.String.html
r? `@GuillaumeGomez`
Previously, tidy-html5 (`tidy`) would complain about a few things in our
HTML. The main thing is that `<summary>` tags can't contain `<div>`s.
That's easily fixed by changing out the `<div>`s for `<span>`s with
`display: block`.
However, there's also a rule that `<span>`s can't contain heading
elements. `<span>` permits only "phrasing content"
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/span, and
`<h3>` (and friends) are "Flow content, heading content, palpable
content".
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Heading_Elements
We have a wrapping `<div>` that goes around each `<h3>`/`<h4>`,
etc. We turn that into a `<section>` rather than a `<span>` because
`<section>` permits "flow content".
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section
After this change we get only three warnings from tidy, run on
struct.String.html:
line 6 column 10790 - Warning: trimming empty <span>
line 1 column 1118 - Warning: <link> proprietary attribute "disabled"
line 1 column 1193 - Warning: <link> proprietary attribute "disabled"
The empty `<span>` is a known issue - there's a span in front of the
search box to work around a strange Safari issue.
The `<link>` attributes are the non-default stylesheets. We can probably
refactor theme application to avoid using this proprietary "disabled"
attribute.
Render more readable macro matcher tokens in rustdoc
Follow-up to #92334.
This PR lifts some of the token rendering logic from https://github.com/dtolnay/prettyplease into rustdoc so that even the matchers for which a source code snippet is not available (because they are macro-generated, or any other reason) follow some baseline good assumptions about where the tokens in the macro matcher are appropriate to space.
The below screenshots show an example of the difference using one of the gnarliest macros I could find. Some things to notice:
- In the **before**, notice how a couple places break in between `$(....)`↵`*`, which is just about the worst possible place that it could break.
- In the **before**, the lines that wrapped are weirdly indented by 1 space of indentation relative to column 0. In the **after**, we use the typical way of block indenting in Rust syntax which is put the open/close delimiters on their own line and indent their contents by 4 spaces relative to the previous line (so 8 spaces relative to column 0, because the matcher itself is indented by 4 relative to the `macro_rules` header).
- In the **after**, macro_rules metavariables like `$tokens:tt` are kept together, which is how just about everybody writing Rust today writes them.
## Before
## After
r? `@camelid`
rustdoc: load the set of in-scope traits for modules with no docstring
Fixes#93428
This fix is a response to a couple of special cases related to the `module_id`, which is eventually used for trait candidates:
* The module id is always set to the current crate, when checking `crate::`.
Normally, the set of in-scope traits would be set in `load_links_in_attrs`, but if there are no doc comments, then that loop will never run.
* the module id is set to the parent module, when resolving a module that is spelled like this:
// Notice how we use an outlined doc comment here!
// [`Test::my_fn`]
mod something {
}
As with the above problem with `crate::`, we need to make sure the module gets its traits in scope resolved, even if it has no doc comments of its own.
Fixes#93428
This fix is a response to a couple of special cases related to the
`module_id`, which is eventually used for trait candidates:
* The module id is always set to the current crate, when checking `crate::`.
Normally, the set of in-scope traits would be set in `load_links_in_attrs`,
but if there are no doc comments, then that loop will never run.
* the module id is set to the parent module, when resolving a module
that is spelled like this:
// Notice how we use an outlined doc comment here!
// [`Test::my_fn`]
mod something {
}
As with the above problem with `crate::`, we need to make sure the
module gets its traits in scope resolved, even if it has no doc comments
of its own.
Rollup of 17 pull requests
Successful merges:
- #91032 (Introduce drop range tracking to generator interior analysis)
- #92856 (Exclude "test" from doc_auto_cfg)
- #92860 (Fix errors on blanket impls by ignoring the children of generated impls)
- #93038 (Fix star handling in block doc comments)
- #93061 (Only suggest adding `!` to expressions that can be macro invocation)
- #93067 (rustdoc mobile: fix scroll offset when jumping to internal id)
- #93086 (Add tests to ensure that `let_chains` works with `if_let_guard`)
- #93087 (Fix src/test/run-make/raw-dylib-alt-calling-convention)
- #93091 (⬆ chalk to 0.76.0)
- #93094 (src/test/rustdoc-json: Check for `struct_field`s in `variant_tuple_struct.rs`)
- #93098 (Show a more informative panic message when `DefPathHash` does not exist)
- #93099 (rustdoc: auto create output directory when "--output-format json")
- #93102 (Pretty printer algorithm revamp step 3)
- #93104 (Support --bless for pp-exact pretty printer tests)
- #93114 (update comment for `ensure_monomorphic_enough`)
- #93128 (Add script to prevent point releases with same number as existing ones)
- #93136 (Backport the 1.58.1 release notes to master)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix star handling in block doc comments
Fixes#92872.
Some extra explanation about this PR and why https://github.com/rust-lang/rust/pull/92357 created this regression: when we merge doc comment kinds for example in:
```rust
/// he
/**
* hello
*/
#[doc = "boom"]
```
We don't want to remove the empty lines between them. However, to correctly compute the "horizontal trim", we still need it, so instead, I put back a part of the "vertical trim" directly in the "horizontal trim" computation so it doesn't impact the output buffer but allows us to correctly handle the stars.
r? ``@camelid``
Fix star handling in block doc comments
Fixes#92872.
Some extra explanation about this PR and why https://github.com/rust-lang/rust/pull/92357 created this regression: when we merge doc comment kinds for example in:
```rust
/// he
/**
* hello
*/
#[doc = "boom"]
```
We don't want to remove the empty lines between them. However, to correctly compute the "horizontal trim", we still need it, so instead, I put back a part of the "vertical trim" directly in the "horizontal trim" computation so it doesn't impact the output buffer but allows us to correctly handle the stars.
r? `@camelid`
rustdoc: decouple stability and const-stability
This PR tweaks the stability rendering code to consider stability and const-stability separately. This fixes two issues:
- Stabilities that match the enclosing item are now always omitted, even if the item has const-stability as well (#90552)
- Const-stable unstable functions will now have their (const-) stability rendered.
Fixes#90552.
This switches to just use size, weight, and spacing to distinguish
headings in the sidebar. We no longer use boxes, horizontal bars, or
centering to distinguish headings. This makes it much easier to
understand the hierarchy of headings, and reduces visual noise.
I also refactored how the mobile topbar works. Previously, we tried to
shift around elements from the sidebar to make the topbar. Now, the
topbar gets its own elements, which can be styled on their own. This
makes styling and reasoning about those elements simpler.
Because the heading font sizes are bigger, increase the sidebar width
slightly.
As a very minor change, removed version from the "All types" page. It's
now only on the crate page.
