| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Reduce prominence of item-infos
Fixes #59853
- Remove border.
- Reduce size of emoji slightly.
- Remove details disclosure for unstable reason. This was inconsistent with our other details disclosures, and the detail revealed was usually better explained by clicking on the issue link.
Demo: https://rustdoc.crud.net/jsha/chill-item-info/std/mem/union.MaybeUninit.html#method.slice_assume_init_ref
Compare vs: https://doc.rust-lang.org/nightly/std/mem/union.MaybeUninit.html#method.slice_assume_init_ref
<img src="https://user-images.githubusercontent.com/220205/142717815-09828c9e-6ff4-445a-8ccc-31e028fd4985.png" width=700>
|
|
Create rustdoc_internals feature gate
As suggested by ``@camelid`` [here](https://github.com/rust-lang/rust/pull/90398#issuecomment-955093851), since `doc_keyword` and `doc_primitive` aren't meant to be stabilized, we could put them behind a same feature flag.
This is pretty much what it would look like (needs to update the tests too).
The tracking issue is https://github.com/rust-lang/rust/issues/90418.
What do you think ``@rust-lang/rustdoc`` ?
|
|
This is a step toward adding more test coverage to make it easier to
remove the distinction between collapsed and uncollapsed doc values.
|
|
|
|
Avoid documenting top-level private imports
PR #88447 aimed to make rustdoc's `--document-private-items` mode only document imports that are visible outside the importing module. Unfortunately, I inadvertently set things up so that imports at the crate top-level are always documented, regardless of their visibility. This behavior was unintended and is [not desirable](https://github.com/rust-lang/rust/issues/90865#issuecomment-971172649).
This PR treats top-level imports as never being visible outside their parent module. In practice, the only way a top-level import can be visible externally is if it's fully public, and there's a seperate check for that.
It's worth calling attention to the fact that this change means that `pub(crate)` imports will be visible in lower level modules, but not at the top-level. This is because, at the top level of the crate, `pub(crate)` means the same thing as `pub(self)`.
It turned out that there were existing tests checking for the only behavior, which I didn't notice at the time of my previous PR. I have updated them to check for the new behavior and substantially extended them to handle differences between the top-level module and lower level modules. I may have gone overboard, so please tell me if there's anything I should cut.
r? `@jyn514`
Fixes #90865.
|
|
|
|
- Remove border.
- Reduce size of emoji slightly.
- Remove details disclosure for unstable reason. This was inconsistent
with our other details disclosures, and the detail revealed was
usually better explained by clicking on the issue link.
|
|
Improve display of enum variants
Use h3 and h4 for the variant name and the "Fields" subheading.
Remove the "of T" part of the "Fields" subheading.
Remove border-bottom from "Fields" subheading.
Move docblock below "Fields" listing.
Fixes #90061
Demo:
https://jacob.hoffman-andrews.com/rust/xmlparser-updated/xmlparser/enum.Token.html#variants
https://jacob.hoffman-andrews.com/rust/fix-enum-variants/std/io/enum.ErrorKind.html#variants
https://jacob.hoffman-andrews.com/rust/fix-enum-variants/std/result/enum.Result.html#variants
r? ``@camelid``
|
|
|
|
|
|
Use h3 and h4 for the variant name and the "Fields" subheading.
Remove the "of T" part of the "Fields" subheading.
Remove border-bottom from "Fields" subheading.
Move docblock below "Fields" listing.
|
|
|
|
which don't have `self` argument)
|
|
|
|
Fix rustdoc UI for very long type names
Fixes #89972.
While working on it, I also discovered that when the item name is too long, it also breaks the flow of the page.
To make things right, I also renamed the `type-decl` CSS class into `item-decl` (because this PR also generates it for more than type declarations).
So here are the before/after screenshots:
r? ``@jsha``
|
|
Fix macro_rules! duplication when reexported in the same module
This can append if within the same module a `#[macro_export] macro_rules!`
is declared but also a reexport of itself producing two export of the same
macro in the same module. In that case we only want to document it once.
Before:
```
Module {
is_crate: true,
items: [
Id("0:4"), // pub use crate::repro as repro2;
Id("0:3"), // macro_rules! repro
Id("0:3"), // duplicate, same as above
],
}
```
After:
```
Module {
is_crate: true,
items: [
Id("0:4"), // pub use crate::repro as repro2;
Id("0:3"), // macro_rules! repro
],
}
```
Fixes https://github.com/rust-lang/rust/issues/89852
|
|
* Rename "type-decl" into "item-decl" to reflect the change of usage
|
|
|
|
|
|
|
|
Make rustdoc not highlight `->` and `=>` as operators
It was marking them up as `<span class="op">=</span><span class="op">></span>`,
which is bloaty and wrong (at least, I think `<=` and `=>` should probably be different colors, since they're so different and yet made from the same symbols).
Before:
After:
|
|
Make cfg imply doc(cfg)
This is a reopening of #79341, rebased and modified a bit (we made a lot of refactoring in rustdoc's types so they needed to be reflected in this PR as well):
* `hidden_cfg` is now in the `Cache` instead of `DocContext` because `cfg` information isn't stored anymore on `clean::Attributes` type but instead computed on-demand, so we need this information in later parts of rustdoc.
* I removed the `bool_to_options` feature (which makes the code a bit simpler to read for `SingleExt` trait implementation.
* I updated the version for the feature.
There is only one thing I couldn't figure out: [this comment](https://github.com/rust-lang/rust/pull/79341#discussion_r561855624)
> I think I'll likely scrap the whole `SingleExt` extension trait as the diagnostics for 0 and >1 items should be different.
How/why should they differ?
EDIT: this part has been solved, the current code was fine, just needed a little simplification.
cc `@Nemo157`
r? `@jyn514`
Original PR description:
This is only active when the `doc_cfg` feature is active.
The implicit cfg can be overridden via `#[doc(cfg(...))]`, so e.g. to hide a `#[cfg]` you can use something like:
```rust
#[cfg(unix)]
#[doc(cfg(all()))]
pub struct Unix;
```
By adding `#![doc(cfg_hide(foobar))]` to the crate attributes the cfg `#[cfg(foobar)]` (and _only_ that _exact_ cfg) will not be implicitly treated as a `doc(cfg)` to render a message in the documentation.
|
|
By adding #![doc(cfg_hide(foobar))] to the crate attributes the cfg
#[cfg(foobar)] (and _only_ that _exact_ cfg) will not be implicitly
treated as a doc(cfg) to render a message in the documentation.
|
|
This is only active when the `doc_cfg` feature is active.
The implicit cfg can be overridden via #[doc(cfg(...))], so e.g. to
hide a #[cfg] you can use something like:
```rust
#[cfg(unix)]
#[doc(cfg(all()))]
pub struct Unix;
```
(since `all()` is always true, it is never shown in the docs)
|
|
|
|
|
|
- Avoid multiple <h1>s on a page.
- The <h#> tags should follow a semantic hierarchy.
- Cap at h6 (no h7)
|
|
rustdoc: Don't show hidden trait methods
Fix #89186.
By skipping trait items whose attributes include `hidden`, we avoid showing such trait methods.
|
|
By skipping trait items whose attributes include `hidden`, we void
showing
such trait methods.
|
|
|
|
Windows on Macos ARM64 produce linker errors.
|
|
|
|
rustdoc: Cleanup `clean` part 1
Split out from #88379.
These commits are completely independent of each other, and each is a fairly
small change (the last few are new commits; they are not from #88379):
- Remove unnecessary `Cache.*_did` fields
- rustdoc: Get symbol for `TyParam` directly
- Create a valid `Res` in `external_path()`
- Remove unused `hir_id` parameter from `resolve_type`
- Fix redundant arguments in `external_path()`
- Remove unnecessary `is_trait` argument
- rustdoc: Cleanup a pattern match in `external_generic_args()`
r? ``@jyn514``
|
|
This prevents the following (very strange) errors:
```
error: linking with `link.exe` failed: exit code: 1120
|
= note: "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Enterprise\\VC\\Tools\\MSVC\\14.29.30133\\bin\\HostX64\\x86\\link.exe" "/DEF:C:\\Users\\runneradmin\\AppData\\Local\\Temp\\rustcJih4fa\\lib.def" "/NOLOGO" "/LARGEADDRESSAWARE" "/SAFESEH" "D:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\test\\rustdoc\\issue-15318-2\\auxiliary\\issue-15318.issue_15318.0a2a8554-cgu.0.rcgu.o" "D:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\test\\rustdoc\\issue-15318-2\\auxiliary\\issue-15318.1na9aylmt25n6w3f.rcgu.o" "/LIBPATH:D:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\native\\rust-test-helpers" "/LIBPATH:D:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\test\\rustdoc\\issue-15318-2\\auxiliary" "/LIBPATH:D:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\stage2\\lib\\rustlib\\i686-pc-windows-msvc\\lib" "vcruntime.lib" "ucrt.lib" "/WHOLEARCHIVE:D:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\stage2\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\librustc_std_workspace_core-78744e1360284b1e.rlib" "/WHOLEARCHIVE:D:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\stage2\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libcore-a900fa3d16956226.rlib" "D:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\stage2\\lib\\rustlib\\i686-pc-windows-msvc\\lib\\libcompiler_builtins-eb97e6b4dfd2f421.rlib" "/NXCOMPAT" "/LIBPATH:D:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\stage2\\lib\\rustlib\\i686-pc-windows-msvc\\lib" "/OUT:D:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\test\\rustdoc\\issue-15318-2\\auxiliary\\issue_15318.dll" "/OPT:REF,ICF" "/DLL" "/IMPLIB:D:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\test\\rustdoc\\issue-15318-2\\auxiliary\\issue_15318.dll.lib" "/DEBUG" "/NATVIS:D:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\stage2\\lib\\rustlib\\etc\\intrinsic.natvis" "/NATVIS:D:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\stage2\\lib\\rustlib\\etc\\liballoc.natvis" "/NATVIS:D:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\stage2\\lib\\rustlib\\etc\\libcore.natvis" "/NATVIS:D:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\stage2\\lib\\rustlib\\etc\\libstd.natvis"
= note: LINK : warning LNK4216: Exported entry point __DllMainCRTStartup@12
Creating library D:\a\rust\rust\build\i686-pc-windows-msvc\test\rustdoc\issue-15318-2\auxiliary\issue_15318.dll.lib and object D:\a\rust\rust\build\i686-pc-windows-msvc\test\rustdoc\issue-15318-2\auxiliary\issue_15318.dll.exp
libcore-a900fa3d16956226.rlib(core-a900fa3d16956226.core.95dedc69-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol __aulldiv referenced in function __ZN4core3num7dec2flt7decimal7Decimal10left_shift17hfb9b6c23d6ff0383E
libcompiler_builtins-eb97e6b4dfd2f421.rlib(compiler_builtins-eb97e6b4dfd2f421.compiler_builtins.a5ef280a-cgu.51.rcgu.o) : error LNK2001: unresolved external symbol __aulldiv
libcore-a900fa3d16956226.rlib(core-a900fa3d16956226.core.95dedc69-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol __aullrem referenced in function __ZN4core3fmt3num14parse_u64_into17h90eb20517ec3bd86E
D:\a\rust\rust\build\i686-pc-windows-msvc\test\rustdoc\issue-15318-2\auxiliary\issue_15318.dll : fatal error LNK1120: 2 unresolved externals
```
|
|
Most of these are because alloc uses `#[lang_item]` to define methods,
but core documents primitives before those methods are available.
- Fix rustdoc-js-std test
For some reason this change made CStr not show up in the results for
`str,u8`. Since it still shows up for str, and since it wasn't a great
match for that query anyway, I think this is ok to let slide.
- Add test that all primitives can be linked to
- Enable `doc(primitive)` in `core` as well
- Add linkcheck exception specifically for Windows
Ideally this would be done automatically by the linkchecker by
replacing `\\` with forward slashes, but this PR is already a ton of
work ...
- Don't forcibly fail linkchecking if there's a broken intra-doc link on Windows
Previously, it would exit with a hard error if a missing file had `::`
in it. This changes it to report a missing file instead, which allows
adding an exception.
|
|
- Fix broken handling of primitive associated items
- Remove fragment hack
Fixes 83083
- more logging
- Update CrateNum hacks
The CrateNum has no relation to where in the dependency tree the crate
is, only when it's loaded. Explicitly special-case core instead of
assuming it will be the first DefId.
- Update and add tests
- Cache calculation of primitive locations
This could possibly be avoided by passing a Cache into
collect_intra_doc_links; but that's a much larger change, and doesn't
seem valuable other than for this.
|
|
This works by doing two things:
- Adding links that are specific to the crate. Since not all primitive
items are defined in `core` (due to lang_items), these need to use
relative links and not intra-doc links.
- Duplicating `primitive_docs` in both core and std. This allows not needing CARGO_PKG_NAME to build the standard library. It also adds a tidy check to make sure they stay the same.
|
|
The order of the `where` bounds on auto trait impls changed because
rustdoc currently sorts auto trait `where` bounds based on the `Debug`
output for the bound. Now that the bounds have an actual `Res`, they are
being unintentionally sorted by their `DefId` rather than their path.
So, I had to update a test for the change in ordering of the rendered
bounds.
|
|
Fix table in docblocks
"Overwrite" of #88702.
Instead of adding a z-index to the sidebar (which only hides the issue, doesn't fix it), I wrap `<table>` elements inside a `<div>` and limit all chidren of `.docblock` elements' width to prevent having the scrollbar on the whole doc block.
Thanks `@nbdd0121` for `overflow-x: auto;`. ;)
r? `@notriddle`
|
|
rustdoc: Fix ICE with `doc(hidden)` on tuple variant fields
Fixes #88600.
```rust
pub struct H;
pub struct S;
pub enum FooEnum {
HiddenTupleItem(#[doc(hidden)] H),
MultipleHidden(#[doc(hidden)] H, #[doc(hidden)] H),
MixedHiddenFirst(#[doc(hidden)] H, S),
MixedHiddenLast(S, #[doc(hidden)] H),
HiddenStruct {
#[doc(hidden)]
h: H,
s: S,
},
}
```
Generates
|
|
Rustdoc: Report Layout of enum variants
Followup of #83501, Fixes #86253.
cc `@camelid`
`@rustbot` label A-rustdoc
|
|
|
|
this also renders them as `_`, which rustdoc previously did not.
|
|
|
|
r=camelid,Manishearth
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`
|
|
|
|
|
|
|
|
Followup of #83501, Fixes #86253.
|
|
|
