| Age | Commit message (Collapse) | Author | Lines |
|---|
|
[rustdoc] Don't document stripped items in JSON renderer.
Fixes #80664, see [my comment there](https://github.com/rust-lang/rust/issues/80664#issuecomment-797557948) for why
Note that we already do something similar in `convert_item`:
https://github.com/rust-lang/rust/blob/bb4cdf8ec034dca5c056ec9295f38062e5b7e871/src/librustdoc/json/conversions.rs#L28-L31
``@rustbot`` modify labels: +T-rustdoc +A-rustdoc-json
r? ``@jyn514``
cc ``@CraftSpider``
|
|
|
|
|
|
|
|
functions every time
|
|
|
|
Closes #80664
|
|
Remove unnecessary `Option` wrapping around `Crate.module`
I'm wondering if it was originally there so that we could `take` the
module which enables `after_krate` to take an `&Crate`. However, the two
impls of `after_krate` only use `Crate.name`, so we can pass just the
name instead.
|
|
Slight visual improvements to warning boxes in the docs
First I noticed that sometimes the thumbs-down emoji in the docs is hard to see and hard to look at because the yellow emoji color and the color of the box below are so bright. Especially if you look at the screen late at night you can notice it. I thought I should change that so I added a black outline around the emoji. It works using the [`text-shadow`](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow) property. It may be a bit hacky but it seems to work well and browser compatibility looks pretty good too: [browser compatibility](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow#browser_compatibility).
For consistency the microscope has the black border too.
Alternatively I had `drop-shadow(0px 0px 1px black);` in mind but its [browser compatibility](https://developer.mozilla.org/en-US/docs/Web/CSS/filter-function/drop-shadow()#browser_compatibility) doesn't look as good and the blurry shadow probably doesn't look as good either.
Then, I thought that now that I'm at it I could also try changing the purple color to a color you would rather expect to see for deprecation: red. For the red I've taken the blue and reused it as a foundation and moved it to the red color spectrum.
But then I thought that the purple color could still be reused for something else: for the boxes that tell you about portability (e.g. _only supported on Unix_). These are currently blue.
I think blue doesn't really represent danger like it should. Not being cross-platform represents a danger because if you want to compile for a different platform, your code may not compile anymore. Blue looks too friendly and is in my opinion more suitable for a box containing general information like for instance "This is available since 1.0.0". None of the current three box types (unstable, deprecated and portability) are that.
I think purple is a better fit for it because it's kind of in the middle between "use it" and "don't use it". Deprecated is definitely "don't use it". To illustrate this better, here's a color spectrum:
Blue = friendly, "use it".
Red = danger, "don't use it".
And the purple in the middle (the color that the portability box now has) probably represents "use it if you have to", so it's not entirely friendly and not entirely a danger. That is why I think it fits.
However I made one change to that existing purple: I made the outer color a bit brighter because it's outstandingly dark compared to the other outer colors of the other boxes.
This is all subjective but in my opinion it looks nicer. At first you might need to get used to it though. Notice the box colors and the black outlines around the emoji shapes:
|
|
rustdoc: Record crate name instead of using `None`
Fixes #83365.
r? `@jyn514`
|
|
Codeblock tooltip position
The codeblocks tooltips were misplaced. Normally, there is no top margin applied to a tooltip unless the codeblock is the first element of the doc block. The CSS rule was too vague though, applying it to all tooltips where the codeblock was the first child of its parent. Which can be easily seen with lists:
Before:
After:
r? ``@Nemo157``
|
|
r=CraftSpider,jyn514
Sidebar trait items order
We were actually sorting `Symbol` and not `String`, creating a completely invalid sort result. I added a test to prevent regressions.
r? ``@jyn514``
|
|
Rename `source` to `span` and `span` to `source`
- Rename `clean::Item.source` to `span`
- Rename `clean::Span::span()` to `clean::Span::inner()`
- Rename `rustdoc_json_types::Item.source` to `span`
- rustdoc-json: Rename `Import.span` to `Import.source`
*See also the [discussion on Zulip][z] (this is a bit more than discussed in
that conversation, but all the changes are related).*
r? `@jyn514`
[z]: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/get.20span.20of.20file.20from.20name/near/229603729
|
|
The previous changes mean that we can now remove this `Option`.
|
|
I'm wondering if it was originally there so that we could `take` the
module which enables `after_krate` to take an `&Crate`. However, the two
impls of `after_krate` only use `Crate.name`, so we can pass just the
name instead.
|
|
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
|
|
|
|
|
|
|
|
Now that we record the crate's name in its `clean::Item`, pushing the
crate name onto the `stack` causes duplicate paths. E.g., the URL
generated for the path `::foo::bar::baz` would be something like
../foo/foo/bar/baz
With this commit, the URL is corrected to
../foo/bar/baz
|
|
|
|
add rust-analyzer rustc_private option in librustdoc Cargo.toml
This addition will allow to have code completion while hacking rustdoc with rust-analyzer.
more info: https://rust-analyzer.github.io/manual.html#rust-analyzer.rustcSource
r? `@jyn514`
|
|
rustdoc: Replace pair of `Option`s with an enum
They are never both `None` or both `Some`, so it makes more sense to use
an enum so that we "make impossible states impossible".
|
|
Remove theme.js file
Fixes #82616.
The first commit moves the `theme.js` file into `main.js`, which requires to also run a small `.replace` on the `main.js` content.
The second commit is just a small cleanup to centralize DOM ids.
Since it removes a file from rustdoc output: cc `@rust-lang/docs-rs`
cc `@jsha`
r? `@jyn514`
|
|
r=GuillaumeGomez
Update Source Code Pro and include italics
Fixes #65502.
#65665, a similar PR to this was merged but reverted because of https://github.com/rust-lang/rust/pull/65665#issuecomment-556860510.
The issue in that comment is the upstream issue https://github.com/adobe-fonts/source-code-pro/issues/217 which should now be fixed in the upstream since [2.032R-ro/1.052R-it/1.012R-VAR release](https://github.com/adobe-fonts/source-code-pro/releases/tag/2.032R-ro/1.052R-it/1.012R-VAR), so I think this can now be merged.
A couple of notes from the original PR:
* Since this PR changes the font set, I think docs.rs would have to be updated if this PR is merged.
* The fonts have a double extension (.ttf.woff); this is to keep the names consistent with the upstream font release which does that to distinguish these from the .otf.woff files (Source Code Pro otf renders poorly on older Windows system apps).
|
|
|
|
Stabilize or_patterns (RFC 2535, 2530, 2175)
closes #54883
This PR stabilizes the or_patterns feature in Rust 1.53.
This is blocked on the following (in order):
- [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021
- [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705)
- It looks like we will need to pursue some sort of edition-based transition for `:pat`.
- [x] Nomination and discussion by T-lang
- [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100).
- [ ] An FCP on stabilization
EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177
|
|
|
|
|
|
Avoid temporary allocations in `render_assoc_item`
`render_assoc_item` came up as very hot in a profile of rustdoc on
`bevy`. This avoids some temporary allocations just to calculate the
length of the header.
This should be a strict improvement, since all string formatting was
done twice before.
cc #82845
|
|
...and add docs to the types instead of the fields that hold the types.
|
|
The rustdoc-json-types renames are breaking changes.
|
|
* It is called `source` in rustc and the rest of rustdoc
* It is not a span, rather it is the source of the import
|
|
|
|
Otherwise you get a lot of instances of `item.span.span()`, which is
just plain confusing. `item.span.inner()` conveys the correct meaning of
"get the type that `clean::Span` wraps".
|
|
Its type is called `clean::Span`, and also the name in the rest of
rustdoc and rustc for this kind of field is `span`.
|
|
They are never both `None` or both `Some`, so it makes more sense to use
an enum so that we "make impossible states impossible".
|
|
|
|
|
|
Only build help popup when it's really needed
When working on https://github.com/rust-lang/rust/pull/79985, I realized that the help popup was built even when it wasn't needed. This PR only makes the help popup to be built when required.
r? `@jyn514`
|
|
|
|
|
|
rustdoc: allow list syntax for #[doc(alias)] attributes
Fixes https://github.com/rust-lang/rust/issues/81205.
It now allows to have:
```rust
#[doc(alias = "x")]
// and:
#[doc(alias("y", "z"))]
```
cc ``@jplatte``
r? ``@jyn514``
|
|
|
|
ast/hir: Rename field-related structures
I always forget what `ast::Field` and `ast::StructField` mean despite working with AST for long time, so this PR changes the naming to less confusing and more consistent.
- `StructField` -> `FieldDef` ("field definition")
- `Field` -> `ExprField` ("expression field", not "field expression")
- `FieldPat` -> `PatField` ("pattern field", not "field pattern")
Various visiting and other methods working with the fields are renamed correspondingly too.
The second commit reduces the size of `ExprKind` by boxing fields of `ExprKind::Struct` in preparation for https://github.com/rust-lang/rust/pull/80080.
|
|
Don't warn about old rustdoc lint names (temporarily)
Since https://github.com/rust-lang/rust/pull/80527, rustdoc users have an unpleasant situation: they can either use the new tool lint names (`rustdoc::non_autolinks`) or they can use the old names (`non_autolinks`). If they use the tool lints, they get a hard error on stable compilers, because rustc rejects all tool names it doesn't recognize (https://github.com/rust-lang/rust/issues/66079#issuecomment-788589193). If they use the old name, they get a warning to rename the lint to the new name. The only way to compile without warnings is to add `#[allow(renamed_removed_lints)]`, which defeats the whole point of the change: we *want* people to switch to the new name.
To avoid people silencing the lint and never migrating to the tool lint, this avoids warning about the old name, while still allowing you to use the new name. Once the new `rustdoc` tool name makes it to the stable channel, we can change these lints to warn again.
This adds the new lint functions `register_alias` and `register_ignored` - I didn't see an existing way to do this.
r? `@Manishearth` cc `@rust-lang/rustdoc`
|
|
Right now, rustdoc users have an unpleasant situation: they can either
use the new tool lint names (`rustdoc::non_autolinks`) or they can use
the old names (`non_autolinks`). If they use the tool lints, they get a
hard error on stable compilers, because rustc rejects all tool names it
doesn't recognize. If they use the old name, they get a warning to
rename the lint to the new name. The only way to compile without
warnings is to add `#[allow(renamed_removed_lints)]`, which defeats the
whole point of the change: we *want* people to switch to the new name.
To avoid people silencing the lint and never migrating to the tool lint,
this avoids warning about the old name, while still allowing you to use
the new name. Once the new `rustdoc` tool name makes it to the stable
channel, we can change these lints to warn again.
This adds the new lint functions `register_alias` and `register_ignored`
- I didn't see an existing way to do this.
|
|
No background for code in portability snippets
This better matches the appearance of this kind of snippet in the full
item view and is less jarring to read due to repeated
foreground-background changes.
There should be no observable changes to the ayu theme.
|
|
Fall-back to sans-serif if Arial is not available
Otherwise on systems where Arial is not available the UA will
fallback to a serif font, rather than a sans-serif one.
This is especially relevant on acessibility-conscious setups (such as is
mine) that have web-fonts disabled and a limited set of fonts available
on the system.
r? ```@GuillaumeGomez``` cc ```@jsha```
|
|
rustdoc: reduce GC work during search
|
