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
Copy file name to clipboardExpand all lines: src/appendix/glossary.md
+15-15
Original file line number
Diff line number
Diff line change
@@ -7,18 +7,18 @@ them better.
7
7
Term | Meaning
8
8
------------------------|--------
9
9
AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely.
10
-
binder | a "binder" is a place where a variable or type is declared; for example, the `<T>` is a binder for the generic type parameter `T` in `fn foo<T>(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./appendix-background.html#free-vs-bound)
11
-
bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession \|`a`\|` a * 2`. See [the background chapter for more](./appendix-background.html#free-vs-bound)
10
+
binder | a "binder" is a place where a variable or type is declared; for example, the `<T>` is a binder for the generic type parameter `T` in `fn foo<T>(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./appendix/background.html#free-vs-bound)
11
+
bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession \|`a`\|` a * 2`. See [the background chapter for more](./appendix/background.html#free-vs-bound)
12
12
codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use.
13
13
completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness").
14
-
control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./appendix-background.html#cfg)
14
+
control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./appendix/background.html#cfg)
15
15
cx | we tend to use "cx" as an abbrevation for context. See also `tcx`, `infcx`, etc.
16
16
DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](incremental-compilation.html))
17
-
data-flow analysis | 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](./appendix-background.html#dataflow)
17
+
data-flow analysis | 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](./appendix/background.html#dataflow)
18
18
DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`.
19
19
Double pointer | a pointer with additional metadata. See "fat pointer" for more.
20
20
Fat pointer | a two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers".
21
-
free variable | a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./appendix-background.html#free-vs-bound)
21
+
free variable | a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./appendix/background.html#free-vs-bound)
22
22
'gcx | the lifetime of the global arena ([see more](ty.html))
23
23
generics | the set of generic type parameters defined on a type or item
24
24
HIR | the High-level IR, created by lowering and desugaring the AST ([see more](hir.html))
@@ -32,36 +32,36 @@ IR | Intermediate Representation. A general term in compil
32
32
local crate | the crate currently being compiled.
33
33
LTO | Link-Time Optimizations. A set of optimizations offered by LLVM that occur just before the final binary is linked. These include optmizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto]
34
34
[LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that output LLVM IR and use LLVM to compile to all the platforms LLVM supports.
35
-
MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir.html))
35
+
MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir/index.html))
36
36
miri | an interpreter for MIR used for constant evaluation ([see more](./miri.html))
37
-
normalize | a general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](./traits-associated-types.html#normalize)
37
+
normalize | a general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](./traits/associated-types.html#normalize)
38
38
newtype | a "newtype" is a wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices.
39
-
NLL | [non-lexical lifetimes](./mir-regionck.html), an extension to Rust's borrowing system to make it be based on the control-flow graph.
39
+
NLL | [non-lexical lifetimes](./mir/regionck.html), an extension to Rust's borrowing system to make it be based on the control-flow graph.
40
40
node-id or NodeId | an index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`.
41
-
obligation | something that must be proven by the trait system ([see more](trait-resolution.html))
42
-
projection | a general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](./traits-goals-and-clauses.html#trait-ref)
43
-
promoted constants | constants extracted from a function and lifted to static scope; see [this section](./mir.html#promoted) for more details.
41
+
obligation | something that must be proven by the trait system ([see more](traits/resolution.html))
42
+
projection | a general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](./traits/goals-and-clauses.html#trait-ref)
43
+
promoted constants | constants extracted from a function and lifted to static scope; see [this section](./mir/index.html#promoted) for more details.
44
44
provider | the function that executes a query ([see more](query.html))
45
-
quantified | in math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./appendix-background.html#quantified)
45
+
quantified | in math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./appendix/background.html#quantified)
46
46
query | perhaps some sub-computation during compilation ([see more](query.html))
47
47
region | another term for "lifetime" often used in the literature and in the borrow checker.
48
48
sess | the compiler session, which stores global data used throughout compilation
49
49
side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node.
50
50
sigil | like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references.
51
-
skolemization | a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on skolemization and universes](./mir-regionck.html#skol) for more details.
51
+
skolemization | a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on skolemization and universes](./mir/regionck.html#skol) for more details.
52
52
soundness | soundness is a technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness").
53
53
span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more.
54
54
substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap<i32, u32>`)
55
55
tcx | the "typing context", main data structure of the compiler ([see more](ty.html))
56
56
'tcx | the lifetime of the currently active inference context ([see more](ty.html))
57
-
trait reference | the name of a trait along with a suitable set of input type/lifetimes ([see more](./traits-goals-and-clauses.html#trait-ref))
57
+
trait reference | the name of a trait along with a suitable set of input type/lifetimes ([see more](./traits/goals-and-clauses.html#trait-ref))
58
58
token | the smallest unit of parsing. Tokens are produced after lexing ([see more](the-parser.html)).
59
59
[TLS] | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS.
60
60
trans | the code to translate MIR into LLVM IR.
61
61
trait reference | a trait and values for its type parameters ([see more](ty.html)).
62
62
ty | the internal representation of a type ([see more](ty.html)).
63
63
UFCS | Universal Function Call Syntax. An unambiguous syntax for calling a method ([see more](type-checking.html)).
64
-
variance | variance determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec<T>` is a subtype `Vec<U>` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./appendix-background.html#variance) for a more general explanation. See the [variance chapter](./variance.html) for an explanation of how type checking handles variance.
64
+
variance | variance determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec<T>` is a subtype `Vec<U>` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./appendix/background.html#variance) for a more general explanation. See the [variance chapter](./variance.html) for an explanation of how type checking handles variance.
65
65
Wide pointer | a pointer with additional metadata. See "fat pointer" for more.
0 commit comments