| Age | Commit message (Collapse) | Author | Lines |
|
rustdoc: Cleanup ABI rendering
Use a common method for rendering `extern "<abi>"`.
This now consistently shows `extern fn` rather than `extern "C" fn`.
|
|
rustdoc: Handle concurrent mkdir requests
It's likely that `rustdoc` as a tool is run concurrently in the same output
(e.g. documenting multiple crates as Cargo does), in which case it needs to
handle concurrent calls to `fs::create_dir`.
|
|
rustdoc: Linkify extern crates
fixes #33178
r? @alexcrichton
|
|
rustdoc: Improve accessibility of rustdoc pages
fixes #33131
r? @alexcrichton
|
|
show unstable status for deprecated items
Fixes #32374.
|
|
|
|
|
|
It's likely that `rustdoc` as a tool is run concurrently in the same output
(e.g. documenting multiple crates as Cargo does), in which case it needs to
handle concurrent calls to `fs::create_dir`.
|
|
|
|
Due to inlining it is possible to visit the same module multiple times
during `<Cache as DocFolder>::fold_crate`, so we keep track of the
modules we've already visited.
|
|
Use a common method for rendering `extern "<abi>"`.
This now consistently shows `extern "C" fn` rather than just `extern fn`.
|
|
rustdoc: refine cross-crate impl inlining
This changes the current rule that impls within `doc(hidden)` modules aren't inlined, to only inlining impls where the implemented trait and type are reachable in documentation.
fixes #14586
fixes #31948
.. and also applies the reachability checking to cross-crate links.
fixes #28480
r? @alexcrichton
|
|
rustdoc: Disambiguate anchors
Closes https://github.com/rust-lang/rust/issues/32890
|
|
Avoid linking to itself in implementors section of trait page
Fix #32474.
|
|
|
|
|
|
This changes the current rule that impls within `doc(hidden)` modules
aren't inlined, to only inlining impls where the implemented
trait and type are reachable in documentation.
|
|
Implement `pub(restricted)` privacy (RFC 1422)
This implements `pub(restricted)` privacy from RFC 1422 (cc #32409) behind a feature gate.
`pub(restricted)` paths currently cannot use re-exported modules both for simplicity of implementation and for future compatibility with RFC 1560 (cf #31783).
r? @nikomatsakis
|
|
We don't want to render default item docs but previously
`doctraititem` naively delegated to the trait definition in those
cases.
Updated tests to also check that this doesn't strip default item
docs from the trait definition.
|
|
|
|
Add test to check this resolves #24838 and #26871.
|
|
The thread-local isn't needed and consists of mostly empty fields which
were just used to move the data into `html::render::CACHE_KEY`.
|
|
|
|
Add --extend-css option to rustdoc
Fixes #32223
r? @brson
|
|
|
|
|
|
|
|
rustdoc: factor out function for getting inner html of highlighted source
|
|
|
|
|
|
|
|
Like the comment on `Context` explains, `Context` is supposed to be
lightweight, so we're putting everything that's immutable after
creation of the Context behind an `Arc<SharedContext>`.
|
|
|
|
Instead of hardcoding knowledge about the strip-private pass into the
rendering process we represent (some) stripped items as `ItemEnum::StrippedItem`.
Rustdoc will, for example, generate redirect pages for public items
contained in private modules which have been re-exported to somewhere
externally reachable - this will now not only work for the `strip-private`
pass, but for other passes as well, such as the `strip-hidden` pass.
|
|
|
|
Adding these "known" values to the table of used ids is only required
when embedding markdown into a rustdoc html page and may yield
unexpected results when rendering a standalone `*.md` file.
|
|
|
|
These should always correspond to the values in `ItemType::to_static_str`
|
|
|
|
Rollup of 11 pull requests
- Successful merges: #32404, #32420, #32423, #32425, #32429, #32430, #32431, #32434, #32437, #32441, #32443
- Failed merges:
|
|
|
|
Automated conversion using the untry tool [1] and the following command:
```
$ find -name '*.rs' -type f | xargs untry
```
at the root of the Rust repo.
[1]: https://github.com/japaric/untry
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Since we emit the sources beforhand we actually **know** whether we
can safely create src-links to these files and where they are stored.
|