You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This will open a browser with a websocket live-link to automatically reload whenever the source is updated.
68
68
69
-
The `SPEC_RELATIVE=0` environment variable makes links to the standard library go to <https://doc.rust-lang.org/> instead of being relative, which is useful when viewing locally since you normally don't have a copy of the standard library.
70
-
71
69
You can also use mdbook's live webserver option, which will automatically rebuild the book and reload your web browser whenever a source file is modified:
72
70
73
71
```sh
74
72
SPEC_RELATIVE=0 mdbook serve --open
75
73
```
74
+
75
+
### `SPEC_RELATIVE`
76
+
77
+
The `SPEC_RELATIVE=0` environment variable makes links to the standard library go to <https://doc.rust-lang.org/> instead of being relative, which is useful when viewing locally since you normally don't have a copy of the standard library.
78
+
79
+
The published site at <https://doc.rust-lang.org/reference/> (or local docs using `rustup doc`) does not set this, which means it will use relative links which supports offline viewing and links to the correct version (for example, links in <https://doc.rust-lang.org/1.81.0/reference/> will stay within the 1.81.0 directory).
80
+
81
+
### `SPEC_DENY_WARNINGS`
82
+
83
+
The `SPEC_DENY_WARNINGS=1` environment variable will turn all warnings generated by `mdbook-spec` to errors. This is used in CI to ensure that there aren't any problems with the book content.
84
+
85
+
### `SPEC_RUST_ROOT`
86
+
87
+
The `SPEC_RUST_ROOT` can be used to point to the directory of a checkout of <https://github.com/rust-lang/rust>. This is used by the test-linking feature so that it can find tests linked to reference rules. If this is not set, then the tests won't be linked.
Copy file name to clipboardExpand all lines: docs/authoring.md
+41-1
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,8 @@ This document serves as a guide for editors and reviewers. Some conventions and
15
15
* Code blocks should have an explicit language tag.
16
16
* Do not wrap long lines. This helps with reviewing diffs of the source.
17
17
* Use [smart punctuation] instead of Unicode characters. For example, use `---` for em-dash instead of the Unicode character. Characters like em-dash can be difficult to see in a fixed-width editor, and some editors may not have easy methods to enter such characters.
18
-
* Links should be relative with the `.md` extension. Links to other rust-lang books that are published with the reference or the standard library API should also be relative so that the linkchecker can validate them.
18
+
* Links should be relative with the `.md` extension. Links to other rust-lang books that are published with the reference should also be relative so that the linkchecker can validate them.
19
+
* Links to the standard library should use rustdoc-style links described in [Standard library links](#standard-library-links).
19
20
* The use of reference links is preferred, with shortcuts if appropriate. Place the sorted link reference definitions at the bottom of the file, or at the bottom of a section if there are an unusually large number of links that are specific to the section.
20
21
21
22
```markdown
@@ -75,6 +76,45 @@ Rules can be linked to by their ID using markdown such as `[foo.bar]`. There are
75
76
76
77
In the HTML, the rules are clickable just like headers.
77
78
79
+
When assigning rules to new paragraphs, or when modifying rule names, use the following guidelines:
80
+
81
+
1. A rule applies to one core idea, which should be easily determined when reading the paragraph it is applied to.
82
+
2. Other than the "intro" paragraph, purely explanatory, expository, or exemplary content does not need a rule. If the expository paragraph isn't directly related to the previous, separate it with a hard (rendered) line break.
83
+
* This content will be moved to `[!NOTE]` or more specific admonitions in the future.
84
+
3. Rust code examples and tests do not need their own rules.
85
+
4. Use the following guidelines for admonitions:
86
+
* Notes: Do not include a rule.
87
+
* Warning: Omit the rule if the warning follows from the previous paragraph or if the warning is explanatory and doesn't introduce any new rules.
88
+
* Target specific behavior: Always include the rule.
89
+
* Edition differences: Always include the rule.
90
+
5. The following keywords should be used to identify paragraphs when unambiguous:
91
+
*`intro`: The beginning paragraph of each section - should explain the construct being defined overall.
92
+
*`syntax`: Syntax definitions or explanations when BNF syntax definitions are not used.
93
+
*`namespace`: For items only, specifies the namespace(s) the item introduces a name in. May also be used elsewhere when defining a namespace (e.g. `r[attribute.diagnostic.namespace]`).
94
+
6. When a rule doesn't fall under the above keywords, or for section rule ids, name the subrule as follows:
95
+
* If the rule is naming a specific Rust language construct (e.g. an attribute, standard library type/function, or keyword-introduced concept), use the construct as named in the language, appropriately case-adjusted (but do not replace `_`s with `-`s).
96
+
* Other than Rust language concepts with `_`s in the name, use `-` characters to separate words within a "subrule".
97
+
* Whenever possible, do not repeat previous components of the rule.
98
+
* Edition differences admonitions should typically be named by the edition referenced directly by the rule. If multiple editions are named, use the one for which the behavior is defined by the admonition, and not by a previous paragraph.
99
+
* Target specific admonitions should typically be named by the least specific target property to which they apply (e.g. if a rule affects all x86 CPUs, the rule name should include `x86` rather than separately listing `i586`, `i686` and `x86_64`, and if a rule applies to all ELF platforms, it should be named `elf` rather than listing every ELF OS).
100
+
* Use an appropriately descriptive, but short, name if the language does not provide one.
101
+
102
+
#### Test rule annotations
103
+
104
+
Tests in <https://github.com/rust-lang/rust> can be linked to rules in the reference. The rule will include a link to the tests, and there is also an [appendix] which tracks how the rules are currently linked.
105
+
106
+
Tests in the `tests` directory can be annotated with the `//@ reference: x.y.z` header to link it to a rule. The header can be specified multiple times if a single file covers multiple rules.
107
+
108
+
Compiler developers are not expected to add `reference` annotations to tests. However, if they do want to help, their cooperation is very welcome. Reference authors and editors are responsible for making sure every rule has a test associated with it.
109
+
110
+
The tests are beneficial for reviewers to see the behavior of a rule. It is also a benefit to readers who may want to see examples of particular behaviors. When adding new rules, you should wait until the reference side is approved before submitting a PR to `rust-lang/rust` (to avoid churn if we decide on different names).
111
+
112
+
Prefixed rule names should not be used in tests. That is, do not use something like `asm.rules` when there are specific rules like `asm.rules.reg-not-input`.
113
+
114
+
We are not expecting 100% coverage at any time. Although it would be nice, it is unrealistic due to the sequence things are developed, and resources available.
0 commit comments