Use new-style mdBook internal links in glossary
This commit is contained in:
parent
5b6f343c87
commit
17c77b296e
|
|
@ -4,20 +4,20 @@ Term | Meaning
|
||||||
-----------------------------------------------|--------
|
-----------------------------------------------|--------
|
||||||
<span id="arena">arena/arena allocation</span> | An _arena_ is a large memory buffer from which other memory allocations are made. This style of allocation is called _arena allocation_. See [this chapter](../memory.md) for more info.
|
<span id="arena">arena/arena allocation</span> | An _arena_ is a large memory buffer from which other memory allocations are made. This style of allocation is called _arena allocation_. See [this chapter](../memory.md) for more info.
|
||||||
<span id="ast">AST</span> | The abstract syntax tree produced by the `rustc_ast` crate; reflects user syntax very closely.
|
<span id="ast">AST</span> | The abstract syntax tree produced by the `rustc_ast` crate; reflects user syntax very closely.
|
||||||
<span id="binder">binder</span> | 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](./background.html#free-vs-bound).
|
<span id="binder">binder</span> | 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](./background.md#free-vs-bound).
|
||||||
<span id="body-id">BodyId</span> | An identifier that refers to a specific body (definition of a function or constant) in the crate. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir).
|
<span id="body-id">BodyId</span> | An identifier that refers to a specific body (definition of a function or constant) in the crate. See [the HIR chapter for more](../hir.md#identifiers-in-the-hir).
|
||||||
<span id="bound-var">bound variable</span> | A "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound)
|
<span id="bound-var">bound variable</span> | A "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.md#free-vs-bound)
|
||||||
<span id="codegen">codegen</span> | The code to translate MIR into LLVM IR.
|
<span id="codegen">codegen</span> | The code to translate MIR into LLVM IR.
|
||||||
<span id="codegen-unit">codegen unit</span> | When we produce LLVM IR, we group the Rust code into a number of codegen units (sometimes abbreviated as CGUs). Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. ([see more](../backend/codegen.md))
|
<span id="codegen-unit">codegen unit</span> | When we produce LLVM IR, we group the Rust code into a number of codegen units (sometimes abbreviated as CGUs). Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. ([see more](../backend/codegen.md))
|
||||||
<span id="completeness">completeness</span> | A technical term in type theory, it 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").
|
<span id="completeness">completeness</span> | A technical term in type theory, it 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").
|
||||||
<span id="cfg">control-flow graph</span> | A representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg)
|
<span id="cfg">control-flow graph</span> | A representation of the control-flow of a program; see [the background chapter for more](./background.md#cfg)
|
||||||
<span id="ctfe">CTFE</span> | Short for Compile-Time Function Evaluation, this is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.html))
|
<span id="ctfe">CTFE</span> | Short for Compile-Time Function Evaluation, this is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.md))
|
||||||
<span id="cx">cx</span> | We tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc.
|
<span id="cx">cx</span> | We tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc.
|
||||||
<span id="ctxt">ctxt</span> | We also use "ctxt" as an abbreviation for context, e.g. [`TyCtxt`](#TyCtxt). See also [cx](#cx) or [tcx](#tcx).
|
<span id="ctxt">ctxt</span> | We also use "ctxt" as an abbreviation for context, e.g. [`TyCtxt`](#TyCtxt). See also [cx](#cx) or [tcx](#tcx).
|
||||||
<span id="dag">DAG</span> | A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html))
|
<span id="dag">DAG</span> | A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.md))
|
||||||
<span id="data-flow">data-flow analysis</span> | 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).
|
<span id="data-flow">data-flow analysis</span> | 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.md#dataflow).
|
||||||
<span id="debruijn">DeBruijn Index</span> | 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))
|
<span id="debruijn">DeBruijn Index</span> | 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))
|
||||||
<span id="def-id">DefId</span> | 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).
|
<span id="def-id">DefId</span> | An index identifying a definition (see `rustc_middle/src/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.md#identifiers-in-the-hir).
|
||||||
<span id="discriminant">Discriminant</span> | 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).
|
<span id="discriminant">Discriminant</span> | 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).
|
||||||
<span id="double-ptr">Double pointer</span> | A pointer with additional metadata. See "fat pointer" for more.
|
<span id="double-ptr">Double pointer</span> | A pointer with additional metadata. See "fat pointer" for more.
|
||||||
<span id="drop-glue">drop glue</span> | (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types.
|
<span id="drop-glue">drop glue</span> | (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types.
|
||||||
|
|
@ -25,10 +25,10 @@ Term | Meaning
|
||||||
<span id="ebl">early-bound lifetime</span> | A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions))
|
<span id="ebl">early-bound lifetime</span> | A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions))
|
||||||
<span id="empty-type">empty type</span> | see "uninhabited type".
|
<span id="empty-type">empty type</span> | see "uninhabited type".
|
||||||
<span id="fat-ptr">Fat pointer</span> | 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".
|
<span id="fat-ptr">Fat pointer</span> | 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".
|
||||||
<span id="free-var">free variable</span> | A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound)
|
<span id="free-var">free variable</span> | A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.md#free-vs-bound)
|
||||||
<span id="generics">generics</span> | The set of generic type parameters defined on a type or item.
|
<span id="generics">generics</span> | The set of generic type parameters defined on a type or item.
|
||||||
<span id="hir">HIR</span> | The High-level IR, created by lowering and desugaring the AST. ([see more](../hir.html))
|
<span id="hir">HIR</span> | The High-level IR, created by lowering and desugaring the AST. ([see more](../hir.md))
|
||||||
<span id="hir-id">HirId</span> | Identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". See [the HIR chapter for more](../hir.html#identifiers-in-the-hir).
|
<span id="hir-id">HirId</span> | Identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". See [the HIR chapter for more](../hir.md#identifiers-in-the-hir).
|
||||||
<span id="hir-map">HIR Map</span> | The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers.
|
<span id="hir-map">HIR Map</span> | The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers.
|
||||||
<span id="ice">ICE</span> | Short for internal compiler error, this is when the compiler crashes.
|
<span id="ice">ICE</span> | Short for internal compiler error, this is when the compiler crashes.
|
||||||
<span id="ich">ICH</span> | 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.
|
<span id="ich">ICH</span> | 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.
|
||||||
|
|
@ -45,26 +45,26 @@ Term | Meaning
|
||||||
<span id="lto">LTO</span> | Short for Link-Time Optimizations, this is a set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations 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].
|
<span id="lto">LTO</span> | Short for Link-Time Optimizations, this is a set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations 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].
|
||||||
<span id="llvm">[LLVM]</span> | (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 outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports.
|
<span id="llvm">[LLVM]</span> | (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 outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports.
|
||||||
<span id="memoization">memoization</span> | The process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is typically a trade-off between execution speed and memory usage.
|
<span id="memoization">memoization</span> | The process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is typically a trade-off between execution speed and memory usage.
|
||||||
<span id="mir">MIR</span> | The Mid-level IR that is created after type-checking for use by borrowck and codegen. ([see more](../mir/index.html))
|
<span id="mir">MIR</span> | The Mid-level IR that is created after type-checking for use by borrowck and codegen. ([see more](../mir/index.md))
|
||||||
<span id="miri">miri</span> | An interpreter for MIR used for constant evaluation. ([see more](../miri.html))
|
<span id="miri">miri</span> | An interpreter for MIR used for constant evaluation. ([see more](../miri.md))
|
||||||
<span id="mono">monomorphization</span> | The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec<T>`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec<usize>`, a copy for `Vec<MyStruct>`, etc).
|
<span id="mono">monomorphization</span> | The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec<T>`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec<usize>`, a copy for `Vec<MyStruct>`, etc).
|
||||||
<span id="normalize">normalize</span> | A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/goals-and-clauses.html#normalizeprojection---type).
|
<span id="normalize">normalize</span> | A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/goals-and-clauses.md#normalizeprojection---type).
|
||||||
<span id="newtype">newtype</span> | 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.
|
<span id="newtype">newtype</span> | 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.
|
||||||
<span id="niche">Niche</span> | Invalid bit patterns for a type *that can be used* for layout optimizations. Some types cannot have certain bit patterns. For example, the `NonZero*` integers or the reference `&T` cannot be represented by a 0 bitstring. This means the compiler can perform layout optimizations by taking advantage of the invalid "niche value". An example application for this is the [*Discriminant elision on `Option`-like enums*](https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums), which allows using a type's niche as the ["tag"](#tag) for an `enum` without requiring a separate field.
|
<span id="niche">Niche</span> | Invalid bit patterns for a type *that can be used* for layout optimizations. Some types cannot have certain bit patterns. For example, the `NonZero*` integers or the reference `&T` cannot be represented by a 0 bitstring. This means the compiler can perform layout optimizations by taking advantage of the invalid "niche value". An example application for this is the [*Discriminant elision on `Option`-like enums*](https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums), which allows using a type's niche as the ["tag"](#tag) for an `enum` without requiring a separate field.
|
||||||
<span id="nll">NLL</span> | Short for [non-lexical lifetimes](../borrow_check/region_inference.html), this is an extension to Rust's borrowing system to make it be based on the control-flow graph.
|
<span id="nll">NLL</span> | Short for [non-lexical lifetimes](../borrow_check/region_inference.md), this is an extension to Rust's borrowing system to make it be based on the control-flow graph.
|
||||||
<span id="node-id">node-id or NodeId</span> | An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir).
|
<span id="node-id">node-id or NodeId</span> | An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.md#identifiers-in-the-hir).
|
||||||
<span id="obligation">obligation</span> | Something that must be proven by the trait system. ([see more](../traits/resolution.html))
|
<span id="obligation">obligation</span> | Something that must be proven by the trait system. ([see more](../traits/resolution.md))
|
||||||
<span id="placeholder">placeholder</span> | **NOTE: skolemization is deprecated by placeholder** 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 placeholder and universes](../borrow_check/region_inference/placeholders_and_universes.md) for more details.
|
<span id="placeholder">placeholder</span> | **NOTE: skolemization is deprecated by placeholder** 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 placeholder and universes](../borrow_check/region_inference/placeholders_and_universes.md) for more details.
|
||||||
<span id="point">point</span> | Used in the NLL analysis to refer to some particular location in the MIR; typically used to refer to a node in the control-flow graph.
|
<span id="point">point</span> | Used in the NLL analysis to refer to some particular location in the MIR; typically used to refer to a node in the control-flow graph.
|
||||||
<span id="polymorphize">polymorphize</span> | An optimization that avoids unnecessary monomorphisation. ([see more](../backend/monomorph.md#polymorphization))
|
<span id="polymorphize">polymorphize</span> | An optimization that avoids unnecessary monomorphisation. ([see more](../backend/monomorph.md#polymorphization))
|
||||||
<span id="projection">projection</span> | 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).
|
<span id="projection">projection</span> | 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.md#trait-ref).
|
||||||
<span id="pc">promoted constants</span> | Constants extracted from a function and lifted to static scope; see [this section](../mir/index.html#promoted) for more details.
|
<span id="pc">promoted constants</span> | Constants extracted from a function and lifted to static scope; see [this section](../mir/index.md#promoted) for more details.
|
||||||
<span id="provider">provider</span> | The function that executes a query. ([see more](../query.html))
|
<span id="provider">provider</span> | The function that executes a query. ([see more](../query.md))
|
||||||
<span id="quantified">quantified</span> | 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](./background.html#quantified).
|
<span id="quantified">quantified</span> | 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](./background.md#quantified).
|
||||||
<span id="query">query</span> | Perhaps some sub-computation during compilation. ([see more](../query.html))
|
<span id="query">query</span> | Perhaps some sub-computation during compilation. ([see more](../query.md))
|
||||||
<span id="recovery">recovery</span> | Recovery refers to handling invalid syntax during parsing (e.g. a missing comma) and continuing to parse the AST. This avoid showing spurious errors to the user (e.g. showing 'missing field' errors when the struct definition contains errors).
|
<span id="recovery">recovery</span> | Recovery refers to handling invalid syntax during parsing (e.g. a missing comma) and continuing to parse the AST. This avoid showing spurious errors to the user (e.g. showing 'missing field' errors when the struct definition contains errors).
|
||||||
<span id="region">region</span> | Another term for "lifetime" often used in the literature and in the borrow checker.
|
<span id="region">region</span> | Another term for "lifetime" often used in the literature and in the borrow checker.
|
||||||
<span id="rib">rib</span> | A data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.html))
|
<span id="rib">rib</span> | A data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.md))
|
||||||
<span id="scrutinee">scrutinee</div> | A scrutinee is the expression that is matched on in `match` expressions and similar pattern matching constructs. For example, in `match x { A => 1, B => 2 }`, the expression `x` is the scrutinee.
|
<span id="scrutinee">scrutinee</div> | A scrutinee is the expression that is matched on in `match` expressions and similar pattern matching constructs. For example, in `match x { A => 1, B => 2 }`, the expression `x` is the scrutinee.
|
||||||
<span id="sess">sess</span> | The compiler session, which stores global data used throughout compilation
|
<span id="sess">sess</span> | The compiler session, which stores global data used throughout compilation
|
||||||
<span id="side-tables">side tables</span> | 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.
|
<span id="side-tables">side tables</span> | 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.
|
||||||
|
|
@ -73,18 +73,18 @@ Term | Meaning
|
||||||
<span id="span">span</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.
|
<span id="span">span</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.
|
||||||
<span id="substs">substs</span> | The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap<i32, u32>`).
|
<span id="substs">substs</span> | The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap<i32, u32>`).
|
||||||
<span id="tag">Tag</span> | The "tag" of an enum/generator encodes the [discriminant](#discriminant) of the active variant/state. Tags can either be "direct" (simply storing the discriminant in a field) or use a ["niche"](#niche).
|
<span id="tag">Tag</span> | The "tag" of an enum/generator encodes the [discriminant](#discriminant) of the active variant/state. Tags can either be "direct" (simply storing the discriminant in a field) or use a ["niche"](#niche).
|
||||||
<span id="tcx">tcx</span> | The "typing context", main data structure of the compiler. ([see more](../ty.html))
|
<span id="tcx">tcx</span> | The "typing context", main data structure of the compiler. ([see more](../ty.md))
|
||||||
<span id="lifetime-tcx">`'tcx`</span> | The lifetime of the allocation arena. ([see more](../ty.html))
|
<span id="lifetime-tcx">`'tcx`</span> | The lifetime of the allocation arena. ([see more](../ty.md))
|
||||||
<span id="token">token</span> | The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)).
|
<span id="token">token</span> | The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.md)).
|
||||||
<span id="tls">[TLS]</span> | 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.
|
<span id="tls">[TLS]</span> | 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.
|
||||||
<span id="trait-ref">trait reference</span> | The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.html#trait-ref))
|
<span id="trait-ref">trait reference</span> | The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.md#trait-ref))
|
||||||
<span id="trans">trans</span> | The code to translate MIR into LLVM IR. Renamed to codegen.
|
<span id="trans">trans</span> | The code to translate MIR into LLVM IR. Renamed to codegen.
|
||||||
<span id="ty">ty</span> | The internal representation of a type. ([see more](../ty.html))
|
<span id="ty">ty</span> | The internal representation of a type. ([see more](../ty.md))
|
||||||
<span id="tyctxt">TyCtxt</span> | The data structure often referred to as [tcx](#tcx) in code
|
<span id="tyctxt">TyCtxt</span> | The data structure often referred to as [tcx](#tcx) in code
|
||||||
<span id="ufcs">UFCS</span> | Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.html))
|
<span id="ufcs">UFCS</span> | Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.md))
|
||||||
<span id="ut">uninhabited type</span> | A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types".
|
<span id="ut">uninhabited type</span> | A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types".
|
||||||
<span id="upvar">upvar</span> | A variable captured by a closure from outside the closure.
|
<span id="upvar">upvar</span> | A variable captured by a closure from outside the closure.
|
||||||
<span id="variance">variance</span> | 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](./background.html#variance) for a more general explanation. See the [variance chapter](../variance.html) for an explanation of how type checking handles variance.
|
<span id="variance">variance</span> | 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](./background.md#variance) for a more general explanation. See the [variance chapter](../variance.md) for an explanation of how type checking handles variance.
|
||||||
<span id="variant-idx">Variant index</span> | In an enum, identifies a variant by assigning them indices starting at 0. This is purely internal and not to be confused with the ["discrimiant"](#discriminant) which can be overwritten by the user (e.g. `enum Bool { True = 42, False = 0 }`).
|
<span id="variant-idx">Variant index</span> | In an enum, identifies a variant by assigning them indices starting at 0. This is purely internal and not to be confused with the ["discrimiant"](#discriminant) which can be overwritten by the user (e.g. `enum Bool { True = 42, False = 0 }`).
|
||||||
<span id="wide-ptr">Wide pointer</span> | A pointer with additional metadata. See "fat pointer" for more.
|
<span id="wide-ptr">Wide pointer</span> | A pointer with additional metadata. See "fat pointer" for more.
|
||||||
<span id="zst">ZST</span> | Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs.
|
<span id="zst">ZST</span> | Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs.
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue