| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Wrap non-pre code blocks
Fix #83550 regression
```
$ cargo new --lib whitespace && cd whitespace && echo '//! `" foo "`' > src/lib.rs && cargo doc --open
```
Before
After
r? ``@GuillaumeGomez``
cc ``@mgeisler``
|
|
Rollup of 7 pull requests
Successful merges:
- #82331 (alloc: Added `as_slice` method to `BinaryHeap` collection)
- #83130 (escape_ascii take 2)
- #83374 (unix: Fix feature(unix_socket_ancillary_data) on macos and other BSDs)
- #83543 (Lint on unknown intra-doc link disambiguators)
- #83636 (Add a regression test for issue-82792)
- #83643 (Remove a FIXME resolved by #73578)
- #83644 (:arrow_up: rust-analyzer)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Lint on unknown intra-doc link disambiguators
|
|
rustdoc: Don't enter an infer_ctxt in get_blanket_impls for impls that aren't blanket impls
Less broken version of https://github.com/rust-lang/rust/pull/82856.
get_blanket_impls is a *very* hot region of rustdoc, so even small changes like this should help. Unfortunately I don't have benchmarks for this until https://github.com/rust-lang/rustc-perf/pull/802 is merged.
|
|
Fix #83550 regression
|
|
|
|
And, now that we do that, we can remove the explanatory note since the
error span should make it clear what the disambiguator is.
|
|
rustdoc: Use diagnostics for error when including sources
This error probably almost never happens, but we should still use the
diagnostic infrastructure. My guess is that the error was added back
before rustdoc used the rustc diagnostic infrastructure (it was all
`println!` and `eprintln!` back then!) and since it likely rarely occurs
and this code doesn't change that much, no one thought to transition it
to using diagnostics.
Note that the old error was actually a warning (it didn't stop the rest
of doc building). It seems very unlikely that this would fail without
the rest of the doc build failing, so it makes more sense for it to be a
hard error.
The error looks like this:
error: failed to render source code for `src/test/rustdoc/smart-punct.rs`: "bar": foo
--> src/test/rustdoc/smart-punct.rs:3:1
|
3 | / #![crate_name = "foo"]
4 | |
5 | | //! This is the "start" of the 'document'! How'd you know that "it's" ...
6 | | //!
... |
22 | | //! I say "don't smart-punct me -- please!"
23 | | //! ```
| |_______^
I wasn't sure how to trigger the error, so to create that message I
temporarily made rustdoc always emit it. That's also why it says "bar"
and "foo" instead of a real error message.
Note that the span of the diagnostic starts at line 3 because line 1 of
that file is a (non-doc) comment and line 2 is a blank line.
|
|
|
|
[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
|
|
This error probably almost never happens, but we should still use the
diagnostic infrastructure. My guess is that the error was added back
before rustdoc used the rustc diagnostic infrastructure (it was all
`println!` and `eprintln!` back then!) and since it likely rarely occurs
and this code doesn't change that much, no one thought to transition it
to using diagnostics.
Note that the old error was actually a warning (it didn't stop the rest
of doc building). It seems very unlikely that this would fail without
the rest of the doc build failing, so it makes more sense for it to be a
hard error.
The error looks like this:
error: failed to render source code for `src/test/rustdoc/smart-punct.rs`: "bar": foo
--> src/test/rustdoc/smart-punct.rs:3:1
|
3 | / #![crate_name = "foo"]
4 | |
5 | | //! This is the "start" of the 'document'! How'd you know that "it's" ...
6 | | //!
... |
22 | | //! I say "don't smart-punct me -- please!"
23 | | //! ```
| |_______^
I wasn't sure how to trigger the error, so to create that message I
temporarily made rustdoc always emit it. That's also why it says "bar"
and "foo" instead of a real error message.
Note that the span of the diagnostic starts at line 3 because line 1 of
that file is a (non-doc) comment and line 2 is a blank line.
|
|
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`
|
