Return to The Rust Reference, Rust, Rust Outline, Rust Bibliography, Rust Courses, Rust Topics, Awesome Lists

https://github.com/rust-unofficial/awesome-rust

Glossary

• Rust Abstract syntax tree - “An ‘abstract syntax tree’, or ‘AST’, is an intermediate representation of the structure of the program when the compiler is compiling it.” (RstGls)

• Rust Alignment - “The alignment of a value specifies what addresses values are preferred to start at. Always a power of two. References to a value must be aligned. More.” (RstGls)

• Rust Arity - “Arity refers to the number of arguments a function or operator takes. For some examples, f(2, 3) and g(4, 6) have arity 2, while h(8, 2, 6) has arity 3. The ! operator has arity 1.” (RstGls)

• Rust Array - “An array, sometimes also called a fixed-size array or an inline array, is a value describing a collection of elements, each selected by an index that can be computed at run time by the program. It occupies a contiguous region of memory.” (RstGls)

• Rust Associated item - “An associated item is an item that is associated with another item. Associated items are defined in implementations and declared in traits. Only functions, constants, and type aliases can be associated. Contrast to a free item.” (RstGls)

• Rust Blanket implementation - “Any implementation where a type appears uncovered. impl<T> Foo for T, impl<T> Bar<T> for T, impl<T> Bar<Vec<T» for T, and impl<T> Bar<T> for Vec<T> are considered blanket impls. However, impl<T> Bar<Vec<T» for Vec<T> is not a blanket impl, as all instances of T which appear in this impl are covered by Vec.” (RstGls)

• Rust Bound - “Bounds are constraints on a type or trait. For example, if a bound is placed on the argument a function takes, types passed to that function must abide by that constraint.” (RstGls)

• Rust Combinator - “Combinators are higher-order functions that apply only functions and earlier defined combinators to provide a result from its arguments. They can be used to manage control flow in a modular fashion.” (RstGls)

• Rust Crate - “A crate is the unit of compilation and linking. There are different types of crates, such as libraries or executables. Crates may link and refer to other library crates, called external crates. A crate has a self-contained tree of modules, starting from an unnamed root module called the crate root. Items may be made visible to other crates by marking them as public in the crate root, including through paths of public modules. More.” (RstGls)

• Rust Dispatch - “Dispatch is the mechanism to determine which specific version of code is actually run when it involves polymorphism. Two major forms of dispatch are static dispatch and dynamic dispatch. While Rust favors static dispatch, it also supports dynamic dispatch through a mechanism called ‘trait objects’.” (RstGls)

• Rust Dynamically sized type - “A dynamically sized type (DST) is a type without a statically known size or alignment.” (RstGls)

• Rust Entity - “An entity is a language construct that can be referred to in some way within the source program, usually via a path. Entities include types, items, generic parameters, variable bindings, loop labels, lifetimes, fields, attributes, and lints.” (RstGls)

• Rust Expression - “An expression is a combination of values, constants, variables, operators and functions that evaluate to a single value, with or without side-effects. For example, 2 + (3 * 4) is an expression that returns the value 14.” (RstGls)

• Rust Free item - “An item that is not a member of an implementation, such as a free function or a free const. Contrast to an associated item.” (RstGls)

• Rust Fundamental traits - “A fundamental trait is one where adding an impl of it for an existing type is a breaking change. The Fn traits and Sized are fundamental.” (RstGls)

• Rust Fundamental type constructors - “A fundamental type constructor is a type where implementing a blanket implementation over it is a breaking change. &, &mut, Box, and Pin are fundamental.

Any time a type T is considered local, &T, &mut T, Box<T>, and Pin<T> are also considered local. Fundamental type constructors cannot cover other types. Any time the term “covered type” is used, the T in &T, &mut T, Box<T>, and Pin<T> is not considered covered.” (RstGls)

• Rust Inhabited - “A type is inhabited if it has constructors and therefore can be instantiated. An inhabited type is not “empty” in the sense that there can be values of the type. Opposite of Uninhabited.” (RstGls)

• Rust Inherent implementation - “An implementation that applies to a nominal type, not to a trait-type pair. More.” (RstGls)

• Rust Inherent method - “A method defined in an inherent implementation, not in a trait implementation.” (RstGls)

• Rust Initialized - “A variable is initialized if it has been assigned a value and hasn't since been moved from. All other memory locations are assumed to be uninitialized. Only unsafe Rust can create a memory location without initializing it.” (RstGls)

• Rust Local trait - “A trait which was defined in the current crate. A trait definition is local or not independent of applied type arguments. Given trait Foo<T, U>, Foo is always local, regardless of the types substituted for T and U.” (RstGls)

• Rust Local type - “A struct, enum, or union which was defined in the current crate. This is not affected by applied type arguments. struct Foo is considered local, but Vec<Foo> is not. LocalType<ForeignType> is local. Type aliases do not affect locality.” (RstGls)

• Rust Module - “A module is a container for zero or more items. Modules are organized in a tree, starting from an unnamed module at the root called the crate root or the root module. Paths may be used to refer to items from other modules, which may be restricted by visibility rules. More” (RstGls)

• Rust Name - “A name is an identifier or lifetime or loop label that refers to an entity. A name binding is when an entity declaration introduces an identifier or label associated with that entity. Paths, identifiers, and labels are used to refer to an entity.” (RstGls)

• Rust Name resolution - “Name resolution is the compile-time process of tying paths, identifiers, and labels to entity declarations.” (RstGls)

• Rust Namespace - “A namespace is a logical grouping of declared names based on the kind of entity the name refers to. Namespaces allow the occurrence of a name in one namespace to not conflict with the same name in another namespace.” (RstGls)

Within a namespace, names are organized in a hierarchy, where each level of the hierarchy has its own collection of named entities.“ (RstGls)

• Rust Nominal types - “Types that can be referred to by a path directly. Specifically enums, structs, unions, and trait objects.” (RstGls)

• Rust Object safe traits - “Traits that can be used as trait objects. Only traits that follow specific rules are object safe.” (RstGls)

• Rust Path - “A path is a sequence of one or more path segments used to refer to an entity in the current scope or other levels of a namespace hierarchy.” (RstGls)

• Rust Prelude - “Prelude, or The Rust Prelude, is a small collection of items - mostly traits - that are imported into every module of every crate. The traits in the prelude are pervasive.” (RstGls)

• Rust Scope - “A scope is the region of source text where a named entity may be referenced with that name.” (RstGls)

• Rust Scrutinee - “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.” (RstGls)

• Rust Size - “The size of a value has two definitions.

The first is that it is how much memory must be allocated to store that value.

The second is that it is the offset in bytes between successive elements in an array with that item type.

It is a multiple of the alignment, including zero. The size can change depending on compiler version (as new optimizations are made) and target platform (similar to how usize varies per-platform). More.” (RstGls)

• Rust Slice - “A slice is dynamically-sized view into a contiguous sequence, written as [T].

It is often seen in its borrowed forms, either mutable or shared. The shared slice type is &[T], while the mutable slice type is &mut [T], where T represents the element type.” (RstGls)

• Rust Statement - “A statement is the smallest standalone element of a programming language that commands a computer to perform an action.” (RstGls)

• Rust String literal - “A string literal is LITERALLY a string stored directly in the final binary, and so will be valid for the 'static duration.

Its type is 'static duration borrowed string slice, &'static str.” (RstGls)

• Rust String slice - “A string slice is the most primitive string type in Rust, written as str. It is often seen in its borrowed forms, either mutable or shared. The shared string slice type is &str, while the mutable string slice type is &mut str.

Strings slices are always valid UTF-8.” (RstGls)

• Rust Trait - “A trait is a language item that is used for describing the functionalities a type must provide. It allows a type to make certain promises about its behavior.

Generic functions and generic structs can use traits to constrain, or bound, the types they accept.” (RstGls)

• Rust Turbofish - “Paths with generic parameters in expressions must prefix the opening brackets with a ::. Combined with the angular brackets for generics, this looks like a fish ::<>. As such, this syntax is colloquially referred to as turbofish syntax.

Examples:

let ok_num = Ok::<_, ()>(5); let vec = [1, 2, 3].iter().map(|n| n * 2).collect::<Vec<_»(); This :: prefix is required to disambiguate generic paths with multiple comparisons in a comma-separate list. See the bastion of the turbofish for an example where not having the prefix would be ambiguous.” (RstGls)

• Rust Uncovered type - “A type which does not appear as an argument to another type. For example, T is uncovered, but the T in Vec<T> is covered. This is only relevant for type arguments.” (RstGls)

• Rust Undefined behavior - “Compile-time or run-time behavior that is not specified. This may result in, but is not limited to: process termination or corruption; improper, incorrect, or unintended computation; or platform-specific results. More.” (RstGls)

• Rust Uninhabited - “A type is uninhabited if it has no constructors and therefore can never be instantiated. An uninhabited type is “empty” in the sense that there are no values of the type. The canonical example of an uninhabited type is the never type !, or an enum with no variants enum Never { }. Opposite of Rust Inhabited.” (RstGls)

https://doc.rust-lang.org/beta/reference/glossary.html

Fair Use Sources:

• RstGls https://doc.rust-lang.org/beta/reference/glossary.html
• Awesome Rust on GitHub

Rust Glossary of Terms

Rust Terms

Rust Term

” (RiA)

• Abstract syntax tree - Rust Abstract syntax tree - An ‘abstract syntax tree’, or ‘AST’, is an intermediate representation of the structure of the program when the compiler is compiling it.

• Alignment - Rust Alignment - The alignment of a value specifies what addresses values are preferred to start at. Always a power of two. References to a value must be aligned. More.

• Arity - Rust Arity - Arity refers to the number of arguments a function or operator takes. For some examples, f(2, 3) and g(4, 6) have arity 2, while h(8, 2, 6) has arity 3. The ! operator has arity 1. * [[Array - Rust Array - An array, sometimes also called a fixed-size array or an inline array, is a value describing a collection of elements, each selected by an index that can be computed at run time by the program. It occupies a contiguous region of memory.

• Associated item - Rust Associated item - An associated item is an item that is associated with another item. Associated items are defined in implementations and declared in traits. Only functions, constants, and type aliases can be associated. Contrast to a free item.

• Blanket implementation - Rust Z - Any implementation where a type appears uncovered. impl<T> Foo for T, impl<T> Bar<T> for T, impl<T> Bar<Vec<T» for T, and impl<T> Bar<T> for Vec<T> are considered blanket impls. However, impl<T> Bar<Vec<T» for Vec<T> is not a blanket impl, as all instances of T which appear in this impl are covered by Vec.

• Bound - Rust Z - Bounds are constraints on a type or trait. For example, if a bound is placed on the argument a function takes, types passed to that function must abide by that constraint.

• Combinator - Rust Z - Combinators are higher-order functions that apply only functions and earlier defined combinators to provide a result from its arguments. They can be used to manage control flow in a modular fashion.

• Crate - Rust Z - A crate is the unit of compilation and linking. There are different types of crates, such as libraries or executables. Crates may link and refer to other library crates, called external crates. A crate has a self-contained tree of modules, starting from an unnamed root module called the crate root. Items may be made visible to other crates by marking them as public in the crate root, including through paths of public modules. More.

• Dispatch - Rust Z - Dispatch is the mechanism to determine which specific version of code is actually run when it involves polymorphism. Two major forms of dispatch are static dispatch and dynamic dispatch. While Rust favors static dispatch, it also supports dynamic dispatch through a mechanism called ‘trait objects’.

• Dynamically sized type - Rust Z - A dynamically sized type (DST) is a type without a statically known size or alignment.

• Entity - Rust Z - An entity is a language construct that can be referred to in some way within the source program, usually via a path. Entities include types, items, generic parameters, variable bindings, loop labels, lifetimes, fields, attributes, and lints.

• Expression - Rust Z - An expression is a combination of values, constants, variables, operators and functions that evaluate to a single value, with or without side-effects.

For example, 2 + (3 * 4) is an expression that returns the value 14.

• Free item - Rust Z - An item that is not a member of an implementation, such as a free function or a free const. Contrast to an associated item.

• Fundamental traits - Rust Z - A fundamental trait is one where adding an impl of it for an existing type is a breaking change. The Fn traits and Sized are fundamental.

• Fundamental type constructors - Rust Z - A fundamental type constructor is a type where implementing a blanket implementation over it is a breaking change. &, &mut, Box, and Pin are fundamental.

Any time a type T is considered local, &T, &mut T, Box<T>, and Pin<T> are also considered local. Fundamental type constructors cannot cover other types. Any time the term “covered type” is used, the T in &T, &mut T, Box<T>, and Pin<T> is not considered covered.

• Inhabited - Rust Z - A type is inhabited if it has constructors and therefore can be instantiated. An inhabited type is not “empty” in the sense that there can be values of the type. Opposite of Uninhabited.

• Inherent implementation - Rust Z - An implementation that applies to a nominal type, not to a trait-type pair. More.

• Inherent method - Rust Z - A method defined in an inherent implementation, not in a trait implementation.

• Initialized - Rust Z - A variable is initialized if it has been assigned a value and hasn't since been moved from. All other memory locations are assumed to be uninitialized. Only unsafe Rust can create a memory location without initializing it.

• Local trait - Rust Z - A trait which was defined in the current crate. A trait definition is local or not independent of applied type arguments. Given trait Foo<T, U>, Foo is always local, regardless of the types substituted for T and U.

• Local type - Rust Z - A struct, enum, or union which was defined in the current crate. This is not affected by applied type arguments. struct Foo is considered local, but Vec<Foo> is not. LocalType<ForeignType> is local. Type aliases do not affect locality.

• Module - Rust Z - A module is a container for zero or more items. Modules are organized in a tree, starting from an unnamed module at the root called the crate root or the root module. Paths may be used to refer to items from other modules, which may be restricted by visibility rules. More

• Name - Rust Z - A name is an identifier or lifetime or loop label that refers to an entity. A name binding is when an entity declaration introduces an identifier or label associated with that entity. Paths, identifiers, and labels are used to refer to an entity.

• Name resolution - Rust Z - Name resolution is the compile-time process of tying paths, identifiers, and labels to entity declarations.

• Namespace - Rust Z - A namespace is a logical grouping of declared names based on the kind of entity the name refers to. Namespaces allow the occurrence of a name in one namespace to not conflict with the same name in another namespace.

Within a namespace, names are organized in a hierarchy, where each level of the hierarchy has its own collection of named entities.

• Nominal types - Rust Z - Types that can be referred to by a path directly. Specifically enums, structs, unions, and trait objects.

• Object safe traits - Rust Z - Traits that can be used as trait objects. Only traits that follow specific rules are object safe.

• Path - Rust Z - A path is a sequence of one or more path segments used to refer to an entity in the current scope or other levels of a namespace hierarchy.

• Prelude - Rust Z - Prelude, or The Rust Prelude, is a small collection of items - mostly traits - that are imported into every module of every crate. The traits in the prelude are pervasive.

• Scope - Rust Z - A scope is the region of source text where a named entity may be referenced with that name.

• Scrutinee - Rust Z - 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.

• Size - Rust Z - The size of a value has two definitions.

The first is that it is how much memory must be allocated to store that value.

The second is that it is the offset in bytes between successive elements in an array with that item type.

It is a multiple of the alignment, including zero. The size can change depending on compiler version (as new optimizations are made) and target platform (similar to how usize varies per-platform).

More.

• Slice - Rust Z - A slice is dynamically-sized view into a contiguous sequence, written as [T].

It is often seen in its borrowed forms, either mutable or shared. The shared slice type is &[T], while the mutable slice type is &mut [T], where T represents the element type.

• Statement - Rust Z - A statement is the smallest standalone element of a programming language that commands a computer to perform an action.

• String literal - Rust Z - A string literal is a string stored directly in the final binary, and so will be valid for the 'static duration.

Its type is 'static duration borrowed string slice, &'static str.

• String slice - Rust Z - A string slice is the most primitive string type in Rust, written as str. It is often seen in its borrowed forms, either mutable or shared. The shared string slice type is &str, while the mutable string slice type is &mut str.

Strings slices are always valid UTF-8.

• Trait - Rust Z - A trait is a language item that is used for describing the functionalities a type must provide. It allows a type to make certain promises about its behavior.

Generic functions and generic structs can use traits to constrain, or bound, the types they accept.

• Turbofish - Rust Z - Paths with generic parameters in expressions must prefix the opening brackets with a ::. Combined with the angular brackets for generics, this looks like a fish ::<>. As such, this syntax is colloquially referred to as turbofish syntax.

Examples:

let ok_num = Ok::<_, ()>(5); let vec = [1, 2, 3].iter().map(|n| n * 2).collect::<Vec<_»(); This :: prefix is required to disambiguate generic paths with multiple comparisons in a comma-separate list. See the bastion of the turbofish for an example where not having the prefix would be ambiguous.

• Uncovered type - Rust Z - A type which does not appear as an argument to another type. For example, T is uncovered, but the T in Vec<T> is covered. This is only relevant for type arguments.

• Undefined behavior - Rust Z - Compile-time or run-time behavior that is not specified. This may result in, but is not limited to: process termination or corruption; improper, incorrect, or unintended computation; or platform-specific results. More.

• Uninhabited - Rust Z - A type is uninhabited if it has no constructors and therefore can never be instantiated. An uninhabited type is “empty” in the sense that there are no values of the type. The canonical example of an uninhabited type is the never type !, or an enum with no variants enum Never { }. Opposite of Inhabited.

Fair Use Source: https://doc.rust-lang.org/beta/reference/glossary.html

Introduction 1. Getting Started 1.1. Installation 1.2. First Steps with Cargo 2. Cargo Guide 2.1. Why Cargo Exists 2.2. Creating a New Package 2.3. Working on an Existing Package 2.4. Dependencies 2.5. Package Layout 2.6. Cargo.toml vs Cargo.lock 2.7. Tests 2.8. Continuous Integration 2.9. Cargo Home 2.10. Build Cache 3. Cargo Reference 3.1. Specifying Dependencies 3.1.1. Overriding Dependencies 3.2. The Manifest Format 3.2.1. Cargo Targets 3.3. Workspaces 3.4. Features 3.4.1. Features Examples 3.5. Profiles 3.6. Configuration 3.7. Environment Variables 3.8. Build Scripts 3.8.1. Build Script Examples 3.9. Publishing on crates.io 3.10. Package ID Specifications 3.11. Source Replacement 3.12. External Tools 3.13. Registries 3.14. Dependency Resolution 3.15. SemVer Compatibility 3.16. Future incompat report 3.17. Reporting build timings 3.18. Unstable Features 4. Cargo Commands 4.1. General Commands 4.1.1. cargo 4.1.2. cargo help 4.1.3. cargo version 4.2. Build Commands 4.2.1. cargo bench 4.2.2. cargo build 4.2.3. cargo check 4.2.4. cargo clean 4.2.5. cargo doc 4.2.6. cargo fetch 4.2.7. cargo fix 4.2.8. cargo run 4.2.9. cargo rustc 4.2.10. cargo rustdoc 4.2.11. cargo test 4.2.12. cargo report 4.3. Manifest Commands 4.3.1. cargo add 4.3.2. cargo generate-lockfile 4.3.3. cargo locate-project 4.3.4. cargo metadata 4.3.5. cargo pkgid 4.3.6. cargo tree 4.3.7. cargo update 4.3.8. cargo vendor 4.3.9. cargo verify-project 4.4. Package Commands 4.4.1. cargo init 4.4.2. cargo install 4.4.3. cargo new 4.4.4. cargo search 4.4.5. cargo uninstall 4.5. Publishing Commands 4.5.1. cargo login 4.5.2. cargo owner 4.5.3. cargo package 4.5.4. cargo publish 4.5.5. cargo yank 5. FAQ 6. Appendix: Glossary 7. Appendix: Git Authentication

The Cargo Book

Cargo Cargo is the Rust package manager, and the primary topic of this book.

Cargo.lock See lock file.

Cargo.toml See manifest.

Crate A Rust crate is either a library or an executable program, referred to as either a library crate or a binary crate, respectively.

Every target defined for a Cargo package is a crate.

Loosely, the term crate may refer to either the source code of the target or to the compiled artifact that the target produces. It may also refer to a compressed package fetched from a registry.

The source code for a given crate may be subdivided into modules.

Edition A Rust edition is a developmental landmark of the Rust language. The edition of a package is specified in the Cargo.toml manifest, and individual targets can specify which edition they use. See the Edition Guide for more information.

Feature The meaning of feature depends on the context:

A feature is a named flag which allows for conditional compilation. A feature can refer to an optional dependency, or an arbitrary name defined in a Cargo.toml manifest that can be checked within source code.

Cargo has unstable feature flags which can be used to enable experimental behavior of Cargo itself.

The Rust compiler and Rustdoc have their own unstable feature flags (see The Unstable Book and The Rustdoc Book).

CPU targets have target features which specify capabilities of a CPU.

Index The index is the searchable list of crates in a registry.

Lock file The Cargo.lock lock file is a file that captures the exact version of every dependency used in a workspace or package. It is automatically generated by Cargo. See Cargo.toml vs Cargo.lock.

Manifest A manifest is a description of a package or a workspace in a file named Cargo.toml.

A virtual manifest is a Cargo.toml file that only describes a workspace, and does not include a package.

Member A member is a package that belongs to a workspace.

Module Rust's module system is used to organize code into logical units called modules, which provide isolated namespaces within the code.

The source code for a given crate may be subdivided into one or more separate modules. This is usually done to organize the code into areas of related functionality or to control the visible scope (public/private) of symbols within the source (structs, functions, and so on).

A Cargo.toml file is primarily concerned with the package it defines, its crates, and the packages of the crates on which they depend. Nevertheless, you will see the term “module” often when working with Rust, so you should understand its relationship to a given crate.

Package A package is a collection of source files and a Cargo.toml manifest file which describes the package. A package has a name and version which is used for specifying dependencies between packages.

A package contains multiple targets, each of which is a crate. The Cargo.toml file describes the type of the crates (binary or library) within the package, along with some metadata about each one – how each is to be built, what their direct dependencies are, etc., as described throughout this book.

The package root is the directory where the package's Cargo.toml manifest is located. (Compare with workspace root.)

The package ID specification, or SPEC, is a string used to uniquely reference a specific version of a package from a specific source.

Small to medium sized Rust projects will only need a single package, though it is common for them to have multiple crates.

Larger projects may involve multiple packages, in which case Cargo workspaces can be used to manage common dependencies and other related metadata between the packages.

Package manager Broadly speaking, a package manager is a program (or collection of related programs) in a software ecosystem that automates the process of obtaining, installing, and upgrading artifacts. Within a programming language ecosystem, a package manager is a developer-focused tool whose primary functionality is to download library artifacts and their dependencies from some central repository; this capability is often combined with the ability to perform software builds (by invoking the language-specific compiler).

Cargo is the package manager within the Rust ecosystem. Cargo downloads your Rust package’s dependencies (artifacts known as crates), compiles your packages, makes distributable packages, and (optionally) uploads them to crates.io, the Rust community’s package registry.

Package registry See registry.

Project Another name for a package.

Registry A registry is a service that contains a collection of downloadable crates that can be installed or used as dependencies for a package. The default registry in the Rust ecosystem is crates.io. The registry has an index which contains a list of all crates, and tells Cargo how to download the crates that are needed.

Source A source is a provider that contains crates that may be included as dependencies for a package. There are several kinds of sources:

Registry source — See registry. Local registry source — A set of crates stored as compressed files on the filesystem. See Local Registry Sources. Directory source — A set of crates stored as uncompressed files on the filesystem. See Directory Sources. Path source — An individual package located on the filesystem (such as a path dependency) or a set of multiple packages (such as path overrides). Git source — Packages located in a git repository (such as a git dependency or git source). See Source Replacement for more information.

Spec See package ID specification.

Target The meaning of the term target depends on the context:

Cargo Target — Cargo packages consist of targets which correspond to artifacts that will be produced. Packages can have library, binary, example, test, and benchmark targets. The list of targets are configured in the Cargo.toml manifest, often inferred automatically by the directory layout of the source files.

Target Directory — Cargo places all built artifacts and intermediate files in the target directory. By default this is a directory named target at the workspace root, or the package root if not using a workspace. The directory may be changed with the –target-dir command-line option, the CARGO_TARGET_DIR environment variable, or the build.target-dir config option.

Target Architecture — The OS and machine architecture for the built artifacts are typically referred to as a target.

Target Triple — A triple is a specific format for specifying a target architecture. Triples may be referred to as a target triple which is the architecture for the artifact produced, and the host triple which is the architecture that the compiler is running on. The target triple can be specified with the –target command-line option or the build.target config option. The general format of the triple is <arch><sub>-<vendor>-<sys>-<abi> where:

arch = The base CPU architecture, for example x86_64, i686, arm, thumb, mips, etc. sub = The CPU sub-architecture, for example arm has v7, v7s, v5te, etc. vendor = The vendor, for example unknown, apple, pc, nvidia, etc. sys = The system name, for example linux, windows, darwin, etc. none is typically used for bare-metal without an OS. abi = The ABI, for example gnu, android, eabi, etc. Some parameters may be omitted. Run rustc –print target-list for a list of supported targets.

Test Targets Cargo test targets generate binaries which help verify proper operation and correctness of code. There are two types of test artifacts:

Unit test — A unit test is an executable binary compiled directly from a library or a binary target. It contains the entire contents of the library or binary code, and runs #[test] annotated functions, intended to verify individual units of code. Integration test target — An integration test target is an executable binary compiled from a test target which is a distinct crate whose source is located in the tests directory or specified by the test table in the Cargo.toml manifest. It is intended to only test the public API of a library, or execute a binary to verify its operation. Workspace A workspace is a collection of one or more packages that share common dependency resolution (with a shared Cargo.lock lock file), output directory, and various settings such as profiles.

A virtual workspace is a workspace where the root Cargo.toml manifest does not define a package, and only lists the workspace members.

The workspace root is the directory where the workspace's Cargo.toml manifest is located. (Compare with package root.)

https://doc.rust-lang.org/cargo/appendix/glossary.html

Fair Use Sources:

• https://doc.rust-lang.org/beta/reference/glossary.html
• https://doc.rust-lang.org/cargo/appendix/glossary.html

• 1617294556 (RiA1)

• WkPd
• 1718500440 (RPL18)
• 1492052593 (PrRst2)