Update docs from date triage for 2021-02 (#1048)
The biggest change was updating the list of rustdoc passes. Several new ones have been added since that documentation was written, so I added those, and I also sorted the list so it is roughly alphabetical (except for the part for the `strip-*` passes, which I left in the same order since one of the list items has two passes so there's no "correct" order).
This commit is contained in:
parent
5297659bb1
commit
c4c0f33a1d
|
|
@ -21,10 +21,6 @@ containing the compiler, the standard libraries (`core`, `alloc`, `std`,
|
||||||
`proc_macro`, etc), and `rustdoc`, along with the build system and a bunch of
|
`proc_macro`, etc), and `rustdoc`, along with the build system and a bunch of
|
||||||
tools and submodules for building a full Rust distribution.
|
tools and submodules for building a full Rust distribution.
|
||||||
|
|
||||||
As of August 2020 <!-- date: 2020-08 -->, this structure is gradually undergoing
|
|
||||||
some transformation to make it a bit less monolithic and more approachable,
|
|
||||||
especially to newcomers.
|
|
||||||
|
|
||||||
The repository consists of three main directories:
|
The repository consists of three main directories:
|
||||||
|
|
||||||
- `compiler/` contains the source code for `rustc`. It consists of many crates
|
- `compiler/` contains the source code for `rustc`. It consists of many crates
|
||||||
|
|
|
||||||
|
|
@ -250,9 +250,9 @@ Moreover, the compiler wasn't originally built to use a query system; the query
|
||||||
system has been retrofitted into the compiler, so parts of it are not query-fied
|
system has been retrofitted into the compiler, so parts of it are not query-fied
|
||||||
yet. Also, LLVM isn't our code, so that isn't querified either. The plan is to
|
yet. Also, LLVM isn't our code, so that isn't querified either. The plan is to
|
||||||
eventually query-fy all of the steps listed in the previous section, but as of
|
eventually query-fy all of the steps listed in the previous section, but as of
|
||||||
April 2020 <!-- date: 2020-04 -->, only the steps between HIR and LLVM-IR are
|
February 2021 <!-- date: 2021-02 -->, only the steps between HIR and LLVM IR are
|
||||||
query-fied. That is, lexing and parsing are done all at once for the whole
|
query-fied. That is, lexing, parsing, name resolution, and macro expansion are
|
||||||
program.
|
done all at once for the whole program.
|
||||||
|
|
||||||
One other thing to mention here is the all-important "typing context",
|
One other thing to mention here is the all-important "typing context",
|
||||||
[`TyCtxt`], which is a giant struct that is at the center of all things.
|
[`TyCtxt`], which is a giant struct that is at the center of all things.
|
||||||
|
|
|
||||||
|
|
@ -22,9 +22,9 @@ There are a few basic ideas in this effort:
|
||||||
|
|
||||||
[`rayon`]: https://crates.io/crates/rayon
|
[`rayon`]: https://crates.io/crates/rayon
|
||||||
|
|
||||||
As of May 2020 <!-- date: 2020-05 -->, much of this effort is on hold due to
|
As of February 2021 <!-- date: 2021-02 -->, much of this effort is on hold due
|
||||||
lack of manpower. We have a working prototype with promising performance gains
|
to lack of manpower. We have a working prototype with promising performance
|
||||||
in many cases. However, there are two blockers:
|
gains in many cases. However, there are two blockers:
|
||||||
|
|
||||||
- It's not clear what invariants need to be upheld that might not hold in the
|
- It's not clear what invariants need to be upheld that might not hold in the
|
||||||
face of concurrency. An auditing effort was underway, but seems to have
|
face of concurrency. An auditing effort was underway, but seems to have
|
||||||
|
|
|
||||||
|
|
@ -58,7 +58,7 @@ markdown parser, or drop items that are not public or deliberately hidden with
|
||||||
file per pass. By default, all of these passes are run on a crate, but the ones
|
file per pass. By default, all of these passes are run on a crate, but the ones
|
||||||
regarding dropping private/hidden items can be bypassed by passing
|
regarding dropping private/hidden items can be bypassed by passing
|
||||||
`--document-private-items` to rustdoc. Note that unlike the previous set of AST
|
`--document-private-items` to rustdoc. Note that unlike the previous set of AST
|
||||||
transformations, the passes happen on the _cleaned_ crate.
|
transformations, the passes are run on the _cleaned_ crate.
|
||||||
|
|
||||||
(Strictly speaking, you can fine-tune the passes run and even add your own, but
|
(Strictly speaking, you can fine-tune the passes run and even add your own, but
|
||||||
[we're trying to deprecate that][44136]. If you need finer-grain control over
|
[we're trying to deprecate that][44136]. If you need finer-grain control over
|
||||||
|
|
@ -66,29 +66,66 @@ these passes, please let us know!)
|
||||||
|
|
||||||
[44136]: https://github.com/rust-lang/rust/issues/44136
|
[44136]: https://github.com/rust-lang/rust/issues/44136
|
||||||
|
|
||||||
Here is the list of passes as of March 2018 <!-- date: 2018-03 -->:
|
Here is the list of passes as of February 2021 <!-- date: 2021-02 -->:
|
||||||
|
|
||||||
|
- `calculate-doc-coverage` calculates information used for the `--show-coverage`
|
||||||
|
flag.
|
||||||
|
|
||||||
|
- `check-code-block-syntax` validates syntax inside Rust code blocks
|
||||||
|
(`` ```rust ``)
|
||||||
|
|
||||||
|
- `check-invalid-html-tags` detects invalid HTML (like an unclosed `<span>`)
|
||||||
|
in doc comments.
|
||||||
|
|
||||||
|
- `check-non-autolinks` detects links that could or should be written using
|
||||||
|
angle brackets (the code behind the nightly-only <!-- date: 2021-02 -->
|
||||||
|
`non_autolinks` lint).
|
||||||
|
|
||||||
- `propagate-doc-cfg` - propagates `#[doc(cfg(...))]` to child items.
|
|
||||||
- `collapse-docs` concatenates all document attributes into one document
|
- `collapse-docs` concatenates all document attributes into one document
|
||||||
attribute. This is necessary because each line of a doc comment is given as a
|
attribute. This is necessary because each line of a doc comment is given as a
|
||||||
separate doc attribute, and this will combine them into a single string with
|
separate doc attribute, and this will combine them into a single string with
|
||||||
line breaks between each attribute.
|
line breaks between each attribute.
|
||||||
- `unindent-comments` removes excess indentation on comments in order for
|
|
||||||
markdown to like it. This is necessary because the convention for writing
|
- `collect-intra-doc-links` resolves [intra-doc links](https://doc.rust-lang.org/rustdoc/linking-to-items-by-name.html).
|
||||||
documentation is to provide a space between the `///` or `//!` marker and the
|
|
||||||
text, and stripping that leading space will make the text easier to parse by
|
- `collect-trait-impls` collects trait impls for each item in the crate. For
|
||||||
the Markdown parser. (In the past, the markdown parser used was not
|
example, if we define a struct that implements a trait, this pass will note
|
||||||
Commonmark- compliant, which caused annoyances with extra whitespace but this
|
that the struct implements that trait.
|
||||||
seems to be less of an issue today.)
|
|
||||||
|
- `doc-test-lints` runs various lints on the doctests.
|
||||||
|
|
||||||
|
- `propagate-doc-cfg` propagates `#[doc(cfg(...))]` to child items.
|
||||||
|
|
||||||
- `strip-priv-imports` strips all private import statements (`use`, `extern
|
- `strip-priv-imports` strips all private import statements (`use`, `extern
|
||||||
crate`) from a crate. This is necessary because rustdoc will handle *public*
|
crate`) from a crate. This is necessary because rustdoc will handle *public*
|
||||||
imports by either inlining the item's documentation to the module or creating
|
imports by either inlining the item's documentation to the module or creating
|
||||||
a "Reexports" section with the import in it. The pass ensures that all of
|
a "Reexports" section with the import in it. The pass ensures that all of
|
||||||
these imports are actually relevant to documentation.
|
these imports are actually relevant to documentation.
|
||||||
|
|
||||||
- `strip-hidden` and `strip-private` strip all `doc(hidden)` and private items
|
- `strip-hidden` and `strip-private` strip all `doc(hidden)` and private items
|
||||||
from the output. `strip-private` implies `strip-priv-imports`. Basically, the
|
from the output. `strip-private` implies `strip-priv-imports`. Basically, the
|
||||||
goal is to remove items that are not relevant for public documentation.
|
goal is to remove items that are not relevant for public documentation.
|
||||||
|
|
||||||
|
- `unindent-comments` removes excess indentation on comments in order for the
|
||||||
|
Markdown to be parsed correctly. This is necessary because the convention for
|
||||||
|
writing documentation is to provide a space between the `///` or `//!` marker
|
||||||
|
and the doc text, but Markdown is whitespace-sensitive. For example, a block
|
||||||
|
of text with four-space indentation is parsed as a code block, so if we didn't
|
||||||
|
unindent comments, these list items
|
||||||
|
|
||||||
|
```rust,ignore
|
||||||
|
/// A list:
|
||||||
|
///
|
||||||
|
/// - Foo
|
||||||
|
/// - Bar
|
||||||
|
```
|
||||||
|
|
||||||
|
would be parsed as if they were in a code block, which is likely not what the
|
||||||
|
user intended.
|
||||||
|
|
||||||
|
There is also a `stripper` module in `passes/`, but it is a collection of
|
||||||
|
utility functions for the `strip-*` passes and is not a pass itself.
|
||||||
|
|
||||||
## From clean to crate
|
## From clean to crate
|
||||||
|
|
||||||
This is where the "second phase" in rustdoc begins. This phase primarily lives
|
This is where the "second phase" in rustdoc begins. This phase primarily lives
|
||||||
|
|
@ -224,4 +261,3 @@ on the internet. For example, the url for `std` will be `/std/".
|
||||||
|
|
||||||
[`rustdoc` api docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/
|
[`rustdoc` api docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/
|
||||||
[The rustdoc user guide]: https://doc.rust-lang.org/nightly/rustdoc/
|
[The rustdoc user guide]: https://doc.rust-lang.org/nightly/rustdoc/
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -339,8 +339,8 @@ The error levels that you can have are:
|
||||||
|
|
||||||
## Revisions
|
## Revisions
|
||||||
|
|
||||||
Certain classes of tests support "revisions" (as of February 2018 <!-- date:
|
Certain classes of tests support "revisions" (as of February 2021 <!-- date:
|
||||||
2018-02 -->, this includes compile-fail, run-fail, and incremental, though
|
2021-02 -->, this includes compile-fail, run-fail, and incremental, though
|
||||||
incremental tests are somewhat different). Revisions allow a single test file to
|
incremental tests are somewhat different). Revisions allow a single test file to
|
||||||
be used for multiple tests. This is done by adding a special header at the top
|
be used for multiple tests. This is done by adding a special header at the top
|
||||||
of the file:
|
of the file:
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue