fix links and names after compiler mv to compiler/
This commit is contained in:
mark
Tshepang Lekhonkhobe
parent
76efc9b91f
commit
9bb3872dc7
|
|
@ -6,30 +6,30 @@ compiler.
|
|||
|
||||
Item | Kind | Short description | Chapter | Declaration
|
||||
----------------|----------|-----------------------------|--------------------|-------------------
|
||||
`BodyId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.BodyId.html)
|
||||
`Compiler` | struct | Represents a compiler session and can be used to drive a compilation. | [The Rustc Driver and Interface] | [src/librustc_interface/interface.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html)
|
||||
`ast::Crate` | struct | A syntax-level representation of a parsed crate | [The parser] | [src/librustc_ast/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/struct.Crate.html)
|
||||
`rustc_hir::Crate` | struct | A more abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc_hir/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Crate.html)
|
||||
`DefId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html)
|
||||
`DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [src/librustc_errors/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html)
|
||||
`BodyId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [compiler/rustc_hir/src/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.BodyId.html)
|
||||
`Compiler` | struct | Represents a compiler session and can be used to drive a compilation. | [The Rustc Driver and Interface] | [compiler/rustc_interface/src/interface.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html)
|
||||
`ast::Crate` | struct | A syntax-level representation of a parsed crate | [The parser] | [compiler/rustc_ast/src/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/struct.Crate.html)
|
||||
`rustc_hir::Crate` | struct | A more abstract, compiler-friendly form of a crate's AST | [The Hir] | [compiler/rustc_hir/src/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Crate.html)
|
||||
`DefId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [compiler/rustc_hir/src/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html)
|
||||
`DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [compiler/rustc_errors/src/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_err.rs/struct.DiagnosticBuilder.html)
|
||||
`DocContext` | struct | A state container used by rustdoc when crawling through a crate to gather its documentation | [Rustdoc] | [src/librustdoc/core.rs](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs)
|
||||
`HirId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/hir_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html)
|
||||
`NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [src/librustc_ast/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html)
|
||||
`P` | struct | An owned immutable smart pointer. By contrast, `&T` is not owned, and `Box<T>` is not immutable. | None | [src/librustc_ast/ptr.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ptr/struct.P.html)
|
||||
`ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc_middle/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.ParamEnv.html)
|
||||
`ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/librustc_session/parse/parse.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.ParseSess.html)
|
||||
`Query` | struct | Represents the result of query to the `Compiler` interface and allows stealing, borrowing, and returning the results of compiler passes. | [The Rustc Driver and Interface] | [src/librustc_interface/queries.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html)
|
||||
`Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.Rib.html)
|
||||
`Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [src/librustc_middle/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html)
|
||||
`SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [src/librustc_span/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.SourceFile.html)
|
||||
`SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [src/librustc_span/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html)
|
||||
`Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/librustc_span/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html)
|
||||
`StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/librustc_parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html)
|
||||
`rustc_ast::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/librustc_ast/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html)
|
||||
`TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc_middle/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/trait_def/struct.TraitDef.html)
|
||||
`TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait<P1...Pn>`) | [Trait Solving: Goals and Clauses] | [src/librustc_middle/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TraitRef.html)
|
||||
`Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc_middle/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html)
|
||||
`TyCtxt<'tcx>` | struct | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [src/librustc_middle/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html)
|
||||
`HirId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [compiler/rustc_hir/src/hir_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html)
|
||||
`NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [compiler/rustc_ast/src/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html)
|
||||
`P` | struct | An owned immutable smart pointer. By contrast, `&T` is not owned, and `Box<T>` is not immutable. | None | [compiler/rustc_ast/src/ptr.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ptr/struct.P.html)
|
||||
`ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [compiler/rustc_middle/src/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.ParamEnv.html)
|
||||
`ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [compiler/rustc_session/src/parse/parse.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.P.rseSess.html)
|
||||
`Query` | struct | Represents the result of query to the `Compiler` interface and allows stealing, borrowing, and returning the results of compiler passes. | [The Rustc Driver and Interface] | [compiler/rustc_interface/src/queries.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html)
|
||||
`Rib` | struct | Represents a single scope of names | [Name resolution] | [compiler/rustc_resolve/src/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.Rib.html)
|
||||
`Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [compiler/rustc_middle/src/session/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html)
|
||||
`SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [compiler/rustc_span/src/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.SourceFile.html)
|
||||
`SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [compiler/rustc_span/src/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html)
|
||||
`Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [compiler/rustc_span/src/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html)
|
||||
`StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [compiler/rustc_parse/src/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_p.rse/lexer/struct.StringReader.html)
|
||||
`rustc_ast::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [compiler/rustc_ast/src/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html)
|
||||
`TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [compiler/rustc_middle/src/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/trait_def/struct.TraitDef.html)
|
||||
`TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait<P1...Pn>`) | [Trait Solving: Goals and Clauses] | [compiler/rustc_middle/src/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TraitRef.html)
|
||||
`Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [compiler/rustc_middle/src/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html)
|
||||
`TyCtxt<'tcx>` | struct | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [compiler/rustc_middle/src/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html)
|
||||
|
||||
[The HIR]: ../hir.html
|
||||
[Identifiers in the HIR]: ../hir.html#hir-id
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ cx <div id="cx"/> | We tend to use "cx" as an abbreviati
|
|||
DAG <div id="dag"/> | A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html))
|
||||
data-flow analysis <div id="data-flow"/> | A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow).
|
||||
DeBruijn Index <div id="debruijn"> | A technique for describing which binder a variable is bound by using only integers. It has the benefit that it is invariant under variable renaming. ([see more](./background.md#what-is-a-debruijn-index))
|
||||
DefId <div id="def-id"/> | An index identifying a definition (see `librustc_middle/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir).
|
||||
DefId <div id="def-id"/> | An index identifying a definition (see `rustc_middle/src/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir).
|
||||
Discriminant <div id="discriminant"/> | The underlying value associated with an enum variant or generator state to indicate it as "active" (but not to be confused with its ["variant index"](#variant-idx)). At runtime, the discriminant of the active variant is encoded in the [tag](#tag).
|
||||
Double pointer <div id="double-ptr"/> | A pointer with additional metadata. See "fat pointer" for more.
|
||||
drop glue <div id="drop-glue"/> | (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types.
|
||||
|
|
@ -31,7 +31,7 @@ HirId <div id="hir-id"/> | Identifies a particular node in the
|
|||
HIR Map <div id="hir-map"/> | The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers.
|
||||
ICE <div id="ice"/> | Short for internal compiler error, this is when the compiler crashes.
|
||||
ICH <div id="ich"/> | Short for incremental compilation hash, these are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled.
|
||||
infcx <div id="infcx"/> | The inference context (see `librustc_middle/infer`)
|
||||
infcx <div id="infcx"/> | The inference context (see `rustc_middle/src/infer`)
|
||||
inference variable <div id="inf-var"/> | When doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type.
|
||||
intern <div id="intern"/> | Interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info.
|
||||
intrinsic <div id="intrinsic"/> | Intrinsics are special functions that are implemented in the compiler itself but exposed (often unstably) to users. They do magical and dangerous things. (See [`std::intrinsics`](https://doc.rust-lang.org/std/intrinsics/index.html))
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Backend Agnostic Codegen
|
||||
|
||||
In the future, it would be nice to allow other codegen backends (e.g.
|
||||
[Cranelift]). To this end, `librustc_codegen_ssa` provides an
|
||||
[Cranelift]). To this end, `rustc_codegen_ssa` provides an
|
||||
abstract interface for all backends to implement.
|
||||
|
||||
[Cranelift]: https://github.com/bytecodealliance/wasmtime/tree/HEAD/cranelift
|
||||
|
|
|
|||
|
|
@ -63,8 +63,8 @@ before objects are passed on to the linker and some to happen during the
|
|||
linking.
|
||||
|
||||
This all happens towards the very end of compilation. The code for this can be
|
||||
found in [`librustc_codegen_ssa::back`][ssaback] and
|
||||
[`librustc_codegen_llvm::back`][llvmback]. Sadly, this piece of code is not
|
||||
found in [`rustc_codegen_ssa::back`][ssaback] and
|
||||
[`rustc_codegen_llvm::back`][llvmback]. Sadly, this piece of code is not
|
||||
really well-separated into LLVM-dependent code; the [`rustc_codegen_ssa`][ssa]
|
||||
contains a fair amount of code specific to the LLVM backend.
|
||||
|
||||
|
|
|
|||
|
|
@ -15,14 +15,14 @@ MIR to LLVM IR.
|
|||
|
||||
The code is split into modules which handle particular MIR primitives:
|
||||
|
||||
- [`librustc_codegen_ssa::mir::block`][mirblk] will deal with translating
|
||||
- [`rustc_codegen_ssa::mir::block`][mirblk] will deal with translating
|
||||
blocks and their terminators. The most complicated and also the most
|
||||
interesting thing this module does is generating code for function calls,
|
||||
including the necessary unwinding handling IR.
|
||||
- [`librustc_codegen_ssa::mir::statement`][mirst] translates MIR statements.
|
||||
- [`librustc_codegen_ssa::mir::operand`][mirop] translates MIR operands.
|
||||
- [`librustc_codegen_ssa::mir::place`][mirpl] translates MIR place references.
|
||||
- [`librustc_codegen_ssa::mir::rvalue`][mirrv] translates MIR r-values.
|
||||
- [`rustc_codegen_ssa::mir::statement`][mirst] translates MIR statements.
|
||||
- [`rustc_codegen_ssa::mir::operand`][mirop] translates MIR operands.
|
||||
- [`rustc_codegen_ssa::mir::place`][mirpl] translates MIR place references.
|
||||
- [`rustc_codegen_ssa::mir::rvalue`][mirrv] translates MIR r-values.
|
||||
|
||||
[mirblk]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/block/index.html
|
||||
[mirst]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/statement/index.html
|
||||
|
|
@ -49,7 +49,7 @@ and can be found in [`rustc_codegen_llvm::intrinsic`][llvmint].
|
|||
[llvmint]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/intrinsic/index.html
|
||||
|
||||
Everything else will use the [builder interface][builder]. This is the code that gets
|
||||
called in the [`librustc_codegen_ssa::mir::*`][ssamir] modules discussed above.
|
||||
called in the [`rustc_codegen_ssa::mir::*`][ssamir] modules discussed above.
|
||||
|
||||
[builder]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/builder/index.html
|
||||
[ssamir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/index.html
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ maintain a set storing what elements are present in its value (to make this
|
|||
efficient, we give each kind of element an index, the `RegionElementIndex`, and
|
||||
use sparse bitsets).
|
||||
|
||||
[ri]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/borrow_check/region_infer/
|
||||
[ri]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_mir/src/borrow_check/region_infer/
|
||||
|
||||
The kinds of region elements are as follows:
|
||||
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ described in more detail below):
|
|||
1. 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 `librustc_ast` that will affect plugins, the general policy
|
||||
Finally, for changes to `rustc_ast` that will affect plugins, the general policy
|
||||
is to batch these changes. That is discussed below in more detail.
|
||||
|
||||
### Tracking issue
|
||||
|
|
@ -120,7 +120,7 @@ future-compatibility warnings. These are a special category of lint warning.
|
|||
Adding a new future-compatibility warning can be done as follows.
|
||||
|
||||
```rust
|
||||
// 1. Define the lint in `src/librustc/lint/builtin.rs`:
|
||||
// 1. Define the lint in `compiler/rustc_middle/src/lint/builtin.rs`:
|
||||
declare_lint! {
|
||||
pub YOUR_ERROR_HERE,
|
||||
Warn,
|
||||
|
|
@ -137,7 +137,7 @@ impl LintPass for HardwiredLints {
|
|||
}
|
||||
}
|
||||
|
||||
// 3. Register the lint in `src/librustc_lint/lib.rs`:
|
||||
// 3. Register the lint in `compiler/rustc_lint/src/lib.rs`:
|
||||
store.register_future_incompatible(sess, vec![
|
||||
...,
|
||||
FutureIncompatibleInfo {
|
||||
|
|
@ -235,7 +235,7 @@ automatically generates the lower-case string; so searching for
|
|||
#### Remove the lint.
|
||||
|
||||
The first reference you will likely find is the lint definition [in
|
||||
`librustc/lint/builtin.rs` that resembles this][defsource]:
|
||||
`rustc_session/src/lint/builtin.rs` that resembles this][defsource]:
|
||||
|
||||
[defsource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc/lint/builtin.rs#L171-L175
|
||||
|
||||
|
|
@ -254,7 +254,7 @@ the file as [part of a `lint_array!`][lintarraysource]; remove it too,
|
|||
[lintarraysource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc/lint/builtin.rs#L252-L290
|
||||
|
||||
Next, you see see [a reference to `OVERLAPPING_INHERENT_IMPLS` in
|
||||
`librustc_lint/lib.rs`][futuresource]. This defining the lint as a "future
|
||||
`rustc_lint/src/lib.rs`][futuresource]. This defining the lint as a "future
|
||||
compatibility lint":
|
||||
|
||||
```rust
|
||||
|
|
@ -268,7 +268,7 @@ Remove this too.
|
|||
|
||||
#### Add the lint to the list of removed lists.
|
||||
|
||||
In `src/librustc_lint/lib.rs` there is a list of "renamed and removed lints".
|
||||
In `compiler/rustc_lint/src/lib.rs` there is a list of "renamed and removed lints".
|
||||
You can add this lint to the list:
|
||||
|
||||
```rust
|
||||
|
|
|
|||
|
|
@ -259,7 +259,7 @@ thread 'main' panicked at 'RUSTC_STAGE was not set: NotPresent', library/core/sr
|
|||
|
||||
If `./stageN/bin/rustc` gives an error about environment variables, that
|
||||
usually means something is quite wrong -- or you're trying to compile e.g.
|
||||
`librustc` or `std` or something that depends on environment variables. In
|
||||
`rustc` or `std` or something that depends on environment variables. In
|
||||
the unlikely case that you actually need to invoke rustc in such a situation,
|
||||
you can find the environment variable values by adding the following flag to
|
||||
your `x.py` command: `--on-fail=print-env`.
|
||||
|
|
|
|||
|
|
@ -183,7 +183,7 @@ This may *look* like it only builds `std`, but that is not the case.
|
|||
What this command does is the following:
|
||||
|
||||
- Build `std` using the stage0 compiler (using incremental)
|
||||
- Build `librustc` using the stage0 compiler (using incremental)
|
||||
- Build `rustc` using the stage0 compiler (using incremental)
|
||||
- This produces the stage1 compiler
|
||||
- Build `std` using the stage1 compiler (cannot use incremental)
|
||||
|
||||
|
|
@ -207,9 +207,9 @@ workflows"](./suggested.md) below.
|
|||
|
||||
Note that this whole command just gives you a subset of the full `rustc`
|
||||
build. The **full** `rustc` build (what you get if you say `./x.py build
|
||||
--stage 2 src/rustc`) has quite a few more steps:
|
||||
--stage 2 compiler/rustc`) has quite a few more steps:
|
||||
|
||||
- Build `librustc` and `rustc` with the stage1 compiler.
|
||||
- Build `rustc` with the stage1 compiler.
|
||||
- The resulting compiler here is called the "stage2" compiler.
|
||||
- Build `std` with stage2 compiler.
|
||||
- Build `librustdoc` and a bunch of other things with the stage2 compiler.
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ somewhat successfully, you can copy the specification into the
|
|||
compiler itself.
|
||||
|
||||
You will need to add a line to the big table inside of the
|
||||
`supported_targets` macro in the `librustc_target::spec` module. You
|
||||
`supported_targets` macro in the `rustc_target::spec` module. You
|
||||
will then add a corresponding file for your new target containing a
|
||||
`target` function.
|
||||
|
||||
|
|
@ -94,7 +94,7 @@ cross-compile `rustc`:
|
|||
```
|
||||
DESTDIR=/path/to/install/in \
|
||||
./x.py install -i --stage 1 --host aarch64-apple-darwin.json --target aarch64-apple-darwin \
|
||||
src/librustc library/std
|
||||
compiler/rustc library/std
|
||||
```
|
||||
|
||||
If your target specification is already available in the bootstrap
|
||||
|
|
|
|||
|
|
@ -115,7 +115,7 @@ Let's start with defining a term that we will be using quite a bit in the rest o
|
|||
*upvar*. An **upvar** is a variable that is local to the function where the closure is defined. So,
|
||||
in the above examples, **x** will be an upvar to the closure. They are also sometimes referred to as
|
||||
the *free variables* meaning they are not bound to the context of the closure.
|
||||
[`src/librustc_middle/ty/query/mod.rs`][upvars] defines a query called *upvars_mentioned*
|
||||
[`compiler/rustc_middle/src/ty/query/mod.rs`][upvars] defines a query called *upv.rs_mentioned*
|
||||
for this purpose.
|
||||
|
||||
[upvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/queries/struct.upvars_mentioned.html
|
||||
|
|
@ -135,8 +135,8 @@ appropriate trait: `Fn` trait for immutable borrow, `FnMut` for mutable borrow,
|
|||
and `FnOnce` for move semantics.
|
||||
|
||||
Most of the code related to the closure is in the
|
||||
[`src/librustc_typeck/check/upvar.rs`][upvar] file and the data structures are
|
||||
declared in the file [`src/librustc_middle/ty/mod.rs`][ty].
|
||||
[`compiler/rustc_typeck/src/check/upvar.rs`][upvar] file and the data structures are
|
||||
declared in the file [`compiler/rustc_middle/src/ty/mod.rs`][ty].
|
||||
|
||||
[upvar]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/upvar/index.html
|
||||
[ty]:https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/index.html
|
||||
|
|
@ -184,7 +184,7 @@ The callbacks are defined by implementing the [`Delegate`] trait. The
|
|||
records for each upvar which mode of borrow was required. The modes of borrow
|
||||
can be `ByValue` (moved) or `ByRef` (borrowed). For `ByRef` borrows, it can be
|
||||
`shared`, `shallow`, `unique` or `mut` as defined in the
|
||||
[`src/librustc_middle/mir/mod.rs`][mir_mod].
|
||||
[`compiler/rustc_middle/src/mir/mod.rs`][mir_mod].
|
||||
|
||||
[mir_mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html
|
||||
|
||||
|
|
@ -194,7 +194,7 @@ can be `ByValue` (moved) or `ByRef` (borrowed). For `ByRef` borrows, it can be
|
|||
|
||||
All of these callbacks have a common argument *cmt* which stands for Category,
|
||||
Mutability and Type and is defined in
|
||||
[`src/librustc_middle/middle/mem_categorization.rs`][cmt]. Borrowing from the code
|
||||
[`compiler/rustc_middle/src/middle/mem_categorization.rs`][cmt]. Borrowing from the code
|
||||
comments, "`cmt` is a complete categorization of a value indicating where it
|
||||
originated and how it is located, as well as the mutability of the memory in
|
||||
which the value is stored". Based on the callback (consume, borrow etc.), we
|
||||
|
|
|
|||
|
|
@ -53,17 +53,17 @@ look like this:
|
|||
```text
|
||||
stack backtrace:
|
||||
(~~~~ LINES REMOVED BY ME FOR BREVITY ~~~~)
|
||||
at /home/user/rust/src/librustc_typeck/check/cast.rs:110
|
||||
at /home/user/rust/compiler/rustc_typeck/src/check/cast.rs:110
|
||||
7: rustc_typeck::check::cast::CastCheck::check
|
||||
at /home/user/rust/src/librustc_typeck/check/cast.rs:572
|
||||
at /home/user/rust/src/librustc_typeck/check/cast.rs:460
|
||||
at /home/user/rust/src/librustc_typeck/check/cast.rs:370
|
||||
at /home/user/rust/compiler/rustc_typeck/src/check/cast.rs:572
|
||||
at /home/user/rust/compiler/rustc_typeck/src/check/cast.rs:460
|
||||
at /home/user/rust/compiler/rustc_typeck/src/check/cast.rs:370
|
||||
(~~~~ LINES REMOVED BY ME FOR BREVITY ~~~~)
|
||||
33: rustc_driver::driver::compile_input
|
||||
at /home/user/rust/src/librustc_driver/driver.rs:1010
|
||||
at /home/user/rust/src/librustc_driver/driver.rs:212
|
||||
at /home/user/rust/compiler/rustc_driver/src/driver.rs:1010
|
||||
at /home/user/rust/compiler/rustc_driver/src/driver.rs:212
|
||||
34: rustc_driver::run_compiler
|
||||
at /home/user/rust/src/librustc_driver/lib.rs:253
|
||||
at /home/user/rust/compiler/rustc_driver/src/lib.rs:253
|
||||
```
|
||||
|
||||
## Getting a backtrace for errors
|
||||
|
|
@ -123,23 +123,23 @@ note: rustc 1.24.0-dev running on x86_64-unknown-linux-gnu
|
|||
note: run with `RUST_BACKTRACE=1` for a backtrace
|
||||
|
||||
thread 'rustc' panicked at 'encountered error with `-Z treat_err_as_bug',
|
||||
/home/user/rust/src/librustc_errors/lib.rs:411:12
|
||||
/home/user/rust/compiler/rustc_errors/src/lib.rs:411:12
|
||||
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose
|
||||
backtrace.
|
||||
stack backtrace:
|
||||
(~~~ IRRELEVANT PART OF BACKTRACE REMOVED BY ME ~~~)
|
||||
7: rustc::traits::error_reporting::<impl rustc::infer::InferCtxt<'a, 'tcx>>
|
||||
::report_selection_error
|
||||
at /home/user/rust/src/librustc_middle/traits/error_reporting.rs:823
|
||||
at /home/user/rust/compiler/rustc_middle/src/traits/error_reporting.rs:823
|
||||
8: rustc::traits::error_reporting::<impl rustc::infer::InferCtxt<'a, 'tcx>>
|
||||
::report_fulfillment_errors
|
||||
at /home/user/rust/src/librustc_middle/traits/error_reporting.rs:160
|
||||
at /home/user/rust/src/librustc_middle/traits/error_reporting.rs:112
|
||||
at /home/user/rust/compiler/rustc_middle/src/traits/error_reporting.rs:160
|
||||
at /home/user/rust/compiler/rustc_middle/src/traits/error_reporting.rs:112
|
||||
9: rustc_typeck::check::FnCtxt::select_obligations_where_possible
|
||||
at /home/user/rust/src/librustc_typeck/check/mod.rs:2192
|
||||
at /home/user/rust/compiler/rustc_typeck/src/check/mod.rs:2192
|
||||
(~~~ IRRELEVANT PART OF BACKTRACE REMOVED BY ME ~~~)
|
||||
36: rustc_driver::run_compiler
|
||||
at /home/user/rust/src/librustc_driver/lib.rs:253
|
||||
at /home/user/rust/compiler/rustc_driver/src/lib.rs:253
|
||||
$ # Cool, now I have a backtrace for the error
|
||||
```
|
||||
|
||||
|
|
@ -174,11 +174,11 @@ look at the log output with a text editor.
|
|||
So to put it together.
|
||||
|
||||
```bash
|
||||
# This puts the output of all debug calls in `librustc_middle/traits` into
|
||||
# This puts the output of all debug calls in `rustc_middle/src/traits` into
|
||||
# standard error, which might fill your console backscroll.
|
||||
$ RUSTC_LOG=rustc_middle::traits rustc +local my-file.rs
|
||||
|
||||
# This puts the output of all debug calls in `librustc_middle/traits` in
|
||||
# This puts the output of all debug calls in `rustc_middle/src/traits` in
|
||||
# `traits-log`, so you can then see it with a text editor.
|
||||
$ RUSTC_LOG=rustc_middle::traits rustc +local my-file.rs 2>traits-log
|
||||
|
||||
|
|
@ -199,7 +199,7 @@ $ RUSTC_LOG=rustc_trans=info rustc +local my-file.rs
|
|||
# This will show the output of all `info!` calls made by rustdoc or any rustc library it calls.
|
||||
$ RUSTDOC_LOG=info rustdoc +local my-file.rs
|
||||
|
||||
# This will only show `debug!` calls made by rustdoc directly, not any `librustc*` crate.
|
||||
# This will only show `debug!` calls made by rustdoc directly, not any `rustc*` crate.
|
||||
$ RUSTDOC_LOG=rustdoc rustdoc +local my-file.rs
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ built in a special way because it can use unstable features.
|
|||
> NOTE: As of this writing, the crates all live in `src/`, but there is an MCP
|
||||
> to move them to a new `compiler/` directory.
|
||||
|
||||
The compiler crates all have names starting with `librustc_*`. These are a
|
||||
The compiler crates all have names starting with `rustc_*`. These are a
|
||||
collection of around 50 interdependent crates ranging in size from tiny to
|
||||
huge. There is also the `rustc` crate which is the actual binary (i.e. the
|
||||
`main` function); it doesn't actually do anything besides calling the
|
||||
|
|
|
|||
|
|
@ -71,11 +71,11 @@ Please read [RFC 1567] for details on how to format and write long error
|
|||
codes.
|
||||
|
||||
The descriptions are written in markdown, and all of them are linked in the
|
||||
[`librustc_error_codes`] crate.
|
||||
[`rustc_error_codes`] crate.
|
||||
|
||||
TODO: When should an error use an error code, and when shouldn't it?
|
||||
|
||||
[`librustc_error_codes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_error_codes/error_codes/index.html
|
||||
[`rustc_error_codes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_error_codes/error_codes/index.html
|
||||
[error index]: https://doc.rust-lang.org/error-index.html
|
||||
[RFC 1567]: https://github.com/rust-lang/rfcs/blob/master/text/1567-long-error-codes-explanation-normalization.md
|
||||
|
||||
|
|
@ -633,12 +633,12 @@ like normal but invokes the lint with `buffer_lint`.
|
|||
|
||||
#### Linting even earlier in the compiler
|
||||
|
||||
The parser (`librustc_ast`) is interesting in that it cannot have dependencies on
|
||||
any of the other `librustc*` crates. In particular, it cannot depend on
|
||||
`librustc_middle::lint` or `librustc_lint`, where all of the compiler linting
|
||||
The parser (`rustc_ast`) is interesting in that it cannot have dependencies on
|
||||
any of the other `rustc*` crates. In particular, it cannot depend on
|
||||
`rustc_middle::lint` or `rustc_lint`, where all of the compiler linting
|
||||
infrastructure is defined. That's troublesome!
|
||||
|
||||
To solve this, `librustc_ast` defines its own buffered lint type, which
|
||||
To solve this, `rustc_ast` defines its own buffered lint type, which
|
||||
`ParseSess::buffer_lint` uses. After macro expansion, these buffered lints are
|
||||
then dumped into the `Session::buffered_lints` used by the rest of the compiler.
|
||||
|
||||
|
|
@ -669,8 +669,8 @@ the structured JSON and see the "human" output (well, _sans_ colors)
|
|||
without having to compile everything twice.
|
||||
|
||||
The "human" readable and the json format emitter can be found under
|
||||
librustc_errors, both were moved from the `librustc_ast` crate to the
|
||||
[librustc_errors crate](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html).
|
||||
`rustc_errors`, both were moved from the `rustc_ast` crate to the
|
||||
[rustc_errors crate](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html).
|
||||
|
||||
The JSON emitter defines [its own `Diagnostic`
|
||||
struct](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/json/struct.Diagnostic.html)
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Here we see the highest error code in use is `E0591`, so we _probably_ want
|
|||
`E0592`. To be sure, run `rg E0592` and check, you should see no references.
|
||||
|
||||
Next, open `src/{crate}/diagnostics.rs` within the crate where you wish to issue
|
||||
the error (e.g., `src/librustc_typeck/diagnostics.rs`). Ideally, you will add
|
||||
the error (e.g., `compiler/rustc_typeck/src/diagnostics.rs`). Ideally, you will add
|
||||
the code (in its proper numerical order) into the `register_long_diagnostics!`
|
||||
macro, sort of like this:
|
||||
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@ understanding the code. However, with the current type-erased lint store
|
|||
approach, it is beneficial to do so for performance reasons.
|
||||
|
||||
New lints being added likely want to join one of the existing declarations like
|
||||
`late_lint_mod_passes` in `librustc_lint/lib.rs`, which would then
|
||||
`late_lint_mod_passes` in `rustc_lint/src/lib.rs`, which would then
|
||||
auto-propagate into the other.
|
||||
|
||||
[`LintStore::register_lint`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/struct.LintStore.html#method.register_lints
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ a new unstable feature:
|
|||
2. Pick a name for the feature gate (for RFCs, use the name
|
||||
in the RFC).
|
||||
|
||||
3. Add a feature gate declaration to `librustc_feature/active.rs`
|
||||
3. Add a feature gate declaration to `rustc_feature/src/active.rs`
|
||||
in the active `declare_features` block:
|
||||
|
||||
```rust,ignore
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ of such structures include but are not limited to
|
|||
* Converted to a virtual `existential type` declaration
|
||||
|
||||
Lowering needs to uphold several invariants in order to not trigger the
|
||||
sanity checks in `src/librustc_middle/hir/map/hir_id_validator.rs`:
|
||||
sanity checks in `compiler/rustc_middle/src/hir/map/hir_id_validator.rs`:
|
||||
|
||||
1. A `HirId` must be used if created. So if you use the `lower_node_id`,
|
||||
you *must* use the resulting `NodeId` or `HirId` (either is fine, since
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Macro expansion
|
||||
|
||||
> `librustc_ast`, `librustc_expand`, and `librustc_builtin_macros` are all undergoing
|
||||
> `rustc_ast`, `rustc_expand`, and `rustc_builtin_macros` are all undergoing
|
||||
> refactoring, so some of the links in this chapter may be broken.
|
||||
|
||||
Rust has a very powerful macro system. In the previous chapter, we saw how the
|
||||
|
|
@ -222,7 +222,7 @@ a macro author may want to introduce a new name to the context where the macro
|
|||
was called. Alternately, the macro author may be defining a variable for use
|
||||
only within the macro (i.e. it should not be visible outside the macro).
|
||||
|
||||
[code_dir]: https://github.com/rust-lang/rust/tree/master/src/librustc_expand/mbe
|
||||
[code_dir]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_expand/src/mbe
|
||||
[code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser
|
||||
[code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_rules
|
||||
[code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/fn.parse_tt.html
|
||||
|
|
@ -232,7 +232,7 @@ The context is attached to AST nodes. All AST nodes generated by macros have
|
|||
context attached. Additionally, there may be other nodes that have context
|
||||
attached, such as some desugared syntax (non-macro-expanded nodes are
|
||||
considered to just have the "root" context, as described below).
|
||||
Throughout the compiler, we use [`librustc_span::Span`s][span] to refer to code locations.
|
||||
Throughout the compiler, we use [`rustc_span::Span`s][span] to refer to code locations.
|
||||
This struct also has hygiene information attached to it, as we will see later.
|
||||
|
||||
[span]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html
|
||||
|
|
@ -442,7 +442,7 @@ are expanded, we may invoke the MBE parser to parse and expand a macro. The
|
|||
MBE parser, in turn, may call the normal Rust parser when it needs to bind a
|
||||
metavariable (e.g. `$my_expr`) while parsing the contents of a macro
|
||||
invocation. The code for macro expansion is in
|
||||
[`src/librustc_expand/mbe/`][code_dir].
|
||||
[`compiler/rustc_expand/src/mbe/`][code_dir].
|
||||
|
||||
### Example
|
||||
|
||||
|
|
@ -495,7 +495,7 @@ invocations. Interestingly, both are done by the macro parser.
|
|||
Basically, the MBE parser is like an NFA-based regex parser. It uses an
|
||||
algorithm similar in spirit to the [Earley parsing
|
||||
algorithm](https://en.wikipedia.org/wiki/Earley_parser). The macro parser is
|
||||
defined in [`src/librustc_expand/mbe/macro_parser.rs`][code_mp].
|
||||
defined in [`compiler/rustc_expand/src/mbe/macro_parser.rs`][code_mp].
|
||||
|
||||
The interface of the macro parser is as follows (this is slightly simplified):
|
||||
|
||||
|
|
@ -542,7 +542,7 @@ normal Rust parser.
|
|||
As mentioned above, both definitions and invocations of macros are parsed using
|
||||
the macro parser. This is extremely non-intuitive and self-referential. The code
|
||||
to parse macro _definitions_ is in
|
||||
[`src/librustc_expand/mbe/macro_rules.rs`][code_mr]. It defines the pattern for
|
||||
[`compiler/rustc_expand/src/mbe/macro_rules.rs`][code_mr]. It defines the pattern for
|
||||
matching for a macro definition as `$( $lhs:tt => $rhs:tt );+`. In other words,
|
||||
a `macro_rules` definition should have in its body at least one occurrence of a
|
||||
token tree followed by `=>` followed by another token tree. When the compiler
|
||||
|
|
@ -571,7 +571,7 @@ the parse is ambiguous, while if there are no matches at all, there is a syntax
|
|||
error.
|
||||
|
||||
For more information about the macro parser's implementation, see the comments
|
||||
in [`src/librustc_expand/mbe/macro_parser.rs`][code_mp].
|
||||
in [`compiler/rustc_expand/src/mbe/macro_parser.rs`][code_mp].
|
||||
|
||||
### `macro`s and Macros 2.0
|
||||
|
||||
|
|
|
|||
|
|
@ -15,8 +15,8 @@ graphs and desugaring), you may enjoy the
|
|||
|
||||
## Introduction to MIR
|
||||
|
||||
MIR is defined in the [`src/librustc_middle/mir/`][mir] module, but much of the code
|
||||
that manipulates it is found in [`src/librustc_mir`][mirmanip].
|
||||
MIR is defined in the [`compiler/rustc_middle/src/mir/`][mir] module, but much of the code
|
||||
that manipulates it is found in [`compiler/rustc_mir`][mirmanip].
|
||||
|
||||
[RFC 1211]: https://rust-lang.github.io/rfcs/1211-mir.html
|
||||
|
||||
|
|
@ -212,7 +212,7 @@ over the overflow checks.)
|
|||
|
||||
## MIR data types
|
||||
|
||||
The MIR data types are defined in the [`src/librustc_middle/mir/`][mir]
|
||||
The MIR data types are defined in the [`compiler/rustc_middle/src/mir/`][mir]
|
||||
module. Each of the key concepts mentioned in the previous section
|
||||
maps in a fairly straightforward way to a Rust type.
|
||||
|
||||
|
|
@ -253,7 +253,6 @@ but [you can read about those below](#promoted)).
|
|||
*to be written*
|
||||
|
||||
|
||||
[mir]: https://github.com/rust-lang/rust/tree/master/src/librustc_middle/mir
|
||||
[mirmanip]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir
|
||||
[mir]: https://github.com/rust-lang/rust/tree/master/src/librustc_middle/mir
|
||||
[mir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html
|
||||
[mirmanip]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/index.html
|
||||
[newtype'd]: ../appendix/glossary.html#newtype
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@ Miri, but just use the cached result.
|
|||
## Datastructures
|
||||
|
||||
Miri's outside-facing datastructures can be found in
|
||||
[librustc_middle/mir/interpret](https://github.com/rust-lang/rust/blob/master/src/librustc_middle/mir/interpret).
|
||||
[rustc_middle/src/mir/interpret](https://github.com/rust-lang/rust/blob/master/compiler/rustc_middle/src/mir/interpret).
|
||||
This is mainly the error enum and the [`ConstValue`] and [`Scalar`] types. A
|
||||
`ConstValue` can be either `Scalar` (a single `Scalar`, i.e., integer or thin
|
||||
pointer), `Slice` (to represent byte slices and strings, as needed for pattern
|
||||
|
|
@ -202,7 +202,7 @@ division on pointer values.
|
|||
|
||||
Although the main entry point to constant evaluation is the `tcx.const_eval_*`
|
||||
functions, there are additional functions in
|
||||
[librustc_mir/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/index.html)
|
||||
[rustc_mir/src/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/index.html)
|
||||
that allow accessing the fields of a `ConstValue` (`ByRef` or otherwise). You should
|
||||
never have to access an `Allocation` directly except for translating it to the
|
||||
compilation target (at the moment just LLVM).
|
||||
|
|
@ -213,7 +213,7 @@ function with no arguments, except that constants do not allow local (named)
|
|||
variables at the time of writing this guide.
|
||||
|
||||
A stack frame is defined by the `Frame` type in
|
||||
[librustc_mir/interpret/eval_context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/interpret/eval_context.rs)
|
||||
[rustc_mir/src/interpret/eval_context.rs](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir/src/interpret/eval_context.rs)
|
||||
and contains all the local
|
||||
variables memory (`None` at the start of evaluation). Each frame refers to the
|
||||
evaluation of either the root constant or subsequent calls to `const fn`. The
|
||||
|
|
@ -225,7 +225,7 @@ The frames are just a `Vec<Frame>`, there's no way to actually refer to a
|
|||
memory that can be referred to are `Allocation`s.
|
||||
|
||||
Miri now calls the `step` method (in
|
||||
[librustc_mir/interpret/step.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/interpret/step.rs)
|
||||
[rustc_mir/src/interpret/step.rs](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir/src/interpret/step.rs)
|
||||
) until it either returns an error or has no further statements to execute. Each
|
||||
statement will now initialize or modify the locals or the virtual memory
|
||||
referred to by a local. This might require evaluating other constants or
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ A successful run of the second phase ([`Resolver::resolve_crate`]) creates kind
|
|||
of an index the rest of the compilation may use to ask about the present names
|
||||
(through the `hir::lowering::Resolver` interface).
|
||||
|
||||
The name resolution lives in the `librustc_resolve` crate, with the meat in
|
||||
The name resolution lives in the `rustc_resolve` crate, with the meat in
|
||||
`lib.rs` and some helpers or symbol-type specific logic in the other modules.
|
||||
|
||||
[`Resolver::resolve_crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/struct.Resolver.html#method.resolve_crate
|
||||
|
|
|
|||
|
|
@ -22,31 +22,31 @@ we'll talk about that later.
|
|||
enable nightly features (`-Z` flags), perform `check`-only builds, or emit
|
||||
LLVM-IR rather than executable machine code. The `rustc` executable call may
|
||||
be indirect through the use of `cargo`.
|
||||
- Command line argument parsing occurs in the [`librustc_driver`]. This crate
|
||||
- Command line argument parsing occurs in the [`rustc_driver`]. This crate
|
||||
defines the compile configuration that is requested by the user and passes it
|
||||
to the rest of the compilation process as a [`rustc_interface::Config`].
|
||||
- The raw Rust source text is analyzed by a low-level lexer located in
|
||||
[`librustc_lexer`]. At this stage, the source text is turned into a stream of
|
||||
[`rustc_lexer`]. At this stage, the source text is turned into a stream of
|
||||
atomic source code units known as _tokens_. The lexer supports the
|
||||
Unicode character encoding.
|
||||
- The token stream passes through a higher-level lexer located in
|
||||
[`librustc_parse`] to prepare for the next stage of the compile process. The
|
||||
[`rustc_parse`] to prepare for the next stage of the compile process. The
|
||||
[`StringReader`] struct is used at this stage to perform a set of validations
|
||||
and turn strings into interned symbols (_interning_ is discussed later).
|
||||
- The lexer has a small interface and doesn't depend directly on the
|
||||
diagnostic infrastructure in `rustc`. Instead it provides diagnostics as plain
|
||||
data which are emitted in `librustc_parse::lexer::mod` as real diagnostics.
|
||||
data which are emitted in `rustc_parse::lexer::mod` as real diagnostics.
|
||||
- The lexer preserves full fidelity information for both IDEs and proc macros.
|
||||
- The parser [translates the token stream from the lexer into an Abstract Syntax
|
||||
Tree (AST)][parser]. It uses a recursive descent (top-down) approach to syntax
|
||||
analysis. The crate entry points for the parser are the `Parser::parse_crate_mod()` and
|
||||
`Parser::parse_mod()` methods found in `librustc_parse::parser::item`. The external
|
||||
module parsing entry point is `librustc_expand::module::parse_external_mod`. And
|
||||
`Parser::parse_mod()` methods found in `rustc_parse::parser::item`. The external
|
||||
module parsing entry point is `rustc_expand::module::parse_external_mod`. And
|
||||
the macro parser entry point is [`Parser::parse_nonterminal()`][parse_nonterminal].
|
||||
- Parsing is performed with a set of `Parser` utility methods including `fn bump`,
|
||||
`fn check`, `fn eat`, `fn expect`, `fn look_ahead`.
|
||||
- Parsing is organized by the semantic construct that is being parsed. Separate
|
||||
`parse_*` methods can be found in `librustc_parse` `parser` directory. The source
|
||||
`parse_*` methods can be found in `rustc_parse` `parser` directory. The source
|
||||
file name follows the construct name. For example, the following files are found
|
||||
in the parser:
|
||||
- `expr.rs`
|
||||
|
|
@ -97,12 +97,12 @@ we'll talk about that later.
|
|||
- The different libraries/binaries are linked together to produce the final
|
||||
binary.
|
||||
|
||||
[`librustc_lexer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html
|
||||
[`librustc_driver`]: https://rustc-dev-guide.rust-lang.org/rustc-driver.html
|
||||
[`rustc_lexer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html
|
||||
[`rustc_driver`]: https://rustc-dev-guide.rust-lang.org/rustc-driver.html
|
||||
[`rustc_interface::Config`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Config.html
|
||||
[lex]: https://rustc-dev-guide.rust-lang.org/the-parser.html
|
||||
[`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html
|
||||
[`librustc_parse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html
|
||||
[`rustc_parse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html
|
||||
[parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html
|
||||
[hir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html
|
||||
[type inference]: https://rustc-dev-guide.rust-lang.org/type-inference.html
|
||||
|
|
@ -340,16 +340,16 @@ For more details on bootstrapping, see
|
|||
- Main entry point: [`rustc_session::config::build_session_options`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/config/fn.build_session_options.html)
|
||||
- Lexical Analysis: Lex the user program to a stream of tokens
|
||||
- Guide: [Lexing and Parsing](https://rustc-dev-guide.rust-lang.org/the-parser.html)
|
||||
- Lexer definition: [`librustc_lexer`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html)
|
||||
- Lexer definition: [`rustc_lexer`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html)
|
||||
- Main entry point: [`rustc_lexer::first_token`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/fn.first_token.html)
|
||||
- Parsing: Parse the stream of tokens to an Abstract Syntax Tree (AST)
|
||||
- Guide: [Lexing and Parsing](https://rustc-dev-guide.rust-lang.org/the-parser.html)
|
||||
- Parser definition: [`librustc_parse`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html)
|
||||
- Parser definition: [`rustc_parse`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html)
|
||||
- Main entry points:
|
||||
- [Entry point for first file in crate](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/passes/fn.parse.html)
|
||||
- [Entry point for outline module parsing](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/module/fn.parse_external_mod.html)
|
||||
- [Entry point for macro fragments][parse_nonterminal]
|
||||
- AST definition: [`librustc_ast`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html)
|
||||
- AST definition: [`rustc_ast`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html)
|
||||
- Expansion: **TODO**
|
||||
- Name Resolution: **TODO**
|
||||
- Feature gating: **TODO**
|
||||
|
|
@ -371,8 +371,8 @@ For more details on bootstrapping, see
|
|||
- These two functions can't be decoupled.
|
||||
- The Mid Level Intermediate Representation (MIR)
|
||||
- Guide: [The MIR (Mid level IR)](https://rustc-dev-guide.rust-lang.org/mir/index.html)
|
||||
- Definition: [`librustc_middle/mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html)
|
||||
- Definition of source that manipulates the MIR: [`librustc_mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/index.html)
|
||||
- Definition: [`rustc_middle/src/mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html)
|
||||
- Definition of source that manipulates the MIR: [`rustc_mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/index.html)
|
||||
- The Borrow Checker
|
||||
- Guide: [MIR Borrow Check](https://rustc-dev-guide.rust-lang.org/borrow_check.html)
|
||||
- Definition: [`rustc_mir/borrow_check`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html)
|
||||
|
|
|
|||
|
|
@ -24,8 +24,8 @@ unsafe { panic_impl(&pi) }
|
|||
|
||||
Actually resolving this goes through several layers of indirection:
|
||||
|
||||
1. In `src/librustc_middle/middle/weak_lang_items.rs`, `panic_impl` is declared as 'weak lang item',
|
||||
with the symbol `rust_begin_unwind`. This is used in `librustc_typeck/collect.rs`
|
||||
1. In `compiler/rustc_middle/src/middle/weak_lang_items.rs`, `panic_impl` is declared as 'weak lang item',
|
||||
with the symbol `rust_begin_unwind`. This is used in `rustc_typeck/src/collect.rs`
|
||||
to set the actual symbol name to `rust_begin_unwind`.
|
||||
|
||||
Note that `panic_impl` is declared in an `extern "Rust"` block,
|
||||
|
|
@ -44,7 +44,7 @@ pub fn begin_panic_handler(info: &PanicInfo<'_>) -> ! {
|
|||
}
|
||||
```
|
||||
|
||||
The special `panic_handler` attribute is resolved via `src/librustc_middle/middle/lang_items`.
|
||||
The special `panic_handler` attribute is resolved via `compiler/rustc_middle/src/middle/lang_items`.
|
||||
The `extract` function converts the `panic_handler` attribute to a `panic_impl` lang item.
|
||||
|
||||
Now, we have a matching `panic_handler` lang item in the `std`. This function goes
|
||||
|
|
|
|||
|
|
@ -175,7 +175,7 @@ fn try_mark_green(tcx, current_node) -> bool {
|
|||
}
|
||||
|
||||
// Note: The actual implementation can be found in
|
||||
// src/librustc_middle/dep_graph/graph.rs
|
||||
// compiler/rustc_middle/src/dep_graph/graph.rs
|
||||
```
|
||||
|
||||
By using red-green marking we can avoid the devastating cumulative effect of
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ Try-mark-green works as follows:
|
|||
### The query DAG
|
||||
|
||||
The query DAG code is stored in
|
||||
[`src/librustc_middle/dep_graph`][dep_graph]. Construction of the DAG is done
|
||||
[`compiler/rustc_middle/src/dep_graph`][dep_graph]. Construction of the DAG is done
|
||||
by instrumenting the query execution.
|
||||
|
||||
One key point is that the query DAG also tracks ordering; that is, for
|
||||
|
|
@ -113,7 +113,7 @@ of order, however, it might visit `subquery2` before `subquery1`, and hence
|
|||
execute it.
|
||||
This can lead to ICEs and other problems in the compiler.
|
||||
|
||||
[dep_graph]: https://github.com/rust-lang/rust/tree/master/src/librustc_middle/dep_graph
|
||||
[dep_graph]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/dep_graph/index.html
|
||||
|
||||
## Improvements to the basic algorithm
|
||||
|
||||
|
|
|
|||
|
|
@ -259,7 +259,7 @@ We give some background about the query model of the Rust compiler.
|
|||
In the query model, many queries have a key that consists of a Def ID. The Rust
|
||||
compiler uses Def IDs to distinguish definitions in the input Rust program.
|
||||
|
||||
From the compiler source code (`src/librustc_middle/hir/def_id.rs`):
|
||||
From the compiler source code (`compiler/rustc_middle/src/hir/def_id.rs`):
|
||||
|
||||
```
|
||||
/// A DefId identifies a particular *definition*, by combining a crate
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ for external crates, though the plan is that we may eventually have
|
|||
one per crate.
|
||||
|
||||
These `Providers` structs are ultimately created and populated by
|
||||
`librustc_driver`, but it does this by distributing the work
|
||||
`rustc_driver`, but it does this by distributing the work
|
||||
throughout the other `rustc_*` crates. This is done by invoking
|
||||
various [`provide`][provide_fn] functions. These functions tend to look
|
||||
something like this:
|
||||
|
|
@ -159,7 +159,7 @@ they define both a [`provide`][ext_provide] and a
|
|||
[`provide_extern`][ext_provide_extern] function that `rustc_driver`
|
||||
can invoke.
|
||||
|
||||
[rustc_metadata]: https://github.com/rust-lang/rust/tree/master/src/librustc_metadata
|
||||
[rustc_metadata]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/index.html
|
||||
[ext_provide]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/attributes/fn.provide.html
|
||||
[ext_provide_extern]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/attributes/fn.provide_extern.html
|
||||
|
||||
|
|
@ -173,7 +173,7 @@ Well, defining a query takes place in two steps:
|
|||
|
||||
To specify the query name and arguments, you simply add an entry to
|
||||
the big macro invocation in
|
||||
[`src/librustc_middle/query/mod.rs`][query-mod], which looks something like:
|
||||
[`compiler/rustc_middle/src/query/mod.rs`][query-mod], which looks something like:
|
||||
|
||||
[query-mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/query/index.html
|
||||
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ should appear in the documentation.
|
|||
### Updating the feature-gate listing
|
||||
|
||||
There is a central listing of feature-gates in
|
||||
[`src/librustc_feature`]. Search for the `declare_features!`
|
||||
[`compiler/rustc_feature`]. Search for the `declare_features!`
|
||||
macro. There should be an entry for the feature you are aiming
|
||||
to stabilize, something like (this example is taken from
|
||||
[rust-lang/rust#32409]:
|
||||
|
|
@ -140,7 +140,7 @@ Most importantly, remove the code which flags an error if the
|
|||
feature-gate is not present (since the feature is now considered
|
||||
stable). If the feature can be detected because it employs some
|
||||
new syntax, then a common place for that code to be is in the
|
||||
same `src/librustc_ast_passes/feature_gate.rs`.
|
||||
same `compiler/rustc_ast_passes/src/feature_gate.rs`.
|
||||
For example, you might see code like this:
|
||||
|
||||
```rust,ignore
|
||||
|
|
@ -175,7 +175,7 @@ if something { /* XXX */ }
|
|||
```
|
||||
|
||||
[rust-lang/rust#32409]: https://github.com/rust-lang/rust/issues/32409
|
||||
[`src/librustc_feature`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_feature/index.html
|
||||
[`compiler/rustc_feature`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_feature/index.html
|
||||
[The Reference]: https://github.com/rust-lang/reference
|
||||
[The Book]: https://github.com/rust-lang/book
|
||||
[Rust by Example]: https://github.com/rust-lang/rust-by-example
|
||||
|
|
|
|||
|
|
@ -32,14 +32,14 @@ How does any sort of `main` function invoke these tests if they're not visible?
|
|||
What exactly is `rustc --test` doing?
|
||||
|
||||
`#[test]` is implemented as a syntactic transformation inside the compiler's
|
||||
[`librustc_ast` crate][librustc_ast]. Essentially, it's a fancy macro, that
|
||||
[`rustc_ast` crate][rustc_ast]. Essentially, it's a fancy macro, that
|
||||
rewrites the crate in 3 steps:
|
||||
|
||||
#### Step 1: Re-Exporting
|
||||
|
||||
As mentioned earlier, tests can exist inside private modules, so we need a
|
||||
way of exposing them to the main function, without breaking any existing
|
||||
code. To that end, `librustc_ast` will create local modules called
|
||||
code. To that end, `rustc_ast` will create local modules called
|
||||
`__test_reexports` that recursively reexport tests. This expansion translates
|
||||
the above example into:
|
||||
|
||||
|
|
@ -79,7 +79,7 @@ hygiene.
|
|||
|
||||
#### Step 2: Harness Generation
|
||||
Now that our tests are accessible from the root of our crate, we need to do
|
||||
something with them. `librustc_ast` generates a module like so:
|
||||
something with them. `rustc_ast` generates a module like so:
|
||||
|
||||
```rust,ignore
|
||||
#[main]
|
||||
|
|
@ -116,7 +116,7 @@ fn foo() {
|
|||
This means our tests are more than just simple functions, they have
|
||||
configuration information as well. `test` encodes this configuration data
|
||||
into a struct called [`TestDesc`][TestDesc]. For each test function in a
|
||||
crate, `librustc_ast` will parse its attributes and generate a `TestDesc`
|
||||
crate, `rustc_ast` will parse its attributes and generate a `TestDesc`
|
||||
instance. It then combines the `TestDesc` and test function into the
|
||||
predictably named `TestDescAndFn` struct, that `test_main_static` operates
|
||||
on. For a given test, the generated `TestDescAndFn` instance looks like so:
|
||||
|
|
@ -150,4 +150,4 @@ $ rustc my_mod.rs -Z unpretty=hir
|
|||
[Symbol]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Symbol.html
|
||||
[Ident]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Ident.html
|
||||
[eRFC]: https://github.com/rust-lang/rfcs/blob/master/text/2318-custom-test-frameworks.md
|
||||
[librustc_ast]: https://github.com/rust-lang/rust/tree/master/src/librustc_ast
|
||||
[rustc_ast]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_ast
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ conveniently than strings. This happens in two stages: Lexing and Parsing.
|
|||
|
||||
Lexing takes strings and turns them into streams of [tokens]. For example,
|
||||
`a.b + c` would be turned into the tokens `a`, `.`, `b`, `+`, and `c`.
|
||||
The lexer lives in [`librustc_lexer`][lexer].
|
||||
The lexer lives in [`rustc_lexer`][lexer].
|
||||
|
||||
[tokens]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/token/index.html
|
||||
[lexer]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html
|
||||
|
|
@ -19,12 +19,12 @@ form which is easier for the compiler to work with, usually called an [*Abstract
|
|||
Syntax Tree*][ast] (AST). An AST mirrors the structure of a Rust program in memory,
|
||||
using a `Span` to link a particular AST node back to its source text.
|
||||
|
||||
The AST is defined in [`librustc_ast`][librustc_ast], along with some definitions for
|
||||
The AST is defined in [`rustc_ast`][rustc_ast], along with some definitions for
|
||||
tokens and token streams, data structures/traits for mutating ASTs, and shared
|
||||
definitions for other AST-related parts of the compiler (like the lexer and
|
||||
macro-expansion).
|
||||
|
||||
The parser is defined in [`librustc_parse`][librustc_parse], along with a
|
||||
The parser is defined in [`rustc_parse`][rustc_parse], along with a
|
||||
high-level interface to the lexer and some validation routines that run after
|
||||
macro expansion. In particular, the [`rustc_parse::parser`][parser] contains
|
||||
the parser implementation.
|
||||
|
|
@ -52,16 +52,16 @@ Code for lexical analysis is split between two crates:
|
|||
constituting tokens. Although it is popular to implement lexers as generated
|
||||
finite state machines, the lexer in `rustc_lexer` is hand-written.
|
||||
|
||||
- [`StringReader`] from [`librustc_ast`][librustc_ast] integrates `rustc_lexer` with `rustc`
|
||||
- [`StringReader`] from [`rustc_ast`][rustc_ast] integrates `rustc_lexer` with `rustc`
|
||||
specific data structures. Specifically, it adds `Span` information to tokens
|
||||
returned by `rustc_lexer` and interns identifiers.
|
||||
|
||||
[librustc_ast]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/index.html
|
||||
[rustc_ast]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/index.html
|
||||
[rustc_errors]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html
|
||||
[ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree
|
||||
[`SourceMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html
|
||||
[ast module]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html
|
||||
[librustc_parse]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html
|
||||
[rustc_parse]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html
|
||||
[parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/index.html
|
||||
[`Parser`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/parse/parser/struct.Parser.html
|
||||
[`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html
|
||||
|
|
|
|||
|
|
@ -38,4 +38,4 @@ implementing them in rustc. We map our struct, trait, and impl declarations
|
|||
into logical inference rules in the [lowering module in rustc](./lowering-module.md).
|
||||
|
||||
[chalk]: https://github.com/rust-lang/chalk
|
||||
[librustc_traits]: https://github.com/rust-lang/rust/tree/master/src/librustc_traits
|
||||
[rustc_traits]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_traits
|
||||
|
|
|
|||
|
|
@ -38,11 +38,11 @@ paper
|
|||
gives the details.
|
||||
|
||||
In terms of code, these types are defined in
|
||||
[`librustc_middle/traits/mod.rs`][traits_mod] in rustc, and in
|
||||
[`rustc_middle/src/traits/mod.rs`][traits_mod] in rustc, and in
|
||||
[`chalk-ir/src/lib.rs`][chalk_ir] in chalk.
|
||||
|
||||
[pphhf]: https://rust-lang.github.io/chalk/book/bibliography.html#pphhf
|
||||
[traits_mod]: https://github.com/rust-lang/rust/blob/master/src/librustc_middle/traits/mod.rs
|
||||
[traits_mod]: https://github.com/rust-lang/rust/blob/master/compiler/rustc_middle/src/traits/mod.rs
|
||||
[chalk_ir]: https://github.com/rust-lang/chalk/blob/master/chalk-ir/src/lib.rs
|
||||
|
||||
<a name="domain-goals"></a>
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@ things. We only want to do something when we reach a type. That means there may
|
|||
implementations. Such implementations of `TypeFoldable` tend to be pretty tedious to write by hand.
|
||||
For this reason, there is a `derive` macro that allows you to `#![derive(TypeFoldable)]`. It is
|
||||
defined
|
||||
[here](https://github.com/rust-lang/rust/blob/master/src/librustc_macros/src/type_foldable.rs).
|
||||
[here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_macros/src/type_foldable.rs).
|
||||
|
||||
**`subst`** In the case of substitutions the [actual
|
||||
folder](https://github.com/rust-lang/rust/blob/75ff3110ac6d8a0259023b83fd20d7ab295f8dd6/src/librustc_middle/ty/subst.rs#L440-L451)
|
||||
|
|
|
|||
|
|
@ -4,9 +4,9 @@ The [`rustc_typeck`][typeck] crate contains the source for "type collection"
|
|||
and "type checking", as well as a few other bits of related functionality. (It
|
||||
draws heavily on the [type inference] and [trait solving].)
|
||||
|
||||
[typeck]: https://github.com/rust-lang/rust/tree/master/src/librustc_typeck
|
||||
[type inference]: type-inference.html
|
||||
[trait solving]: traits/resolution.html
|
||||
[typeck]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/index.html
|
||||
[type inference]: ./type-inference.md
|
||||
[trait solving]: ./traits/resolution.md
|
||||
|
||||
## Type collection
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ type *checking*).
|
|||
|
||||
For more details, see the [`collect`][collect] module.
|
||||
|
||||
[queries]: query.html
|
||||
[queries]: ./query.md
|
||||
[collect]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/collect/
|
||||
|
||||
**TODO**: actually talk about type checking...
|
||||
|
|
|
|||
Loading…
Reference in New Issue