| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=jyn514,petrochenkov
Rustdoc: Fix macros 2.0 and built-in derives being shown at the wrong path
Fixes #74355
- ~~waiting on author + draft PR since my code ought to be cleaned up _w.r.t._ the way I avoid the `.unwrap()`s:~~
- ~~dummy items may avoid the first `?`,~~
- ~~but within the module traversal some tests did fail (hence the second `?`), meaning the crate did not possess the exact path of the containing module (`extern` / `impl` blocks maybe? I'll look into that).~~
r? `@jyn514`
|
|
Recursively document methods via `Deref` traits
This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level.
Fixes https://github.com/rust-lang/rust/issues/26207
Fixes https://github.com/rust-lang/rust/issues/53038
Fixes https://github.com/rust-lang/rust/issues/71640
r? `@jyn514`
|
|
This adjusts the `rustdoc` trait impl collection path to preserve `Deref` impls
from other crates. This adds a first pass to map all of the `Deref` type to
target edges and then recursively preserves all targets.
|
|
There can now be multiple `Deref` method sections, so this adds the target type
to the section ID to ensure they are unique.
|
|
|
|
Get rid of custom pretty-printing in rustdoc
and use rustc_hir_pretty directly instead.
Closes https://github.com/rust-lang/rust/issues/79497.
r? `@CraftSpider`
|
|
and use rustc_hir_pretty directly instead
|
|
Properly handle primitive disambiguators in rustdoc
Fixes #80559
r? ``@jyn514``
Is there a way to test that the generated intra-doc link is what I expect?
|
|
|
|
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
|
|
|
|
|
|
|
|
Fixes #74355
The issue with the built-in derives may be related to:
https://github.com/rust-lang/rust/issues/55482#issuecomment-434035721
|
|
|
|
|
|
Cleanup rustdoc handling of associated types
This is best reviewed a commit at a time. No particular reason for these changes, they just stood out as I was reviewing https://github.com/rust-lang/rust/pull/80653 and thinking about https://github.com/rust-lang/rust/issues/80379. The new test case worked before, it just wasn't tested.
r? `@GuillaumeGomez`
|
|
|
|
|
|
The logic was very hard to follow before.
|
|
Fix tests that incorrectly used `!@has` instead of `@!has`
The command is ``@!has`,` not `!`@has`.` I don't think these checks were
doing anything before! Ideally we would accept `!`@has`` as well, or at
least fail tests that use `!`@has`.` The current behavior seems to be
silently ignoring the check, which is very confusing.
r? `@GuillaumeGomez`
|
|
rustdoc: Render visibilities succinctly
Fixes #79139.
r? `@jyn514`
|
|
The command is `@!has`, not `!@has`. I don't think these checks were
doing anything before! Ideally we would accept `!@has` as well, or at
least fail tests that use `!@has`. The current behavior seems to be
silently ignoring the check, which is very confusing.
|
|
|
|
Rustdoc render public underscore_imports as Re-exports
Fixes #61592
|
|
Fixes #61592
|
|
Fix intra-doc links for non-path primitives
This does *not* currently work for associated items that are
auto-implemented by the compiler (e.g. `never::eq`), because they aren't
present in the source code. I plan to fix this in a follow-up PR.
Fixes https://github.com/rust-lang/rust/issues/63351 using the approach mentioned in https://github.com/rust-lang/rust/issues/63351#issuecomment-683352130.
r? `@Manishearth`
cc `@petrochenkov` - this makes `rustc_resolve::Res` public, is that ok? I'd just add an identical type alias in rustdoc if not, which seems a waste.
|
|
|
|
|
|
|
|
|
|
Fix elided lifetimes shown as `'_` on async functions
Closes https://github.com/rust-lang/rust/issues/63037.
r? `@tmandry` on the implementation, `@Darksonn` on the test cases.
|
|
These caused several false positives when documenting rustc, which means
there will likely be many more false positives in the rest of the
ecosystem.
|
|
r=Nemo157
Move tooltips messages out of html
First thing first: nothing in the output has changed. You still have the "i" on the left of code blocks examples when they have `ignore`, `compile_fail`, `should_panic` and `edition`. The behavior also remains the same: when you hover the "i", you have the corresponding message showing up.
So now, why this PR then? I realized recently that we were actually generating those messages into the HTML every time whereas all messages are the same (except for the edition ones, I'll come back to it later). So instead of generating more content, I simply moved it inside the CSS thanks to pseudo elements (`::before` and `::after`). The message is now inside `::after` and we use the `::before` to have the small triangle on the left of the message. So now, we have less HTML generated which is seems pretty nice.
So now, back to the `edition` change: the message is globally the same, but the "edition" itself can be different (2015 or 2018 currently, I expect 2021 to arrive not too far in the future). So the only difference for it is that I added a new attribute on the tooltip called `edition` which contains this information. Then, the `::after` uses it inside its `content` (you can get the content of an element's attribute by using `attr` and concat different strings by simply having them after the other).
Don't hesitate if a part of my explanations isn't clear.
r? `@jyn514`
|
|
|
|
|
|
|
|
This does *not* currently work for associated items that are
auto-implemented by the compiler (e.g. `never::eq`), because they aren't
present in the source code. I plan to fix this in a follow-up PR.
|
|
Fixes #80233
We already have logic in `evaluate_predicates` that tries to add
unimplemented predicates to our `ParamEnv`. Trying to add a predicate
that already holds can lead to errors later on, since projection
will prefer trait candidates from the `ParamEnv` to predicates from an
impl.
|
|
|
|
|
|
Apply `doc(cfg)` from parent items while collecting trait impls
Because trait impls bypass the standard `clean` hierarchy they do not participate in the `propagate_doc_cfg` pass, so instead we need to pre-collect all possible `doc(cfg)` attributes that will apply to them when cleaning.
fixes #79201
|
|
|
|
extend `WithOptConstParam` docs, move rustdoc test
This should hopefully make things a bit clearer, feel free to comment on anything which can still be improved.
cc `@ecstatic-morse` `@nikomatsakis` `@RalfJung`
|
|
|
|
Use `item_name` instead of pretty printing for resolving `Self` on intra-doc links
Pretty printing would add a `r#` prefix to raw identifiers, which was
not correct. In general I think this change makes sense -
pretty-printing is for showing to the *user*, `item_name` is suitable to
pass to resolve.
Fixes https://github.com/rust-lang/rust/issues/79633.
r? `@Manishearth`
|
|
Previously Markdown documentation was not rendered to HTML for search results,
which led to the output not being very readable, particularly for inline code.
This PR fixes that by rendering Markdown to HTML with the help of pulldown-cmark
(the library rustdoc uses to parse Markdown for the main text of documentation).
However, the text for the title attribute (the text shown when you hover over an
element) still uses the plain-text rendering since it is displayed in browsers
as plain-text.
Only these styles will be rendered; everything else is stripped away:
* *italics*
* **bold**
* `inline code`
|
|
Pretty printing would add a `r#` prefix to raw identifiers, which was
not correct. In general I think this change makes sense -
pretty-printing is for showing to the *user*, `item_name` is suitable to
pass to resolve.
|
|
|
|
Show since when a function is const in stdlib
Fixes #76998
This makes it so that functions with the `#[rustc_const_stable()]` attribute now show from what version they were stably declared const, alongside what version they were declared stable. Example from `Result`:
r? ``@jyn514``
|
