mirror
/
rustc-dev-guide
mirror of https://github.com/rust-lang/rustc-dev-guide.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Consistent ordered list indexing

This commit is contained in:
RCoder01 2022-11-08 02:35:45 -05:00 committed by Tshepang Mbambo
parent f541555701
commit 623c6246e9
4 changed files with 51 additions and 51 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
src/bug-fix-procedure.md
View File

@ -53,9 +53,9 @@ Please see [the RFC][rfc 1122] for full details!
The procedure for making a breaking change is as follows (each of these steps is
described in more detail below):
0. Do a **crater run** to assess the impact of the change.
1. Make a **special tracking issue** dedicated to the change.
1. Do not report an error right away. Instead, **issue forwards-compatibility
1. Do a **crater run** to assess the impact of the change.
2. Make a **special tracking issue** dedicated to the change.
3. Do not report an error right away. Instead, **issue forwards-compatibility
lint warnings**.
- Sometimes this is not straightforward. See the text below for suggestions
on different techniques we have employed in the past.
@ -65,7 +65,7 @@ described in more detail below):
- Submit PRs to all known affected crates that fix the issue
- or, at minimum, alert the owners of those crates to the problem and
direct them to the tracking issue
1. Once the change has been in the wild for at least one cycle, we can
4. Once the change has been in the wild for at least one cycle, we can
**stabilize the change**, converting those warnings into errors.
Finally, for changes to `rustc_ast` that will affect plugins, the general policy

78
src/macro-expansion.md
View File

@ -48,45 +48,45 @@ iteration, this represents a compile error. Here is the [algorithm][original]:
[fef]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/struct.MacroExpander.html#method.fully_expand_fragment
[original]: https://github.com/rust-lang/rust/pull/53778#issuecomment-419224049
0. Initialize an `queue` of unresolved macros.
1. Repeat until `queue` is empty (or we make no progress, which is an error):
0. [Resolve](./name-resolution.md) imports in our partially built crate as
much as possible.
1. Collect as many macro [`Invocation`s][inv] as possible from our
partially built crate (fn-like, attributes, derives) and add them to the
queue.
2. Dequeue the first element, and attempt to resolve it.
3. If it's resolved:
0. Run the macro's expander function that consumes a [`TokenStream`] or
AST and produces a [`TokenStream`] or [`AstFragment`] (depending on
the macro kind). (A `TokenStream` is a collection of [`TokenTree`s][tt],
each of which are a token (punctuation, identifier, or literal) or a
delimited group (anything inside `()`/`[]`/`{}`)).
- At this point, we know everything about the macro itself and can
call `set_expn_data` to fill in its properties in the global data;
that is the hygiene data associated with `ExpnId`. (See [the
"Hygiene" section below][hybelow]).
1. Integrate that piece of AST into the big existing partially built
AST. This is essentially where the "token-like mass" becomes a
proper set-in-stone AST with side-tables. It happens as follows:
- If the macro produces tokens (e.g. a proc macro), we parse into
an AST, which may produce parse errors.
- During expansion, we create `SyntaxContext`s (hierarchy 2). (See
[the "Hygiene" section below][hybelow])
- These three passes happen one after another on every AST fragment
freshly expanded from a macro:
- [`NodeId`]s are assigned by [`InvocationCollector`]. This
also collects new macro calls from this new AST piece and
adds them to the queue.
- ["Def paths"][defpath] are created and [`DefId`]s are
assigned to them by [`DefCollector`].
- Names are put into modules (from the resolver's point of
view) by [`BuildReducedGraphVisitor`].
2. After expanding a single macro and integrating its output, continue
to the next iteration of [`fully_expand_fragment`][fef].
4. If it's not resolved:
0. Put the macro back in the queue
1. Continue to next iteration...
1. Initialize an `queue` of unresolved macros.
2. Repeat until `queue` is empty (or we make no progress, which is an error):
1. [Resolve](./name-resolution.md) imports in our partially built crate as
much as possible.
2. Collect as many macro [`Invocation`s][inv] as possible from our
partially built crate (fn-like, attributes, derives) and add them to the
queue.
3. Dequeue the first element, and attempt to resolve it.
4. If it's resolved:
1. Run the macro's expander function that consumes a [`TokenStream`] or
AST and produces a [`TokenStream`] or [`AstFragment`] (depending on
the macro kind). (A `TokenStream` is a collection of [`TokenTree`s][tt],
each of which are a token (punctuation, identifier, or literal) or a
delimited group (anything inside `()`/`[]`/`{}`)).
- At this point, we know everything about the macro itself and can
call `set_expn_data` to fill in its properties in the global data;
that is the hygiene data associated with `ExpnId`. (See [the
"Hygiene" section below][hybelow]).
2. Integrate that piece of AST into the big existing partially built
AST. This is essentially where the "token-like mass" becomes a
proper set-in-stone AST with side-tables. It happens as follows:
- If the macro produces tokens (e.g. a proc macro), we parse into
an AST, which may produce parse errors.
- During expansion, we create `SyntaxContext`s (hierarchy 2). (See
[the "Hygiene" section below][hybelow])
- These three passes happen one after another on every AST fragment
freshly expanded from a macro:
- [`NodeId`]s are assigned by [`InvocationCollector`]. This
also collects new macro calls from this new AST piece and
adds them to the queue.
- ["Def paths"][defpath] are created and [`DefId`]s are
assigned to them by [`DefCollector`].
- Names are put into modules (from the resolver's point of
view) by [`BuildReducedGraphVisitor`].
3. After expanding a single macro and integrating its output, continue
to the next iteration of [`fully_expand_fragment`][fef].
5. If it's not resolved:
1. Put the macro back in the queue
2. Continue to next iteration...
[defpath]: hir.md#identifiers-in-the-hir
[`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html

6
src/part-5-intro.md
View File

@ -21,16 +21,16 @@ Now, we will finally take the MIR and produce some executable machine code.
So what do we need to do?
0. First, we need to collect the set of things to generate code for.
1. First, we need to collect the set of things to generate code for.
In particular,
we need to find out which concrete types to substitute for generic ones,
since we need to generate code for the concrete types.
Generating code for the concrete types
(i.e. emitting a copy of the code for each concrete type) is called _monomorphization_,
so the process of collecting all the concrete types is called _monomorphization collection_.
1. Next, we need to actually lower the MIR to a codegen IR
2. Next, we need to actually lower the MIR to a codegen IR
(usually LLVM IR) for each concrete type we collected.
2. Finally, we need to invoke the codegen backend,
3. Finally, we need to invoke the codegen backend,
which runs a bunch of optimization passes,
generates executable code,
and links together an executable binary.

10
src/stability.md
View File

@ -72,14 +72,14 @@ Furthermore this attribute is needed to mark an intrinsic as callable from
To stabilize a feature, follow these steps:
0. Ask a **@T-libs-api** member to start an FCP on the tracking issue and wait for
1. Ask a **@T-libs-api** member to start an FCP on the tracking issue and wait for
the FCP to complete (with `disposition-merge`).
1. Change `#[unstable(...)]` to `#[stable(since = "CURRENT_RUSTC_VERSION")]`.
2. Remove `#![feature(...)]` from any test or doc-test for this API. If the feature is used in the
2. Change `#[unstable(...)]` to `#[stable(since = "CURRENT_RUSTC_VERSION")]`.
3. Remove `#![feature(...)]` from any test or doc-test for this API. If the feature is used in the
compiler or tools, remove it from there as well.
3. If applicable, change `#[rustc_const_unstable(...)]` to
4. If applicable, change `#[rustc_const_unstable(...)]` to
`#[rustc_const_stable(since = "CURRENT_RUSTC_VERSION")]`.
4. Open a PR against `rust-lang/rust`.
5. Open a PR against `rust-lang/rust`.
- Add the appropriate labels: `@rustbot modify labels: +T-libs-api`.
- Link to the tracking issue and say "Closes #XXXXX".