cargo bench -- foo --exact-
-t typeman — A troff-style man page. Outputs with a numbered extension (like
+.1) matching the man page section.md — A markdown file, after all handlebars processing has been finished.
+Outputs with the .md extension.txt — A text file, rendered for situations where a man page viewer isn't
+available. Outputs with the .txt extension.-o outdir--url base_url--man name:section=url{{man name section}} expression is used, the given URL will be inserted as a link. This
+may be specified multiple times. If a man page reference does not have a
+matching --man entry, then a relative link to a file named name.md will
+be used.", "
") + } + + for param in params { + let rendered = self.render_html(param)?; + let no_p = unwrap_p(&rendered); + // split out first term to use as the id. + let first = no_p + .split_whitespace() + .next() + .ok_or_else(|| format_err!("did not expect option `{}` to be empty", param))?; + let no_tags = trim_tags(first); + if no_tags.is_empty() { + bail!("unexpected empty option with no tags `{}`", param); + } + let id = format!("option-{}-{}", man_name, no_tags); + write!( + result, + "--foo-bar-p spec--package spec@filename--foo [bar]--foo[=bar]cargo-bench - Execute benchmarks of a package
-cargo bench [OPTIONS] [BENCHNAME] [-- BENCH-OPTIONS]
Compile and execute benchmarks.
-The benchmark filtering argument BENCHNAME and all the arguments following
-the two dashes (--) are passed to the benchmark binaries and thus to
-libtest (rustc’s built in unit-test and micro-benchmarking framework). If
-you’re passing arguments to both Cargo and the binary, the ones after -- go
-to the binary, the ones before go to Cargo. For details about libtest’s
-arguments see the output of cargo bench -- --help. As an example, this will
-run only the benchmark named foo (and skip other similarly named benchmarks
-like foobar):
cargo bench -- foo --exact-
Benchmarks are built with the --test option to rustc which creates an
-executable with a main function that automatically runs all functions
-annotated with the #[bench] attribute. Cargo passes the --bench flag to
-the test harness to tell it to run only benchmarks.
The libtest harness may be disabled by setting harness = false in the target
-manifest settings, in which case your code will need to provide its own main
-function to handle running benchmarks.
----Note: The -
-#[bench]attribute -is currently unstable and only available on the -nightly channel. -There are some packages available on -crates.io that may help with -running benchmarks on the stable channel, such as -Criterion.
Compile, but don’t run benchmarks.
-Run all benchmarks regardless of failure. Without this flag, Cargo will exit -after the first executable fails. The Rust test harness will run all -benchmarks within the executable to completion, this flag only applies to -the executable as a whole.
-By default, when no package selection options are given, the packages selected
-depend on the selected manifest file (based on the current working directory if
---manifest-path is not given). If the manifest is the root of a workspace then
-the workspaces default members are selected, otherwise only the package defined
-by the manifest will be selected.
The default members of a workspace can be set explicitly with the
-workspace.default-members key in the root manifest. If this is not set, a
-virtual workspace will include all workspace members (equivalent to passing
---workspace), and a non-virtual workspace will include only the root crate itself.
Benchmark only the specified packages. See cargo-pkgid(1) for the -SPEC format. This flag may be specified multiple times.
-Benchmark all members in the workspace.
-Deprecated alias for --workspace.
Exclude the specified packages. Must be used in conjunction with the
---workspace flag. This flag may be specified multiple times.
When no target selection options are given, cargo bench will build the
-following targets of the selected packages:
lib — used to link with binaries and benchmarks
-bins (only if benchmark targets are built and required features are -available)
-lib as a benchmark
-bins as benchmarks
-benchmark targets
-The default behavior can be changed by setting the bench flag for the target
-in the manifest settings. Setting examples to bench = true will build and
-run the example as a benchmark. Setting targets to bench = false will stop
-them from being benchmarked by default. Target selection options that take a
-target by name ignore the bench flag and will always benchmark the given
-target.
Passing target selection flags will benchmark only the -specified targets.
-Benchmark the package’s library.
-Benchmark the specified binary. This flag may be specified multiple times.
-Benchmark all binary targets.
-Benchmark the specified example. This flag may be specified multiple times.
-Benchmark all example targets.
-Benchmark the specified integration test. This flag may be specified multiple -times.
-Benchmark all targets in test mode that have the test = true manifest
-flag set. By default this includes the library and binaries built as
-unittests, and integration tests. Be aware that this will also build any
-required dependencies, so the lib target may be built twice (once as a
-unittest, and once as a dependency for binaries, integration tests, etc.).
-Targets may be enabled or disabled by setting the test flag in the
-manifest settings for the target.
Benchmark the specified benchmark. This flag may be specified multiple times.
-Benchmark all targets in benchmark mode that have the bench = true
-manifest flag set. By default this includes the library and binaries built
-as benchmarks, and bench targets. Be aware that this will also build any
-required dependencies, so the lib target may be built twice (once as a
-benchmark, and once as a dependency for binaries, benchmarks, etc.).
-Targets may be enabled or disabled by setting the bench flag in the
-manifest settings for the target.
Benchmark all targets. This is equivalent to specifying --lib --bins
---tests --benches --examples.
The feature flags allow you to control the enabled features for the "current"
-package. The "current" package is the package in the current directory, or the
-one specified in --manifest-path. If running in the root of a virtual
-workspace, then the default features are selected for all workspace members,
-or all features if --all-features is specified.
When no feature options are given, the default feature is activated for
-every selected package.
Space or comma separated list of features to activate. These features only
-apply to the current directory’s package. Features of direct dependencies
-may be enabled with <dep-name>/<feature-name> syntax. This flag may be
-specified multiple times, which enables all specified features.
Activate all available features of all selected packages.
-Do not activate the default feature of the current directory’s
-package.
Benchmark for the given architecture. The default is the host
-architecture. The general format of the triple is
-<arch><sub>-<vendor>-<sys>-<abi>. Run rustc --print target-list for a
-list of supported targets.
This may also be specified with the build.target
-config value.
Note that specifying this flag makes Cargo run in a different mode where the -target artifacts are placed in a separate directory. See the -build cache documentation for more details.
-Directory for all generated artifacts and intermediate files. May also be
-specified with the CARGO_TARGET_DIR environment variable, or the
-build.target-dir config value. Defaults
-to target in the root of the workspace.
By default the Rust test harness hides output from benchmark execution to keep
-results readable. Benchmark output can be recovered (e.g., for debugging) by
-passing --nocapture to the benchmark binaries:
cargo bench -- --nocapture-
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
The output format for diagnostic messages. Can be specified multiple times -and consists of comma-separated values. Valid values:
-human (default): Display in a human-readable text format.
short: Emit shorter, human-readable text messages.
json: Emit JSON messages to stdout. See
-the reference
-for more details.
json-diagnostic-short: Ensure the rendered field of JSON messages contains
-the "short" rendering from rustc.
json-diagnostic-rendered-ansi: Ensure the rendered field of JSON messages
-contains embedded ANSI color codes for respecting rustc’s default color
-scheme.
json-render-diagnostics: Instruct Cargo to not include rustc diagnostics in
-in JSON messages printed, but instead Cargo itself should render the
-JSON diagnostics coming from rustc. Cargo’s own JSON diagnostics and others
-coming from rustc are still emitted.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
The --jobs argument affects the building of the benchmark executable but
-does not affect how many threads are used when running the benchmarks. The
-Rust test harness runs benchmarks serially in a single thread.
Number of parallel jobs to run. May also be specified with the
-build.jobs config value. Defaults to
-the number of CPUs.
Profiles may be used to configure compiler options such as optimization levels -and debug settings. See -the reference -for more details.
-Benchmarks are always built with the bench profile. Binary and lib targets
-are built separately as benchmarks with the bench profile. Library targets
-are built with the release profiles when linked to binaries and benchmarks.
-Dependencies use the release profile.
If you need a debug build of a benchmark, try building it with
-cargo-build(1) which will use the test profile which is by default
-unoptimized and includes debug information. You can then run the debug-enabled
-benchmark manually.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Build and execute all the benchmarks of the current package:
-cargo bench-
Run only a specific benchmark within a specific benchmark target:
-cargo bench --bench bench_name -- modname::some_benchmark-
cargo-build - Compile the current package
-cargo build [OPTIONS]
Compile local packages and all of their dependencies.
-By default, when no package selection options are given, the packages selected
-depend on the selected manifest file (based on the current working directory if
---manifest-path is not given). If the manifest is the root of a workspace then
-the workspaces default members are selected, otherwise only the package defined
-by the manifest will be selected.
The default members of a workspace can be set explicitly with the
-workspace.default-members key in the root manifest. If this is not set, a
-virtual workspace will include all workspace members (equivalent to passing
---workspace), and a non-virtual workspace will include only the root crate itself.
Build only the specified packages. See cargo-pkgid(1) for the -SPEC format. This flag may be specified multiple times.
-Build all members in the workspace.
-Deprecated alias for --workspace.
Exclude the specified packages. Must be used in conjunction with the
---workspace flag. This flag may be specified multiple times.
When no target selection options are given, cargo build will build all
-binary and library targets of the selected packages. Binaries are skipped if
-they have required-features that are missing.
Passing target selection flags will build only the -specified targets.
-Build the package’s library.
-Build the specified binary. This flag may be specified multiple times.
-Build all binary targets.
-Build the specified example. This flag may be specified multiple times.
-Build all example targets.
-Build the specified integration test. This flag may be specified multiple -times.
-Build all targets in test mode that have the test = true manifest
-flag set. By default this includes the library and binaries built as
-unittests, and integration tests. Be aware that this will also build any
-required dependencies, so the lib target may be built twice (once as a
-unittest, and once as a dependency for binaries, integration tests, etc.).
-Targets may be enabled or disabled by setting the test flag in the
-manifest settings for the target.
Build the specified benchmark. This flag may be specified multiple times.
-Build all targets in benchmark mode that have the bench = true
-manifest flag set. By default this includes the library and binaries built
-as benchmarks, and bench targets. Be aware that this will also build any
-required dependencies, so the lib target may be built twice (once as a
-benchmark, and once as a dependency for binaries, benchmarks, etc.).
-Targets may be enabled or disabled by setting the bench flag in the
-manifest settings for the target.
Build all targets. This is equivalent to specifying --lib --bins
---tests --benches --examples.
The feature flags allow you to control the enabled features for the "current"
-package. The "current" package is the package in the current directory, or the
-one specified in --manifest-path. If running in the root of a virtual
-workspace, then the default features are selected for all workspace members,
-or all features if --all-features is specified.
When no feature options are given, the default feature is activated for
-every selected package.
Space or comma separated list of features to activate. These features only
-apply to the current directory’s package. Features of direct dependencies
-may be enabled with <dep-name>/<feature-name> syntax. This flag may be
-specified multiple times, which enables all specified features.
Activate all available features of all selected packages.
-Do not activate the default feature of the current directory’s
-package.
Build for the given architecture. The default is the host
-architecture. The general format of the triple is
-<arch><sub>-<vendor>-<sys>-<abi>. Run rustc --print target-list for a
-list of supported targets.
This may also be specified with the build.target
-config value.
Note that specifying this flag makes Cargo run in a different mode where the -target artifacts are placed in a separate directory. See the -build cache documentation for more details.
-Build optimized artifacts with the release profile. See the
-PROFILES section for details on how this affects profile selection.
Directory for all generated artifacts and intermediate files. May also be
-specified with the CARGO_TARGET_DIR environment variable, or the
-build.target-dir config value. Defaults
-to target in the root of the workspace.
Copy final artifacts to this directory.
-This option is unstable and available only on the
-nightly channel
-and requires the -Z unstable-options flag to enable.
-See https://github.com/rust-lang/cargo/issues/6790 for more information.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
The output format for diagnostic messages. Can be specified multiple times -and consists of comma-separated values. Valid values:
-human (default): Display in a human-readable text format.
short: Emit shorter, human-readable text messages.
json: Emit JSON messages to stdout. See
-the reference
-for more details.
json-diagnostic-short: Ensure the rendered field of JSON messages contains
-the "short" rendering from rustc.
json-diagnostic-rendered-ansi: Ensure the rendered field of JSON messages
-contains embedded ANSI color codes for respecting rustc’s default color
-scheme.
json-render-diagnostics: Instruct Cargo to not include rustc diagnostics in
-in JSON messages printed, but instead Cargo itself should render the
-JSON diagnostics coming from rustc. Cargo’s own JSON diagnostics and others
-coming from rustc are still emitted.
Outputs a series of JSON messages to stdout that indicate the commands to -run the build.
-This option is unstable and available only on the
-nightly channel
-and requires the -Z unstable-options flag to enable.
-See https://github.com/rust-lang/cargo/issues/5579 for more information.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
Number of parallel jobs to run. May also be specified with the
-build.jobs config value. Defaults to
-the number of CPUs.
Profiles may be used to configure compiler options such as optimization levels -and debug settings. See -the reference -for more details.
-Profile selection depends on the target and crate being built. By default the
-dev or test profiles are used. If the --release flag is given, then the
-release or bench profiles are used.
| Target | -Default Profile | ---release Profile |
-
|---|---|---|
lib, bin, example |
-
|
-
|
-
test, bench, or any target |
-
|
-
|
-
Dependencies use the dev/release profiles.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Build the local package and all of its dependencies:
-cargo build-
Build with optimizations:
-cargo build --release-
cargo-check - Check the current package
-cargo check [OPTIONS]
Check a local package and all of its dependencies for errors. This will
-essentially compile the packages without performing the final step of code
-generation, which is faster than running cargo build. The compiler will save
-metadata files to disk so that future runs will reuse them if the source has
-not been modified.
By default, when no package selection options are given, the packages selected
-depend on the selected manifest file (based on the current working directory if
---manifest-path is not given). If the manifest is the root of a workspace then
-the workspaces default members are selected, otherwise only the package defined
-by the manifest will be selected.
The default members of a workspace can be set explicitly with the
-workspace.default-members key in the root manifest. If this is not set, a
-virtual workspace will include all workspace members (equivalent to passing
---workspace), and a non-virtual workspace will include only the root crate itself.
Check only the specified packages. See cargo-pkgid(1) for the -SPEC format. This flag may be specified multiple times.
-Check all members in the workspace.
-Deprecated alias for --workspace.
Exclude the specified packages. Must be used in conjunction with the
---workspace flag. This flag may be specified multiple times.
When no target selection options are given, cargo check will check all
-binary and library targets of the selected packages. Binaries are skipped if
-they have required-features that are missing.
Passing target selection flags will check only the -specified targets.
-Check the package’s library.
-Check the specified binary. This flag may be specified multiple times.
-Check all binary targets.
-Check the specified example. This flag may be specified multiple times.
-Check all example targets.
-Check the specified integration test. This flag may be specified multiple -times.
-Check all targets in test mode that have the test = true manifest
-flag set. By default this includes the library and binaries built as
-unittests, and integration tests. Be aware that this will also build any
-required dependencies, so the lib target may be built twice (once as a
-unittest, and once as a dependency for binaries, integration tests, etc.).
-Targets may be enabled or disabled by setting the test flag in the
-manifest settings for the target.
Check the specified benchmark. This flag may be specified multiple times.
-Check all targets in benchmark mode that have the bench = true
-manifest flag set. By default this includes the library and binaries built
-as benchmarks, and bench targets. Be aware that this will also build any
-required dependencies, so the lib target may be built twice (once as a
-benchmark, and once as a dependency for binaries, benchmarks, etc.).
-Targets may be enabled or disabled by setting the bench flag in the
-manifest settings for the target.
Check all targets. This is equivalent to specifying --lib --bins
---tests --benches --examples.
The feature flags allow you to control the enabled features for the "current"
-package. The "current" package is the package in the current directory, or the
-one specified in --manifest-path. If running in the root of a virtual
-workspace, then the default features are selected for all workspace members,
-or all features if --all-features is specified.
When no feature options are given, the default feature is activated for
-every selected package.
Space or comma separated list of features to activate. These features only
-apply to the current directory’s package. Features of direct dependencies
-may be enabled with <dep-name>/<feature-name> syntax. This flag may be
-specified multiple times, which enables all specified features.
Activate all available features of all selected packages.
-Do not activate the default feature of the current directory’s
-package.
Check for the given architecture. The default is the host
-architecture. The general format of the triple is
-<arch><sub>-<vendor>-<sys>-<abi>. Run rustc --print target-list for a
-list of supported targets.
This may also be specified with the build.target
-config value.
Note that specifying this flag makes Cargo run in a different mode where the -target artifacts are placed in a separate directory. See the -build cache documentation for more details.
-Check optimized artifacts with the release profile. See the
-PROFILES section for details on how this affects profile selection.
Changes check behavior. Currently only test is
-supported, which will check with the
-#[cfg(test)] attribute enabled. This is useful to have it
-check unit tests which are usually excluded via
-the cfg attribute. This does not change the actual profile used.
Directory for all generated artifacts and intermediate files. May also be
-specified with the CARGO_TARGET_DIR environment variable, or the
-build.target-dir config value. Defaults
-to target in the root of the workspace.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
The output format for diagnostic messages. Can be specified multiple times -and consists of comma-separated values. Valid values:
-human (default): Display in a human-readable text format.
short: Emit shorter, human-readable text messages.
json: Emit JSON messages to stdout. See
-the reference
-for more details.
json-diagnostic-short: Ensure the rendered field of JSON messages contains
-the "short" rendering from rustc.
json-diagnostic-rendered-ansi: Ensure the rendered field of JSON messages
-contains embedded ANSI color codes for respecting rustc’s default color
-scheme.
json-render-diagnostics: Instruct Cargo to not include rustc diagnostics in
-in JSON messages printed, but instead Cargo itself should render the
-JSON diagnostics coming from rustc. Cargo’s own JSON diagnostics and others
-coming from rustc are still emitted.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
Number of parallel jobs to run. May also be specified with the
-build.jobs config value. Defaults to
-the number of CPUs.
Profiles may be used to configure compiler options such as optimization levels -and debug settings. See -the reference -for more details.
-Profile selection depends on the target and crate being built. By default the
-dev or test profiles are used. If the --release flag is given, then the
-release or bench profiles are used.
| Target | -Default Profile | ---release Profile |
-
|---|---|---|
lib, bin, example |
-
|
-
|
-
test, bench, or any target |
-
|
-
|
-
Dependencies use the dev/release profiles.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Check the local package for errors:
-cargo check-
Check all targets, including unit tests:
-cargo check --all-targets --profile=test-
cargo-clean - Remove generated artifacts
-cargo clean [OPTIONS]
Remove artifacts from the target directory that Cargo has generated in the -past.
-With no options, cargo clean will delete the entire target directory.
When no packages are selected, all packages and all dependencies in the -workspace are cleaned.
-Clean only the specified packages. This flag may be specified -multiple times. See cargo-pkgid(1) for the SPEC format.
-This option will cause cargo clean to remove only the doc directory in
-the target directory.
Clean all artifacts that were built with the release or bench
-profiles.
Directory for all generated artifacts and intermediate files. May also be
-specified with the CARGO_TARGET_DIR environment variable, or the
-build.target-dir config value. Defaults
-to target in the root of the workspace.
Clean for the given architecture. The default is the host
-architecture. The general format of the triple is
-<arch><sub>-<vendor>-<sys>-<abi>. Run rustc --print target-list for a
-list of supported targets.
This may also be specified with the build.target
-config value.
Note that specifying this flag makes Cargo run in a different mode where the -target artifacts are placed in a separate directory. See the -build cache documentation for more details.
-Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Remove the entire target directory:
-cargo clean-
Remove only the release artifacts:
-cargo clean --release-
cargo-doc - Build a package's documentation
-cargo doc [OPTIONS]
Build the documentation for the local package and all dependencies. The output
-is placed in target/doc in rustdoc’s usual format.
Open the docs in a browser after building them. This will use your default
-browser unless you define another one in the BROWSER environment
-variable.
Do not build documentation for dependencies.
-Include non-public items in the documentation.
-By default, when no package selection options are given, the packages selected
-depend on the selected manifest file (based on the current working directory if
---manifest-path is not given). If the manifest is the root of a workspace then
-the workspaces default members are selected, otherwise only the package defined
-by the manifest will be selected.
The default members of a workspace can be set explicitly with the
-workspace.default-members key in the root manifest. If this is not set, a
-virtual workspace will include all workspace members (equivalent to passing
---workspace), and a non-virtual workspace will include only the root crate itself.
Document only the specified packages. See cargo-pkgid(1) for the -SPEC format. This flag may be specified multiple times.
-Document all members in the workspace.
-Deprecated alias for --workspace.
Exclude the specified packages. Must be used in conjunction with the
---workspace flag. This flag may be specified multiple times.
When no target selection options are given, cargo doc will document all
-binary and library targets of the selected package. The binary will be skipped
-if its name is the same as the lib target. Binaries are skipped if they have
-required-features that are missing.
The default behavior can be changed by setting doc = false for the target in
-the manifest settings. Using target selection options will ignore the doc
-flag and will always document the given target.
Document the package’s library.
-Document the specified binary. This flag may be specified multiple times.
-Document all binary targets.
-The feature flags allow you to control the enabled features for the "current"
-package. The "current" package is the package in the current directory, or the
-one specified in --manifest-path. If running in the root of a virtual
-workspace, then the default features are selected for all workspace members,
-or all features if --all-features is specified.
When no feature options are given, the default feature is activated for
-every selected package.
Space or comma separated list of features to activate. These features only
-apply to the current directory’s package. Features of direct dependencies
-may be enabled with <dep-name>/<feature-name> syntax. This flag may be
-specified multiple times, which enables all specified features.
Activate all available features of all selected packages.
-Do not activate the default feature of the current directory’s
-package.
Document for the given architecture. The default is the host
-architecture. The general format of the triple is
-<arch><sub>-<vendor>-<sys>-<abi>. Run rustc --print target-list for a
-list of supported targets.
This may also be specified with the build.target
-config value.
Note that specifying this flag makes Cargo run in a different mode where the -target artifacts are placed in a separate directory. See the -build cache documentation for more details.
-Document optimized artifacts with the release profile. See the
-PROFILES section for details on how this affects profile selection.
Directory for all generated artifacts and intermediate files. May also be
-specified with the CARGO_TARGET_DIR environment variable, or the
-build.target-dir config value. Defaults
-to target in the root of the workspace.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
The output format for diagnostic messages. Can be specified multiple times -and consists of comma-separated values. Valid values:
-human (default): Display in a human-readable text format.
short: Emit shorter, human-readable text messages.
json: Emit JSON messages to stdout. See
-the reference
-for more details.
json-diagnostic-short: Ensure the rendered field of JSON messages contains
-the "short" rendering from rustc.
json-diagnostic-rendered-ansi: Ensure the rendered field of JSON messages
-contains embedded ANSI color codes for respecting rustc’s default color
-scheme.
json-render-diagnostics: Instruct Cargo to not include rustc diagnostics in
-in JSON messages printed, but instead Cargo itself should render the
-JSON diagnostics coming from rustc. Cargo’s own JSON diagnostics and others
-coming from rustc are still emitted.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
Number of parallel jobs to run. May also be specified with the
-build.jobs config value. Defaults to
-the number of CPUs.
Profiles may be used to configure compiler options such as optimization levels -and debug settings. See -the reference -for more details.
-Profile selection depends on the target and crate being built. By default the
-dev or test profiles are used. If the --release flag is given, then the
-release or bench profiles are used.
| Target | -Default Profile | ---release Profile |
-
|---|---|---|
lib, bin, example |
-
|
-
|
-
test, bench, or any target |
-
|
-
|
-
Dependencies use the dev/release profiles.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Build the local package documentation and its dependencies and output to
-target/doc.
cargo doc-
cargo-fetch - Fetch dependencies of a package from the network
-cargo fetch [OPTIONS]
If a Cargo.lock file is available, this command will ensure that all of the
-git dependencies and/or registry dependencies are downloaded and locally
-available. Subsequent Cargo commands never touch the network after a cargo
-fetch unless the lock file changes.
If the lock file is not available, then this command will generate the lock -file before fetching the dependencies.
-If --target is not specified, then all target dependencies are fetched.
See also the cargo-prefetch
-plugin which adds a command to download popular crates. This may be useful if
-you plan to use Cargo without a network with the --offline flag.
Fetch for the given architecture. The default is the host
-architecture. The general format of the triple is
-<arch><sub>-<vendor>-<sys>-<abi>. Run rustc --print target-list for a
-list of supported targets.
This may also be specified with the build.target
-config value.
Note that specifying this flag makes Cargo run in a different mode where the -target artifacts are placed in a separate directory. See the -build cache documentation for more details.
-Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Fetch all dependencies:
-cargo fetch-
cargo-fix - Automatically fix lint warnings reported by rustc
-cargo fix [OPTIONS]
This Cargo subcommand will automatically take rustc’s suggestions from
-diagnostics like warnings and apply them to your source code. This is intended
-to help automate tasks that rustc itself already knows how to tell you to fix!
-The cargo fix subcommand is also being developed for the Rust 2018 edition
-to provide code the ability to easily opt-in to the new edition without having
-to worry about any breakage.
Executing cargo fix will under the hood execute cargo-check(1). Any warnings
-applicable to your crate will be automatically fixed (if possible) and all
-remaining warnings will be displayed when the check process is finished. For
-example if you’d like to prepare for the 2018 edition, you can do so by
-executing:
cargo fix --edition-
which behaves the same as cargo check --all-targets.
cargo fix is only capable of fixing code that is normally compiled with
-cargo check. If code is conditionally enabled with optional features, you
-will need to enable those features for that code to be analyzed:
cargo fix --edition --features foo-
Similarly, other cfg expressions like platform-specific code will need to
-pass --target to fix code for the given target.
cargo fix --edition --target x86_64-pc-windows-gnu-
If you encounter any problems with cargo fix or otherwise have any questions
-or feature requests please don’t hesitate to file an issue at
-https://github.com/rust-lang/cargo
Fix code even if it already has compiler errors. This is useful if cargo
-fix fails to apply the changes. It will apply the changes and leave the
-broken code in the working directory for you to inspect and manually fix.
Apply changes that will update the code to the latest edition. This will
-not update the edition in the Cargo.toml manifest, which must be updated
-manually.
Apply suggestions that will update code to the preferred style for the -current edition.
-Fix code even if a VCS was not detected.
-Fix code even if the working directory has changes.
-Fix code even if the working directory has staged changes.
-By default, when no package selection options are given, the packages selected
-depend on the selected manifest file (based on the current working directory if
---manifest-path is not given). If the manifest is the root of a workspace then
-the workspaces default members are selected, otherwise only the package defined
-by the manifest will be selected.
The default members of a workspace can be set explicitly with the
-workspace.default-members key in the root manifest. If this is not set, a
-virtual workspace will include all workspace members (equivalent to passing
---workspace), and a non-virtual workspace will include only the root crate itself.
Fix only the specified packages. See cargo-pkgid(1) for the -SPEC format. This flag may be specified multiple times.
-Fix all members in the workspace.
-Deprecated alias for --workspace.
Exclude the specified packages. Must be used in conjunction with the
---workspace flag. This flag may be specified multiple times.
When no target selection options are given, cargo fix will fix all targets
-(--all-targets implied). Binaries are skipped if they have
-required-features that are missing.
Passing target selection flags will fix only the -specified targets.
-Fix the package’s library.
-Fix the specified binary. This flag may be specified multiple times.
-Fix all binary targets.
-Fix the specified example. This flag may be specified multiple times.
-Fix all example targets.
-Fix the specified integration test. This flag may be specified multiple -times.
-Fix all targets in test mode that have the test = true manifest
-flag set. By default this includes the library and binaries built as
-unittests, and integration tests. Be aware that this will also build any
-required dependencies, so the lib target may be built twice (once as a
-unittest, and once as a dependency for binaries, integration tests, etc.).
-Targets may be enabled or disabled by setting the test flag in the
-manifest settings for the target.
Fix the specified benchmark. This flag may be specified multiple times.
-Fix all targets in benchmark mode that have the bench = true
-manifest flag set. By default this includes the library and binaries built
-as benchmarks, and bench targets. Be aware that this will also build any
-required dependencies, so the lib target may be built twice (once as a
-benchmark, and once as a dependency for binaries, benchmarks, etc.).
-Targets may be enabled or disabled by setting the bench flag in the
-manifest settings for the target.
Fix all targets. This is equivalent to specifying --lib --bins
---tests --benches --examples.
The feature flags allow you to control the enabled features for the "current"
-package. The "current" package is the package in the current directory, or the
-one specified in --manifest-path. If running in the root of a virtual
-workspace, then the default features are selected for all workspace members,
-or all features if --all-features is specified.
When no feature options are given, the default feature is activated for
-every selected package.
Space or comma separated list of features to activate. These features only
-apply to the current directory’s package. Features of direct dependencies
-may be enabled with <dep-name>/<feature-name> syntax. This flag may be
-specified multiple times, which enables all specified features.
Activate all available features of all selected packages.
-Do not activate the default feature of the current directory’s
-package.
Fix for the given architecture. The default is the host
-architecture. The general format of the triple is
-<arch><sub>-<vendor>-<sys>-<abi>. Run rustc --print target-list for a
-list of supported targets.
This may also be specified with the build.target
-config value.
Note that specifying this flag makes Cargo run in a different mode where the -target artifacts are placed in a separate directory. See the -build cache documentation for more details.
-Fix optimized artifacts with the release profile. See the
-PROFILES section for details on how this affects profile selection.
Changes fix behavior. Currently only test is
-supported, which will fix with the
-#[cfg(test)] attribute enabled. This is useful to have it
-fix unit tests which are usually excluded via
-the cfg attribute. This does not change the actual profile used.
Directory for all generated artifacts and intermediate files. May also be
-specified with the CARGO_TARGET_DIR environment variable, or the
-build.target-dir config value. Defaults
-to target in the root of the workspace.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
The output format for diagnostic messages. Can be specified multiple times -and consists of comma-separated values. Valid values:
-human (default): Display in a human-readable text format.
short: Emit shorter, human-readable text messages.
json: Emit JSON messages to stdout. See
-the reference
-for more details.
json-diagnostic-short: Ensure the rendered field of JSON messages contains
-the "short" rendering from rustc.
json-diagnostic-rendered-ansi: Ensure the rendered field of JSON messages
-contains embedded ANSI color codes for respecting rustc’s default color
-scheme.
json-render-diagnostics: Instruct Cargo to not include rustc diagnostics in
-in JSON messages printed, but instead Cargo itself should render the
-JSON diagnostics coming from rustc. Cargo’s own JSON diagnostics and others
-coming from rustc are still emitted.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
Number of parallel jobs to run. May also be specified with the
-build.jobs config value. Defaults to
-the number of CPUs.
Profiles may be used to configure compiler options such as optimization levels -and debug settings. See -the reference -for more details.
-Profile selection depends on the target and crate being built. By default the
-dev or test profiles are used. If the --release flag is given, then the
-release or bench profiles are used.
| Target | -Default Profile | ---release Profile |
-
|---|---|---|
lib, bin, example |
-
|
-
|
-
test, bench, or any target |
-
|
-
|
-
Dependencies use the dev/release profiles.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Apply compiler suggestions to the local package:
-cargo fix-
Convert a 2015 edition to 2018:
-cargo fix --edition-
Apply suggested idioms for the current edition:
-cargo fix --edition-idioms-
cargo-generate-lockfile - Generate the lockfile for a package
-cargo generate-lockfile [OPTIONS]
This command will create the Cargo.lock lockfile for the current package or
-workspace. If the lockfile already exists, it will be rebuilt if there are any
-manifest changes or dependency updates.
See also cargo-update(1) which is also capable of creating a Cargo.lock
-lockfile and has more options for controlling update behavior.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Create or update the lockfile for the current package or workspace:
-cargo generate-lockfile-
cargo-help - Get help for a Cargo command
-cargo help [SUBCOMMAND]
Prints a help message for the given command.
-Get help for a command:
-cargo help build-
Help is also available with the --help flag:
cargo build --help-
cargo-init - Create a new Cargo package in an existing directory
-cargo init [OPTIONS] [PATH]
This command will create a new Cargo manifest in the current directory. Give a -path as an argument to create in the given directory.
-If there are typically-named Rust source files already in the directory, those
-will be used. If not, then a sample src/main.rs file will be created, or
-src/lib.rs if --lib is passed.
If the directory is not already in a VCS repository, then a new repository
-is created (see --vcs below).
The "authors" field in the manifest is determined from the environment or -configuration settings. A name is required and is determined from (first match -wins):
-cargo-new.name Cargo config value
CARGO_NAME environment variable
GIT_AUTHOR_NAME environment variable
GIT_COMMITTER_NAME environment variable
user.name git configuration value
USER environment variable
USERNAME environment variable
NAME environment variable
The email address is optional and is determined from:
-cargo-new.email Cargo config value
CARGO_EMAIL environment variable
GIT_AUTHOR_EMAIL environment variable
GIT_COMMITTER_EMAIL environment variable
user.email git configuration value
EMAIL environment variable
See the reference for more information about -configuration files.
-See cargo-new(1) for a similar command which will create a new package in -a new directory.
-Create a package with a binary target (src/main.rs).
-This is the default behavior.
Create a package with a library target (src/lib.rs).
Specify the Rust edition to use. Default is 2018. -Possible values: 2015, 2018
-Set the package name. Defaults to the directory name.
-Initialize a new VCS repository for the given version control system (git,
-hg, pijul, or fossil) or do not initialize any version control at all
-(none). If not specified, defaults to git or the configuration value
-cargo-new.vcs, or none if already inside a VCS repository.
This sets the publish field in Cargo.toml to the given registry name
-which will restrict publishing only to that registry.
Registry names are defined in Cargo config files.
-If not specified, the default registry defined by the registry.default
-config key is used. If the default registry is not set and --registry is not
-used, the publish field will not be set which means that publishing will not
-be restricted.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Create a binary Cargo package in the current directory:
-cargo init-
cargo-install - Build and install a Rust binary
-cargo install [OPTIONS] CRATE…
-cargo install [OPTIONS] --path PATH
-cargo install [OPTIONS] --git URL [CRATE…]
-cargo install [OPTIONS] --list
This command manages Cargo’s local set of installed binary crates. Only
-packages which have executable [[bin]] or [[example]] targets can be
-installed, and all executables are installed into the installation root’s
-bin folder.
The installation root is determined, in order of precedence:
---root option
CARGO_INSTALL_ROOT environment variable
install.root Cargo config value
CARGO_HOME environment variable
$HOME/.cargo
There are multiple sources from which a crate can be installed. The default
-location is crates.io but the --git, --path, and --registry flags can
-change this source. If the source contains more than one package (such as
-crates.io or a git repository with multiple crates) the CRATE argument is
-required to indicate which crate should be installed.
Crates from crates.io can optionally specify the version they wish to install
-via the --version flags, and similarly packages from git repositories can
-optionally specify the branch, tag, or revision that should be installed. If a
-crate has multiple binaries, the --bin argument can selectively install only
-one of them, and if you’d rather install examples the --example argument can
-be used as well.
If the package is already installed, Cargo will reinstall it if the installed -version does not appear to be up-to-date. If any of the following values -change, then Cargo will reinstall the package:
-The package version and source.
-The set of binary names installed.
-The chosen features.
-The release mode (--debug).
The target (--target).
Installing with --path will always build and install, unless there are
-conflicting binaries from another package. The --force flag may be used to
-force Cargo to always reinstall the package.
If the source is crates.io or --git then by default the crate will be built
-in a temporary target directory. To avoid this, the target directory can be
-specified by setting the CARGO_TARGET_DIR environment variable to a relative
-path. In particular, this can be useful for caching build artifacts on
-continuous integration systems.
By default, the Cargo.lock file that is included with the package will be
-ignored. This means that Cargo will recompute which versions of dependencies
-to use, possibly using newer versions that have been released since the
-package was published. The --locked flag can be used to force Cargo to use
-the packaged Cargo.lock file if it is available. This may be useful for
-ensuring reproducible builds, to use the exact same set of dependencies that
-were available when the package was published. It may also be useful if a
-newer version of a dependency is published that no longer builds on your
-system, or has other problems. The downside to using --locked is that you
-will not receive any fixes or updates to any dependency. Note that Cargo did
-not start publishing Cargo.lock files until version 1.37, which means
-packages published with prior versions will not have a Cargo.lock file
-available.
Specify a version to install. This may be a
-version requirement, like
-~1.2, to have Cargo select the newest version from the given
-requirement. If the version does not have a requirement operator (such as
-^ or ~), then it must be in the form MAJOR.MINOR.PATCH, and will
-install exactly that version; it is not treated as a caret requirement
-like Cargo dependencies are.
Git URL to install the specified crate from.
-Branch to use when installing from git.
-Tag to use when installing from git.
-Specific commit to use when installing from git.
-Filesystem path to local crate to install.
-List all installed packages and their versions.
-Force overwriting existing crates or binaries. This can be used if a
-package has installed a binary with the same name as another package. This
-is also useful if something has changed on the system that you want to
-rebuild with, such as a newer version of rustc.
By default, Cargo keeps track of the installed packages with a metadata
-file stored in the installation root directory. This flag tells Cargo not
-to use or create that file. With this flag, Cargo will refuse to overwrite
-any existing files unless the --force flag is used. This also disables
-Cargo’s ability to protect against multiple concurrent invocations of
-Cargo installing at the same time.
Install only the specified binary.
-Install all binaries.
-Install only the specified example.
-Install all examples.
-Directory to install packages into.
-Name of the registry to use. Registry names are defined in Cargo config files.
-If not specified, the default registry is used, which is defined by the
-registry.default config key which defaults to crates-io.
The URL of the registry index to use.
-The feature flags allow you to control the enabled features for the "current"
-package. The "current" package is the package in the current directory, or the
-one specified in --manifest-path. If running in the root of a virtual
-workspace, then the default features are selected for all workspace members,
-or all features if --all-features is specified.
When no feature options are given, the default feature is activated for
-every selected package.
Space or comma separated list of features to activate. These features only
-apply to the current directory’s package. Features of direct dependencies
-may be enabled with <dep-name>/<feature-name> syntax. This flag may be
-specified multiple times, which enables all specified features.
Activate all available features of all selected packages.
-Do not activate the default feature of the current directory’s
-package.
Install for the given architecture. The default is the host
-architecture. The general format of the triple is
-<arch><sub>-<vendor>-<sys>-<abi>. Run rustc --print target-list for a
-list of supported targets.
This may also be specified with the build.target
-config value.
Note that specifying this flag makes Cargo run in a different mode where the -target artifacts are placed in a separate directory. See the -build cache documentation for more details.
-Directory for all generated artifacts and intermediate files. May also be
-specified with the CARGO_TARGET_DIR environment variable, or the
-build.target-dir config value. Defaults
-to target in the root of the workspace.
Build with the dev profile instead the release profile.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
Number of parallel jobs to run. May also be specified with the
-build.jobs config value. Defaults to
-the number of CPUs.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Install or upgrade a package from crates.io:
-cargo install ripgrep-
Install or reinstall the package in the current directory:
-cargo install --path .-
View the list of installed packages:
-cargo install --list-
cargo-locate-project - Print a JSON representation of a Cargo.toml file's location
-cargo locate-project [OPTIONS]
This command will print a JSON object to stdout with the full path to the
-Cargo.toml manifest.
See also cargo-metadata(1) which is capable of returning the path to a -workspace root.
-Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Display the path to the manifest based on the current directory:
-cargo locate-project-
cargo-login - Save an API token from the registry locally
-cargo login [OPTIONS] [TOKEN]
This command will save the API token to disk so that commands that require
-authentication, such as cargo-publish(1), will be automatically
-authenticated. The token is saved in $CARGO_HOME/credentials.toml. CARGO_HOME
-defaults to .cargo in your home directory.
If the TOKEN argument is not specified, it will be read from stdin.
-The API token for crates.io may be retrieved from https://crates.io/me.
-Take care to keep the token secret, it should not be shared with anyone else.
-Name of the registry to use. Registry names are defined in Cargo config files.
-If not specified, the default registry is used, which is defined by the
-registry.default config key which defaults to crates-io.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Save the API token to disk:
-cargo login-
cargo-metadata - Machine-readable metadata about the current package
-cargo metadata [OPTIONS]
Output JSON to stdout containing information about the workspace members and -resolved dependencies of the current package.
-It is recommended to include the --format-version flag to future-proof
-your code to ensure the output is in the format you are expecting.
See the cargo_metadata crate -for a Rust API for reading the metadata.
-The output has the following format:
-{
- /* Array of all packages in the workspace.
- It also includes all feature-enabled dependencies unless --no-deps is used.
- */
- "packages": [
- {
- /* The name of the package. */
- "name": "my-package",
- /* The version of the package. */
- "version": "0.1.0",
- /* The Package ID, a unique identifier for referring to the package. */
- "id": "my-package 0.1.0 (path+file:///path/to/my-package)",
- /* The license value from the manifest, or null. */
- "license": "MIT/Apache-2.0",
- /* The license-file value from the manifest, or null. */
- "license_file": "LICENSE",
- /* The description value from the manifest, or null. */
- "description": "Package description.",
- /* The source ID of the package. This represents where
- a package is retrieved from.
- This is null for path dependencies and workspace members.
- For other dependencies, it is a string with the format:
- - "registry+URL" for registry-based dependencies.
- Example: "registry+https://github.com/rust-lang/crates.io-index"
- - "git+URL" for git-based dependencies.
- Example: "git+https://github.com/rust-lang/cargo?rev=5e85ba14aaa20f8133863373404cb0af69eeef2c#5e85ba14aaa20f8133863373404cb0af69eeef2c"
- */
- "source": null,
- /* Array of dependencies declared in the package's manifest. */
- "dependencies": [
- {
- /* The name of the dependency. */
- "name": "bitflags",
- /* The source ID of the dependency. May be null, see
- description for the package source.
- */
- "source": "registry+https://github.com/rust-lang/crates.io-index",
- /* The version requirement for the dependency.
- Dependencies without a version requirement have a value of "*".
- */
- "req": "^1.0",
- /* The dependency kind.
- "dev", "build", or null for a normal dependency.
- */
- "kind": null,
- /* If the dependency is renamed, this is the new name for
- the dependency as a string. null if it is not renamed.
- */
- "rename": null,
- /* Boolean of whether or not this is an optional dependency. */
- "optional": false,
- /* Boolean of whether or not default features are enabled. */
- "uses_default_features": true,
- /* Array of features enabled. */
- "features": [],
- /* The target platform for the dependency.
- null if not a target dependency.
- */
- "target": "cfg(windows)",
- /* A string of the URL of the registry this dependency is from.
- If not specified or null, the dependency is from the default
- registry (crates.io).
- */
- "registry": null
- }
- ],
- /* Array of Cargo targets. */
- "targets": [
- {
- /* Array of target kinds.
- - lib targets list the `crate-type` values from the
- manifest such as "lib", "rlib", "dylib",
- "proc-macro", etc. (default ["lib"])
- - binary is ["bin"]
- - example is ["example"]
- - integration test is ["test"]
- - benchmark is ["bench"]
- - build script is ["custom-build"]
- */
- "kind": [
- "bin"
- ],
- /* Array of crate types.
- - lib and example libraries list the `crate-type` values
- from the manifest such as "lib", "rlib", "dylib",
- "proc-macro", etc. (default ["lib"])
- - all other target kinds are ["bin"]
- */
- "crate_types": [
- "bin"
- ],
- /* The name of the target. */
- "name": "my-package",
- /* Absolute path to the root source file of the target. */
- "src_path": "/path/to/my-package/src/main.rs",
- /* The Rust edition of the target.
- Defaults to the package edition.
- */
- "edition": "2018",
- /* Array of required features.
- This property is not included if no required features are set.
- */
- "required-features": ["feat1"],
- /* Whether or not this target has doc tests enabled, and
- the target is compatible with doc testing.
- */
- "doctest": false,
- /* Whether or not this target should be built and run with `--test`
- */
- "test": true
- }
- ],
- /* Set of features defined for the package.
- Each feature maps to an array of features or dependencies it
- enables.
- */
- "features": {
- "default": [
- "feat1"
- ],
- "feat1": [],
- "feat2": []
- },
- /* Absolute path to this package's manifest. */
- "manifest_path": "/path/to/my-package/Cargo.toml",
- /* Package metadata.
- This is null if no metadata is specified.
- */
- "metadata": {
- "docs": {
- "rs": {
- "all-features": true
- }
- }
- },
- /* List of registries to which this package may be published.
- Publishing is unrestricted if null, and forbidden if an empty array. */
- "publish": [
- "crates-io"
- ],
- /* Array of authors from the manifest.
- Empty array if no authors specified.
- */
- "authors": [
- "Jane Doe <user@example.com>"
- ],
- /* Array of categories from the manifest. */
- "categories": [
- "command-line-utilities"
- ],
- /* Array of keywords from the manifest. */
- "keywords": [
- "cli"
- ],
- /* The readme value from the manifest or null if not specified. */
- "readme": "README.md",
- /* The repository value from the manifest or null if not specified. */
- "repository": "https://github.com/rust-lang/cargo",
- /* The default edition of the package.
- Note that individual targets may have different editions.
- */
- "edition": "2018",
- /* Optional string that is the name of a native library the package
- is linking to.
- */
- "links": null,
- }
- ],
- /* Array of members of the workspace.
- Each entry is the Package ID for the package.
- */
- "workspace_members": [
- "my-package 0.1.0 (path+file:///path/to/my-package)",
- ],
- // The resolved dependency graph for the entire workspace. The enabled
- // features are based on the enabled features for the "current" package.
- // Inactivated optional dependencies are not listed.
- //
- // This is null if --no-deps is specified.
- //
- // By default, this includes all dependencies for all target platforms.
- // The `--filter-platform` flag may be used to narrow to a specific
- // target triple.
- "resolve": {
- /* Array of nodes within the dependency graph.
- Each node is a package.
- */
- "nodes": [
- {
- /* The Package ID of this node. */
- "id": "my-package 0.1.0 (path+file:///path/to/my-package)",
- /* The dependencies of this package, an array of Package IDs. */
- "dependencies": [
- "bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)"
- ],
- /* The dependencies of this package. This is an alternative to
- "dependencies" which contains additional information. In
- particular, this handles renamed dependencies.
- */
- "deps": [
- {
- /* The name of the dependency's library target.
- If this is a renamed dependency, this is the new
- name.
- */
- "name": "bitflags",
- /* The Package ID of the dependency. */
- "pkg": "bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
- /* Array of dependency kinds. Added in Cargo 1.40. */
- "dep_kinds": [
- {
- /* The dependency kind.
- "dev", "build", or null for a normal dependency.
- */
- "kind": null,
- /* The target platform for the dependency.
- null if not a target dependency.
- */
- "target": "cfg(windows)"
- }
- ]
- }
- ],
- /* Array of features enabled on this package. */
- "features": [
- "default"
- ]
- }
- ],
- /* The root package of the workspace.
- This is null if this is a virtual workspace. Otherwise it is
- the Package ID of the root package.
- */
- "root": "my-package 0.1.0 (path+file:///path/to/my-package)"
- },
- /* The absolute path to the build directory where Cargo places its output. */
- "target_directory": "/path/to/my-package/target",
- /* The version of the schema for this metadata structure.
- This will be changed if incompatible changes are ever made.
- */
- "version": 1,
- /* The absolute path to the root of the workspace. */
- "workspace_root": "/path/to/my-package"
- /* Workspace metadata.
- This is null if no metadata is specified. */
- "metadata": {
- "docs": {
- "rs": {
- "all-features": true
- }
- }
- }
-}Output information only about the workspace members and don’t fetch -dependencies.
-Specify the version of the output format to use. Currently 1 is the only
-possible value.
This filters the resolve output to only include dependencies for the
-given target triple. Without this flag, the resolve includes all targets.
Note that the dependencies listed in the "packages" array still includes all
-dependencies. Each package definition is intended to be an unaltered
-reproduction of the information within Cargo.toml.
The feature flags allow you to control the enabled features for the "current"
-package. The "current" package is the package in the current directory, or the
-one specified in --manifest-path. If running in the root of a virtual
-workspace, then the default features are selected for all workspace members,
-or all features if --all-features is specified.
When no feature options are given, the default feature is activated for
-every selected package.
Space or comma separated list of features to activate. These features only
-apply to the current directory’s package. Features of direct dependencies
-may be enabled with <dep-name>/<feature-name> syntax. This flag may be
-specified multiple times, which enables all specified features.
Activate all available features of all selected packages.
-Do not activate the default feature of the current directory’s
-package.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Output JSON about the current package:
-cargo metadata --format-version=1-
cargo-new - Create a new Cargo package
-cargo new [OPTIONS] PATH
This command will create a new Cargo package in the given directory. This
-includes a simple template with a Cargo.toml manifest, sample source file,
-and a VCS ignore file. If the directory is not already in a VCS repository,
-then a new repository is created (see --vcs below).
The "authors" field in the manifest is determined from the environment or -configuration settings. A name is required and is determined from (first match -wins):
-cargo-new.name Cargo config value
CARGO_NAME environment variable
GIT_AUTHOR_NAME environment variable
GIT_COMMITTER_NAME environment variable
user.name git configuration value
USER environment variable
USERNAME environment variable
NAME environment variable
The email address is optional and is determined from:
-cargo-new.email Cargo config value
CARGO_EMAIL environment variable
GIT_AUTHOR_EMAIL environment variable
GIT_COMMITTER_EMAIL environment variable
user.email git configuration value
EMAIL environment variable
See the reference for more information about -configuration files.
-See cargo-init(1) for a similar command which will create a new manifest -in an existing directory.
-Create a package with a binary target (src/main.rs).
-This is the default behavior.
Create a package with a library target (src/lib.rs).
Specify the Rust edition to use. Default is 2018. -Possible values: 2015, 2018
-Set the package name. Defaults to the directory name.
-Initialize a new VCS repository for the given version control system (git,
-hg, pijul, or fossil) or do not initialize any version control at all
-(none). If not specified, defaults to git or the configuration value
-cargo-new.vcs, or none if already inside a VCS repository.
This sets the publish field in Cargo.toml to the given registry name
-which will restrict publishing only to that registry.
Registry names are defined in Cargo config files.
-If not specified, the default registry defined by the registry.default
-config key is used. If the default registry is not set and --registry is not
-used, the publish field will not be set which means that publishing will not
-be restricted.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Create a binary Cargo package in the given directory:
-cargo new foo-
cargo-owner - Manage the owners of a crate on the registry
-cargo owner [OPTIONS] --add LOGIN [CRATE]
-cargo owner [OPTIONS] --remove LOGIN [CRATE]
-cargo owner [OPTIONS] --list [CRATE]
This command will modify the owners for a crate on the registry. Owners of a -crate can upload new versions and yank old versions. Non-team owners can also -modify the set of owners, so take care!
-This command requires you to be authenticated with either the --token option
-or using cargo-login(1).
If the crate name is not specified, it will use the package name from the -current directory.
-See the reference for more -information about owners and publishing.
-Invite the given user or team as an owner.
-Remove the given user or team as an owner.
-List owners of a crate.
-API token to use when authenticating. This overrides the token stored in -the credentials file (which is created by cargo-login(1)).
-Cargo config environment variables can be
-used to override the tokens stored in the credentials file. The token for
-crates.io may be specified with the CARGO_REGISTRY_TOKEN environment
-variable. Tokens for other registries may be specified with environment
-variables of the form CARGO_REGISTRIES_NAME_TOKEN where NAME is the name
-of the registry in all capital letters.
The URL of the registry index to use.
-Name of the registry to use. Registry names are defined in Cargo config files.
-If not specified, the default registry is used, which is defined by the
-registry.default config key which defaults to crates-io.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-List owners of a package:
-cargo owner --list foo-
Invite an owner to a package:
-cargo owner --add username foo-
Remove an owner from a package:
-cargo owner --remove username foo-
cargo-package - Assemble the local package into a distributable tarball
-cargo package [OPTIONS]
This command will create a distributable, compressed .crate file with the
-source code of the package in the current directory. The resulting file will
-be stored in the target/package directory. This performs the following
-steps:
Load and check the current workspace, performing some basic checks.
-Path dependencies are not allowed unless they have a version key. Cargo
-will ignore the path key for dependencies in published packages.
-dev-dependencies do not have this restriction.
Create the compressed .crate file.
The original Cargo.toml file is rewritten and normalized.
[patch], [replace], and [workspace] sections are removed from the
-manifest.
Cargo.lock is automatically included if the package contains an
-executable binary or example target. cargo-install(1) will use the
-packaged lock file if the --locked flag is used.
A .cargo_vcs_info.json file is included that contains information
-about the current VCS checkout hash if available (not included with
---allow-dirty).
Extract the .crate file and build it to verify it can build.
This will rebuild your package from scratch to ensure that it can be
-built from a pristine state. The --no-verify flag can be used to skip
-this step.
Check that build scripts did not modify any source files.
-The list of files included can be controlled with the include and exclude
-fields in the manifest.
See the reference for more details about -packaging and publishing.
-Print files included in a package without making one.
-Don’t verify the contents by building them.
-Ignore warnings about a lack of human-usable metadata (such as the -description or the license).
-Allow working directories with uncommitted VCS changes to be packaged.
-Package for the given architecture. The default is the host
-architecture. The general format of the triple is
-<arch><sub>-<vendor>-<sys>-<abi>. Run rustc --print target-list for a
-list of supported targets.
This may also be specified with the build.target
-config value.
Note that specifying this flag makes Cargo run in a different mode where the -target artifacts are placed in a separate directory. See the -build cache documentation for more details.
-Directory for all generated artifacts and intermediate files. May also be
-specified with the CARGO_TARGET_DIR environment variable, or the
-build.target-dir config value. Defaults
-to target in the root of the workspace.
The feature flags allow you to control the enabled features for the "current"
-package. The "current" package is the package in the current directory, or the
-one specified in --manifest-path. If running in the root of a virtual
-workspace, then the default features are selected for all workspace members,
-or all features if --all-features is specified.
When no feature options are given, the default feature is activated for
-every selected package.
Space or comma separated list of features to activate. These features only
-apply to the current directory’s package. Features of direct dependencies
-may be enabled with <dep-name>/<feature-name> syntax. This flag may be
-specified multiple times, which enables all specified features.
Activate all available features of all selected packages.
-Do not activate the default feature of the current directory’s
-package.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
Number of parallel jobs to run. May also be specified with the
-build.jobs config value. Defaults to
-the number of CPUs.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Create a compressed .crate file of the current package:
cargo package-
cargo-pkgid - Print a fully qualified package specification
-cargo pkgid [OPTIONS] [SPEC]
Given a SPEC argument, print out the fully qualified package ID specifier -for a package or dependency in the current workspace. This command will -generate an error if SPEC is ambiguous as to which package it refers to in -the dependency graph. If no SPEC is given, then the specifier for the local -package is printed.
-This command requires that a lockfile is available and dependencies have been -fetched.
-A package specifier consists of a name, version, and source URL. You are -allowed to use partial specifiers to succinctly match a specific package as -long as it matches only one package. The format of a SPEC can be one of the -following:
-| SPEC Structure | -Example SPEC | -
|---|---|
NAME |
-
|
-
NAME |
-
|
-
URL |
-- |
URL |
-- |
URL |
-- |
URL |
-- |
Get the package ID for the given package instead of the current package.
-Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Retrieve package specification for foo package:
cargo pkgid foo-
Retrieve package specification for version 1.0.0 of foo:
cargo pkgid foo:1.0.0-
Retrieve package specification for foo from crates.io:
cargo pkgid https://github.com/rust-lang/crates.io-index#foo-
cargo-publish - Upload a package to the registry
-cargo publish [OPTIONS]
This command will create a distributable, compressed .crate file with the
-source code of the package in the current directory and upload it to a
-registry. The default registry is https://crates.io. This performs the
-following steps:
Performs a few checks, including:
-Checks the package.publish key in the manifest for restrictions on which
-registries you are allowed to publish to.
Create a .crate file by following the steps in cargo-package(1).
Upload the crate to the registry. Note that the server will perform -additional checks on the crate.
-This command requires you to be authenticated with either the --token option
-or using cargo-login(1).
See the reference for more details about -packaging and publishing.
-Perform all checks without uploading.
-API token to use when authenticating. This overrides the token stored in -the credentials file (which is created by cargo-login(1)).
-Cargo config environment variables can be
-used to override the tokens stored in the credentials file. The token for
-crates.io may be specified with the CARGO_REGISTRY_TOKEN environment
-variable. Tokens for other registries may be specified with environment
-variables of the form CARGO_REGISTRIES_NAME_TOKEN where NAME is the name
-of the registry in all capital letters.
Don’t verify the contents by building them.
-Allow working directories with uncommitted VCS changes to be packaged.
-The URL of the registry index to use.
-Name of the registry to use. Registry names are defined in Cargo config files.
-If not specified, the default registry is used, which is defined by the
-registry.default config key which defaults to crates-io.
Publish for the given architecture. The default is the host
-architecture. The general format of the triple is
-<arch><sub>-<vendor>-<sys>-<abi>. Run rustc --print target-list for a
-list of supported targets.
This may also be specified with the build.target
-config value.
Note that specifying this flag makes Cargo run in a different mode where the -target artifacts are placed in a separate directory. See the -build cache documentation for more details.
-Directory for all generated artifacts and intermediate files. May also be
-specified with the CARGO_TARGET_DIR environment variable, or the
-build.target-dir config value. Defaults
-to target in the root of the workspace.
The feature flags allow you to control the enabled features for the "current"
-package. The "current" package is the package in the current directory, or the
-one specified in --manifest-path. If running in the root of a virtual
-workspace, then the default features are selected for all workspace members,
-or all features if --all-features is specified.
When no feature options are given, the default feature is activated for
-every selected package.
Space or comma separated list of features to activate. These features only
-apply to the current directory’s package. Features of direct dependencies
-may be enabled with <dep-name>/<feature-name> syntax. This flag may be
-specified multiple times, which enables all specified features.
Activate all available features of all selected packages.
-Do not activate the default feature of the current directory’s
-package.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
Number of parallel jobs to run. May also be specified with the
-build.jobs config value. Defaults to
-the number of CPUs.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Publish the current package:
-cargo publish-
cargo-run - Run the current package
-cargo run [OPTIONS] [-- ARGS]
Run a binary or example of the local package.
-All the arguments following the two dashes (--) are passed to the binary to
-run. If you’re passing arguments to both Cargo and the binary, the ones after
--- go to the binary, the ones before go to Cargo.
By default, the package in the current working directory is selected. The -p
-flag can be used to choose a different package in a workspace.
The package to run. See cargo-pkgid(1) for -the SPEC format.
-When no target selection options are given, cargo run will run the binary
-target. If there are multiple binary targets, you must pass a target flag to
-choose one. Or, the default-run field may be specified in the [package]
-section of Cargo.toml to choose the name of the binary to run by default.
Run the specified binary.
-Run the specified example.
-The feature flags allow you to control the enabled features for the "current"
-package. The "current" package is the package in the current directory, or the
-one specified in --manifest-path. If running in the root of a virtual
-workspace, then the default features are selected for all workspace members,
-or all features if --all-features is specified.
When no feature options are given, the default feature is activated for
-every selected package.
Space or comma separated list of features to activate. These features only
-apply to the current directory’s package. Features of direct dependencies
-may be enabled with <dep-name>/<feature-name> syntax. This flag may be
-specified multiple times, which enables all specified features.
Activate all available features of all selected packages.
-Do not activate the default feature of the current directory’s
-package.
Run for the given architecture. The default is the host
-architecture. The general format of the triple is
-<arch><sub>-<vendor>-<sys>-<abi>. Run rustc --print target-list for a
-list of supported targets.
This may also be specified with the build.target
-config value.
Note that specifying this flag makes Cargo run in a different mode where the -target artifacts are placed in a separate directory. See the -build cache documentation for more details.
-Run optimized artifacts with the release profile. See the
-PROFILES section for details on how this affects profile selection.
Directory for all generated artifacts and intermediate files. May also be
-specified with the CARGO_TARGET_DIR environment variable, or the
-build.target-dir config value. Defaults
-to target in the root of the workspace.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
The output format for diagnostic messages. Can be specified multiple times -and consists of comma-separated values. Valid values:
-human (default): Display in a human-readable text format.
short: Emit shorter, human-readable text messages.
json: Emit JSON messages to stdout. See
-the reference
-for more details.
json-diagnostic-short: Ensure the rendered field of JSON messages contains
-the "short" rendering from rustc.
json-diagnostic-rendered-ansi: Ensure the rendered field of JSON messages
-contains embedded ANSI color codes for respecting rustc’s default color
-scheme.
json-render-diagnostics: Instruct Cargo to not include rustc diagnostics in
-in JSON messages printed, but instead Cargo itself should render the
-JSON diagnostics coming from rustc. Cargo’s own JSON diagnostics and others
-coming from rustc are still emitted.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
Number of parallel jobs to run. May also be specified with the
-build.jobs config value. Defaults to
-the number of CPUs.
Profiles may be used to configure compiler options such as optimization levels -and debug settings. See -the reference -for more details.
-Profile selection depends on the target and crate being built. By default the
-dev or test profiles are used. If the --release flag is given, then the
-release or bench profiles are used.
| Target | -Default Profile | ---release Profile |
-
|---|---|---|
lib, bin, example |
-
|
-
|
-
test, bench, or any target |
-
|
-
|
-
Dependencies use the dev/release profiles.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Build the local package and run its main target (assuming only one binary):
-cargo run-
Run an example with extra arguments:
-cargo run --example exname -- --exoption exarg1 exarg2-
cargo-rustc - Compile the current package, and pass extra options to the compiler
-cargo rustc [OPTIONS] [-- ARGS]
The specified target for the current package (or package specified by -p if
-provided) will be compiled along with all of its dependencies. The specified
-ARGS will all be passed to the final compiler invocation, not any of the
-dependencies. Note that the compiler will still unconditionally receive
-arguments such as -L, --extern, and --crate-type, and the specified
-ARGS will simply be added to the compiler invocation.
See https://doc.rust-lang.org/rustc/index.html for documentation on rustc -flags.
-This command requires that only one target is being compiled when additional
-arguments are provided. If more than one target is available for the current
-package the filters of --lib, --bin, etc, must be used to select which
-target is compiled.
-To pass flags to all compiler processes spawned by Cargo, use the RUSTFLAGS
-environment variable or the
-build.rustflags config value.
By default, the package in the current working directory is selected. The -p
-flag can be used to choose a different package in a workspace.
The package to build. See cargo-pkgid(1) for -the SPEC format.
-When no target selection options are given, cargo rustc will build all
-binary and library targets of the selected package.
Passing target selection flags will build only the -specified targets.
-Build the package’s library.
-Build the specified binary. This flag may be specified multiple times.
-Build all binary targets.
-Build the specified example. This flag may be specified multiple times.
-Build all example targets.
-Build the specified integration test. This flag may be specified multiple -times.
-Build all targets in test mode that have the test = true manifest
-flag set. By default this includes the library and binaries built as
-unittests, and integration tests. Be aware that this will also build any
-required dependencies, so the lib target may be built twice (once as a
-unittest, and once as a dependency for binaries, integration tests, etc.).
-Targets may be enabled or disabled by setting the test flag in the
-manifest settings for the target.
Build the specified benchmark. This flag may be specified multiple times.
-Build all targets in benchmark mode that have the bench = true
-manifest flag set. By default this includes the library and binaries built
-as benchmarks, and bench targets. Be aware that this will also build any
-required dependencies, so the lib target may be built twice (once as a
-benchmark, and once as a dependency for binaries, benchmarks, etc.).
-Targets may be enabled or disabled by setting the bench flag in the
-manifest settings for the target.
Build all targets. This is equivalent to specifying --lib --bins
---tests --benches --examples.
The feature flags allow you to control the enabled features for the "current"
-package. The "current" package is the package in the current directory, or the
-one specified in --manifest-path. If running in the root of a virtual
-workspace, then the default features are selected for all workspace members,
-or all features if --all-features is specified.
When no feature options are given, the default feature is activated for
-every selected package.
Space or comma separated list of features to activate. These features only
-apply to the current directory’s package. Features of direct dependencies
-may be enabled with <dep-name>/<feature-name> syntax. This flag may be
-specified multiple times, which enables all specified features.
Activate all available features of all selected packages.
-Do not activate the default feature of the current directory’s
-package.
Build for the given architecture. The default is the host
-architecture. The general format of the triple is
-<arch><sub>-<vendor>-<sys>-<abi>. Run rustc --print target-list for a
-list of supported targets.
This may also be specified with the build.target
-config value.
Note that specifying this flag makes Cargo run in a different mode where the -target artifacts are placed in a separate directory. See the -build cache documentation for more details.
-Build optimized artifacts with the release profile. See the
-PROFILES section for details on how this affects profile selection.
Directory for all generated artifacts and intermediate files. May also be
-specified with the CARGO_TARGET_DIR environment variable, or the
-build.target-dir config value. Defaults
-to target in the root of the workspace.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
The output format for diagnostic messages. Can be specified multiple times -and consists of comma-separated values. Valid values:
-human (default): Display in a human-readable text format.
short: Emit shorter, human-readable text messages.
json: Emit JSON messages to stdout. See
-the reference
-for more details.
json-diagnostic-short: Ensure the rendered field of JSON messages contains
-the "short" rendering from rustc.
json-diagnostic-rendered-ansi: Ensure the rendered field of JSON messages
-contains embedded ANSI color codes for respecting rustc’s default color
-scheme.
json-render-diagnostics: Instruct Cargo to not include rustc diagnostics in
-in JSON messages printed, but instead Cargo itself should render the
-JSON diagnostics coming from rustc. Cargo’s own JSON diagnostics and others
-coming from rustc are still emitted.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
Number of parallel jobs to run. May also be specified with the
-build.jobs config value. Defaults to
-the number of CPUs.
Profiles may be used to configure compiler options such as optimization levels -and debug settings. See -the reference -for more details.
-Profile selection depends on the target and crate being built. By default the
-dev or test profiles are used. If the --release flag is given, then the
-release or bench profiles are used.
| Target | -Default Profile | ---release Profile |
-
|---|---|---|
lib, bin, example |
-
|
-
|
-
test, bench, or any target |
-
|
-
|
-
Dependencies use the dev/release profiles.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Check if your package (not including dependencies) uses unsafe code:
-cargo rustc --lib -- -D unsafe-code-
Try an experimental flag on the nightly compiler, such as this which prints -the size of every type:
-cargo rustc --lib -- -Z print-type-sizes-
cargo-rustdoc - Build a package's documentation, using specified custom flags
-cargo rustdoc [OPTIONS] [-- ARGS]
The specified target for the current package (or package specified by -p if
-provided) will be documented with the specified ARGS being passed to the
-final rustdoc invocation. Dependencies will not be documented as part of this
-command. Note that rustdoc will still unconditionally receive arguments such
-as -L, --extern, and --crate-type, and the specified ARGS will simply
-be added to the rustdoc invocation.
See https://doc.rust-lang.org/rustdoc/index.html for documentation on rustdoc -flags.
-This command requires that only one target is being compiled when additional
-arguments are provided. If more than one target is available for the current
-package the filters of --lib, --bin, etc, must be used to select which
-target is compiled.
-To pass flags to all rustdoc processes spawned by Cargo, use the
-RUSTDOCFLAGS environment variable
-or the build.rustdocflags config value.
Open the docs in a browser after building them. This will use your default
-browser unless you define another one in the BROWSER environment
-variable.
By default, the package in the current working directory is selected. The -p
-flag can be used to choose a different package in a workspace.
The package to document. See cargo-pkgid(1) for -the SPEC format.
-When no target selection options are given, cargo rustdoc will document all
-binary and library targets of the selected package. The binary will be skipped
-if its name is the same as the lib target. Binaries are skipped if they have
-required-features that are missing.
Passing target selection flags will document only the -specified targets.
-Document the package’s library.
-Document the specified binary. This flag may be specified multiple times.
-Document all binary targets.
-Document the specified example. This flag may be specified multiple times.
-Document all example targets.
-Document the specified integration test. This flag may be specified multiple -times.
-Document all targets in test mode that have the test = true manifest
-flag set. By default this includes the library and binaries built as
-unittests, and integration tests. Be aware that this will also build any
-required dependencies, so the lib target may be built twice (once as a
-unittest, and once as a dependency for binaries, integration tests, etc.).
-Targets may be enabled or disabled by setting the test flag in the
-manifest settings for the target.
Document the specified benchmark. This flag may be specified multiple times.
-Document all targets in benchmark mode that have the bench = true
-manifest flag set. By default this includes the library and binaries built
-as benchmarks, and bench targets. Be aware that this will also build any
-required dependencies, so the lib target may be built twice (once as a
-benchmark, and once as a dependency for binaries, benchmarks, etc.).
-Targets may be enabled or disabled by setting the bench flag in the
-manifest settings for the target.
Document all targets. This is equivalent to specifying --lib --bins
---tests --benches --examples.
The feature flags allow you to control the enabled features for the "current"
-package. The "current" package is the package in the current directory, or the
-one specified in --manifest-path. If running in the root of a virtual
-workspace, then the default features are selected for all workspace members,
-or all features if --all-features is specified.
When no feature options are given, the default feature is activated for
-every selected package.
Space or comma separated list of features to activate. These features only
-apply to the current directory’s package. Features of direct dependencies
-may be enabled with <dep-name>/<feature-name> syntax. This flag may be
-specified multiple times, which enables all specified features.
Activate all available features of all selected packages.
-Do not activate the default feature of the current directory’s
-package.
Document for the given architecture. The default is the host
-architecture. The general format of the triple is
-<arch><sub>-<vendor>-<sys>-<abi>. Run rustc --print target-list for a
-list of supported targets.
This may also be specified with the build.target
-config value.
Note that specifying this flag makes Cargo run in a different mode where the -target artifacts are placed in a separate directory. See the -build cache documentation for more details.
-Document optimized artifacts with the release profile. See the
-PROFILES section for details on how this affects profile selection.
Directory for all generated artifacts and intermediate files. May also be
-specified with the CARGO_TARGET_DIR environment variable, or the
-build.target-dir config value. Defaults
-to target in the root of the workspace.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
The output format for diagnostic messages. Can be specified multiple times -and consists of comma-separated values. Valid values:
-human (default): Display in a human-readable text format.
short: Emit shorter, human-readable text messages.
json: Emit JSON messages to stdout. See
-the reference
-for more details.
json-diagnostic-short: Ensure the rendered field of JSON messages contains
-the "short" rendering from rustc.
json-diagnostic-rendered-ansi: Ensure the rendered field of JSON messages
-contains embedded ANSI color codes for respecting rustc’s default color
-scheme.
json-render-diagnostics: Instruct Cargo to not include rustc diagnostics in
-in JSON messages printed, but instead Cargo itself should render the
-JSON diagnostics coming from rustc. Cargo’s own JSON diagnostics and others
-coming from rustc are still emitted.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
Number of parallel jobs to run. May also be specified with the
-build.jobs config value. Defaults to
-the number of CPUs.
Profiles may be used to configure compiler options such as optimization levels -and debug settings. See -the reference -for more details.
-Profile selection depends on the target and crate being built. By default the
-dev or test profiles are used. If the --release flag is given, then the
-release or bench profiles are used.
| Target | -Default Profile | ---release Profile |
-
|---|---|---|
lib, bin, example |
-
|
-
|
-
test, bench, or any target |
-
|
-
|
-
Dependencies use the dev/release profiles.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Build documentation with custom CSS included from a given file:
-cargo rustdoc --lib -- --extend-css extra.css-
cargo-search - Search packages in crates.io
-cargo search [OPTIONS] [QUERY…]
This performs a textual search for crates on https://crates.io. The matching
-crates will be displayed along with their description in TOML format suitable
-for copying into a Cargo.toml manifest.
Limit the number of results (default: 10, max: 100).
-The URL of the registry index to use.
-Name of the registry to use. Registry names are defined in Cargo config files.
-If not specified, the default registry is used, which is defined by the
-registry.default config key which defaults to crates-io.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Search for a package from crates.io:
-cargo search serde-
cargo-test - Execute unit and integration tests of a package
-cargo test [OPTIONS] [TESTNAME] [-- TEST-OPTIONS]
Compile and execute unit and integration tests.
-The test filtering argument TESTNAME and all the arguments following the two
-dashes (--) are passed to the test binaries and thus to libtest (rustc’s
-built in unit-test and micro-benchmarking framework). If you’re passing
-arguments to both Cargo and the binary, the ones after -- go to the binary,
-the ones before go to Cargo. For details about libtest’s arguments see the
-output of cargo test -- --help.
As an example, this will filter for tests with foo in their name and run them
-on 3 threads in parallel:
cargo test foo -- --test-threads 3-
Tests are built with the --test option to rustc which creates an
-executable with a main function that automatically runs all functions
-annotated with the #[test] attribute in multiple threads. #[bench]
-annotated functions will also be run with one iteration to verify that they
-are functional.
The libtest harness may be disabled by setting harness = false in the target
-manifest settings, in which case your code will need to provide its own main
-function to handle running tests.
Documentation tests are also run by default, which is handled by rustdoc. It
-extracts code samples from documentation comments and executes them. See the
-rustdoc book for more information on
-writing doc tests.
Compile, but don’t run tests.
-Run all tests regardless of failure. Without this flag, Cargo will exit -after the first executable fails. The Rust test harness will run all -tests within the executable to completion, this flag only applies to -the executable as a whole.
-By default, when no package selection options are given, the packages selected
-depend on the selected manifest file (based on the current working directory if
---manifest-path is not given). If the manifest is the root of a workspace then
-the workspaces default members are selected, otherwise only the package defined
-by the manifest will be selected.
The default members of a workspace can be set explicitly with the
-workspace.default-members key in the root manifest. If this is not set, a
-virtual workspace will include all workspace members (equivalent to passing
---workspace), and a non-virtual workspace will include only the root crate itself.
Test only the specified packages. See cargo-pkgid(1) for the -SPEC format. This flag may be specified multiple times.
-Test all members in the workspace.
-Deprecated alias for --workspace.
Exclude the specified packages. Must be used in conjunction with the
---workspace flag. This flag may be specified multiple times.
When no target selection options are given, cargo test will build the
-following targets of the selected packages:
lib — used to link with binaries, examples, integration tests, and doc tests
-bins (only if integration tests are built and required features are -available)
-examples — to ensure they compile
-lib as a unit test
-bins as unit tests
-integration tests
-doc tests for the lib target
-The default behavior can be changed by setting the test flag for the target
-in the manifest settings. Setting examples to test = true will build and run
-the example as a test. Setting targets to test = false will stop them from
-being tested by default. Target selection options that take a target by name
-ignore the test flag and will always test the given target.
Doc tests for libraries may be disabled by setting doctest = false for the
-library in the manifest.
Binary targets are automatically built if there is an integration test or
-benchmark. This allows an integration test to execute the binary to exercise
-and test its behavior. The CARGO_BIN_EXE_<name>
-environment variable
-is set when the integration test is built so that it can use the
-env macro to locate the
-executable.
Passing target selection flags will test only the -specified targets.
-Test the package’s library.
-Test the specified binary. This flag may be specified multiple times.
-Test all binary targets.
-Test the specified example. This flag may be specified multiple times.
-Test all example targets.
-Test the specified integration test. This flag may be specified multiple -times.
-Test all targets in test mode that have the test = true manifest
-flag set. By default this includes the library and binaries built as
-unittests, and integration tests. Be aware that this will also build any
-required dependencies, so the lib target may be built twice (once as a
-unittest, and once as a dependency for binaries, integration tests, etc.).
-Targets may be enabled or disabled by setting the test flag in the
-manifest settings for the target.
Test the specified benchmark. This flag may be specified multiple times.
-Test all targets in benchmark mode that have the bench = true
-manifest flag set. By default this includes the library and binaries built
-as benchmarks, and bench targets. Be aware that this will also build any
-required dependencies, so the lib target may be built twice (once as a
-benchmark, and once as a dependency for binaries, benchmarks, etc.).
-Targets may be enabled or disabled by setting the bench flag in the
-manifest settings for the target.
Test all targets. This is equivalent to specifying --lib --bins
---tests --benches --examples.
Test only the library’s documentation. This cannot be mixed with other -target options.
-The feature flags allow you to control the enabled features for the "current"
-package. The "current" package is the package in the current directory, or the
-one specified in --manifest-path. If running in the root of a virtual
-workspace, then the default features are selected for all workspace members,
-or all features if --all-features is specified.
When no feature options are given, the default feature is activated for
-every selected package.
Space or comma separated list of features to activate. These features only
-apply to the current directory’s package. Features of direct dependencies
-may be enabled with <dep-name>/<feature-name> syntax. This flag may be
-specified multiple times, which enables all specified features.
Activate all available features of all selected packages.
-Do not activate the default feature of the current directory’s
-package.
Test for the given architecture. The default is the host
-architecture. The general format of the triple is
-<arch><sub>-<vendor>-<sys>-<abi>. Run rustc --print target-list for a
-list of supported targets.
This may also be specified with the build.target
-config value.
Note that specifying this flag makes Cargo run in a different mode where the -target artifacts are placed in a separate directory. See the -build cache documentation for more details.
-Test optimized artifacts with the release profile. See the
-PROFILES section for details on how this affects profile selection.
Directory for all generated artifacts and intermediate files. May also be
-specified with the CARGO_TARGET_DIR environment variable, or the
-build.target-dir config value. Defaults
-to target in the root of the workspace.
By default the Rust test harness hides output from test execution to keep
-results readable. Test output can be recovered (e.g., for debugging) by passing
---nocapture to the test binaries:
cargo test -- --nocapture-
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
The output format for diagnostic messages. Can be specified multiple times -and consists of comma-separated values. Valid values:
-human (default): Display in a human-readable text format.
short: Emit shorter, human-readable text messages.
json: Emit JSON messages to stdout. See
-the reference
-for more details.
json-diagnostic-short: Ensure the rendered field of JSON messages contains
-the "short" rendering from rustc.
json-diagnostic-rendered-ansi: Ensure the rendered field of JSON messages
-contains embedded ANSI color codes for respecting rustc’s default color
-scheme.
json-render-diagnostics: Instruct Cargo to not include rustc diagnostics in
-in JSON messages printed, but instead Cargo itself should render the
-JSON diagnostics coming from rustc. Cargo’s own JSON diagnostics and others
-coming from rustc are still emitted.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
The --jobs argument affects the building of the test executable but does not
-affect how many threads are used when running the tests. The Rust test harness
-includes an option to control the number of threads used:
cargo test -j 2 -- --test-threads=2-
Number of parallel jobs to run. May also be specified with the
-build.jobs config value. Defaults to
-the number of CPUs.
Profiles may be used to configure compiler options such as optimization levels -and debug settings. See -the reference -for more details.
-Profile selection depends on the target and crate being built. By default the
-dev or test profiles are used. If the --release flag is given, then the
-release or bench profiles are used.
| Target | -Default Profile | ---release Profile |
-
|---|---|---|
lib, bin, example |
-
|
-
|
-
test, bench, or any target |
-
|
-
|
-
Dependencies use the dev/release profiles.
Unit tests are separate executable artifacts which use the test/bench
-profiles. Example targets are built the same as with cargo build (using the
-dev/release profiles) unless you are building them with the test harness
-(by setting test = true in the manifest or using the --example flag) in
-which case they use the test/bench profiles. Library targets are built
-with the dev/release profiles when linked to an integration test, binary,
-or doctest.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Execute all the unit and integration tests of the current package:
-cargo test-
Run only tests whose names match against a filter string:
-cargo test name_filter-
Run only a specific test within a specific integration test:
-cargo test --test int_test_name -- modname::test_name-
cargo-tree - Display a tree visualization of a dependency graph
-cargo tree [OPTIONS]
This command will display a tree of dependencies to the terminal. An example -of a simple project that depends on the "rand" package:
-myproject v0.1.0 (/myproject) -└── rand v0.7.3 - ├── getrandom v0.1.14 - │ ├── cfg-if v0.1.10 - │ └── libc v0.2.68 - ├── libc v0.2.68 (*) - ├── rand_chacha v0.2.2 - │ ├── ppv-lite86 v0.2.6 - │ └── rand_core v0.5.1 - │ └── getrandom v0.1.14 (*) - └── rand_core v0.5.1 (*) -[build-dependencies] -└── cc v1.0.50-
Packages marked with (*) have been "de-duplicated". The dependencies for the
-package have already been shown elswhere in the graph, and so are not
-repeated. Use the --no-dedupe option to repeat the duplicates.
The -e flag can be used to select the dependency kinds to display. The
-"features" kind changes the output to display the features enabled by
-each dependency. For example, cargo tree -e features:
myproject v0.1.0 (/myproject) -└── log feature "serde" - └── log v0.4.8 - ├── serde v1.0.106 - └── cfg-if feature "default" - └── cfg-if v0.1.10-
In this tree, myproject depends on log with the serde feature. log in
-turn depends on cfg-if with "default" features. When using -e features it
-can be helpful to use -i flag to show how the features flow into a package.
-See the examples below for more detail.
Show the reverse dependencies for the given package. This flag will invert -the tree and display the packages that depend on the given package.
-Note that in a workspace, by default it will only display the package’s
-reverse dependencies inside the tree of the workspace member in the current
-directory. The --workspace flag can be used to extend it so that it will
-show the package’s reverse dependencies across the entire workspace. The -p
-flag can be used to display the package’s reverse dependencies only with the
-subtree of the package given to -p.
Do not de-duplicate repeated dependencies. Usually, when a package has
-already displayed its dependencies, further occurrences will not
-re-display its dependencies, and will include a (*) to indicate it has
-already been shown. This flag will cause those duplicates to be repeated.
Show only dependencies which come in multiple versions (implies
---invert). When used with the -p flag, only shows duplicates within
-the subtree of the given package.
It can be beneficial for build times and executable sizes to avoid building -that same package multiple times. This flag can help identify the offending -packages. You can then investigate if the package that depends on the -duplicate with the older version can be updated to the newer version so that -only one instance is built.
-The dependency kinds to display. Takes a comma separated list of values:
-all — Show all edge kinds.
normal — Show normal dependencies.
build — Show build dependencies.
dev — Show development dependencies.
features — Show features enabled by each dependency. If this is
-the only kind given, then it will automatically include the other
-dependency kinds.
no-normal — Do not include normal dependencies.
no-build — Do not include build dependencies.
no-dev — Do not include development dependencies.
The no- prefixed options cannot be mixed with the other dependency kinds.
The default is normal,build,dev.
Filter dependencies matching the given target-triple.
-The default is the host platform. Use the value all to include all
-targets.
Chooses the character set to use for the tree. Valid values are "utf8" or -"ascii". Default is "utf8".
-Set the format string for each package. The default is "{p}".
-This is an arbitrary string which will be used to display each package. The following -strings will be replaced with the corresponding value:
-{p} — The package name.
{l} — The package license.
{r} — The package repository URL.
{f} — Comma-separated list of package features that are enabled.
Sets how each line is displayed. The PREFIX value can be one of:
-indent (default) — Shows each line indented as a tree.
depth — Show as a list, with the numeric depth printed before each entry.
none — Show as a flat list.
By default, when no package selection options are given, the packages selected
-depend on the selected manifest file (based on the current working directory if
---manifest-path is not given). If the manifest is the root of a workspace then
-the workspaces default members are selected, otherwise only the package defined
-by the manifest will be selected.
The default members of a workspace can be set explicitly with the
-workspace.default-members key in the root manifest. If this is not set, a
-virtual workspace will include all workspace members (equivalent to passing
---workspace), and a non-virtual workspace will include only the root crate itself.
Display only the specified packages. See cargo-pkgid(1) for the -SPEC format. This flag may be specified multiple times.
-Display all members in the workspace.
-Exclude the specified packages. Must be used in conjunction with the
---workspace flag. This flag may be specified multiple times.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
The feature flags allow you to control the enabled features for the "current"
-package. The "current" package is the package in the current directory, or the
-one specified in --manifest-path. If running in the root of a virtual
-workspace, then the default features are selected for all workspace members,
-or all features if --all-features is specified.
When no feature options are given, the default feature is activated for
-every selected package.
Space or comma separated list of features to activate. These features only
-apply to the current directory’s package. Features of direct dependencies
-may be enabled with <dep-name>/<feature-name> syntax. This flag may be
-specified multiple times, which enables all specified features.
Activate all available features of all selected packages.
-Do not activate the default feature of the current directory’s
-package.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Display the tree for the package in the current directory:
-cargo tree-
Display all the packages that depend on the syn package:
cargo tree -i syn-
Show the features enabled on each package:
-cargo tree --format "{p} {f}"
-Show all packages that are built multiple times. This can happen if multiple -semver-incompatible versions appear in the tree (like 1.0.0 and 2.0.0).
-cargo tree -d-
Explain why features are enabled for the syn package:
cargo tree -e features -i syn-
The -e features flag is used to show features. The -i flag is used to
-invert the graph so that it displays the packages that depend on syn. An
-example of what this would display:
syn v1.0.17 -├── syn feature "clone-impls" -│ └── syn feature "default" -│ └── rustversion v1.0.2 -│ └── rustversion feature "default" -│ └── myproject v0.1.0 (/myproject) -│ └── myproject feature "default" (command-line) -├── syn feature "default" (*) -├── syn feature "derive" -│ └── syn feature "default" (*) -├── syn feature "full" -│ └── rustversion v1.0.2 (*) -├── syn feature "parsing" -│ └── syn feature "default" (*) -├── syn feature "printing" -│ └── syn feature "default" (*) -├── syn feature "proc-macro" -│ └── syn feature "default" (*) -└── syn feature "quote" - ├── syn feature "printing" (*) - └── syn feature "proc-macro" (*)-
To read this graph, you can follow the chain for each feature from the root to
-see why it is included. For example, the "full" feature is added by the
-rustversion crate which is included from myproject (with the default
-features), and myproject is the package selected on the command-line. All
-of the other syn features are added by the "default" feature ("quote" is
-added by "printing" and "proc-macro", both of which are default features).
If you’re having difficulty cross-referencing the de-duplicated (*) entries,
-try with the --no-dedupe flag to get the full output.
cargo-uninstall - Remove a Rust binary
-cargo uninstall [OPTIONS] [SPEC…]
This command removes a package installed with cargo-install(1). The SPEC -argument is a package ID specification of the package to remove (see -cargo-pkgid(1)).
-By default all binaries are removed for a crate but the --bin and
---example flags can be used to only remove particular binaries.
The installation root is determined, in order of precedence:
---root option
CARGO_INSTALL_ROOT environment variable
install.root Cargo config value
CARGO_HOME environment variable
$HOME/.cargo
Package to uninstall.
-Only uninstall the binary NAME.
-Directory to uninstall packages from.
-Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Uninstall a previously installed package.
-cargo uninstall ripgrep-
cargo-update - Update dependencies as recorded in the local lock file
-cargo update [OPTIONS]
This command will update dependencies in the Cargo.lock file to the latest
-version. It requires that the Cargo.lock file already exists as generated
-by commands such as cargo-build(1) or cargo-generate-lockfile(1).
Update only the specified packages. This flag may be specified -multiple times. See cargo-pkgid(1) for the SPEC format.
-If packages are specified with the -p flag, then a conservative update of
-the lockfile will be performed. This means that only the dependency specified
-by SPEC will be updated. Its transitive dependencies will be updated only if
-SPEC cannot be updated without updating dependencies. All other dependencies
-will remain locked at their currently recorded versions.
If -p is not specified, all dependencies are updated.
When used with -p, dependencies of SPEC are forced to update as well.
-Cannot be used with --precise.
When used with -p, allows you to specify a specific version number to
-set the package to. If the package comes from a git repository, this can
-be a git revision (such as a SHA hash or tag).
Displays what would be updated, but doesn’t actually write the lockfile.
-Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Update all dependencies in the lockfile:
-cargo update-
Update only specific dependencies:
-cargo update -p foo -p bar-
Set a specific dependency to a specific version:
-cargo update -p foo --precise 1.2.3-
cargo-vendor - Vendor all dependencies locally
-cargo vendor [OPTIONS] [PATH]
This cargo subcommand will vendor all crates.io and git dependencies for a
-project into the specified directory at <path>. After this command completes
-the vendor directory specified by <path> will contain all remote sources from
-dependencies specified. Additional manifests beyond the default one can be
-specified with the -s option.
The cargo vendor command will also print out the configuration necessary
-to use the vendored sources, which you will need to add to .cargo/config.toml.
Specify extra Cargo.toml manifests to workspaces which should also be
-vendored and synced to the output.
Don’t delete the "vendor" directory when vendoring, but rather keep all -existing contents of the vendor directory
-Instead of ignoring [source] configuration by default in .cargo/config.toml
-read it and use it when downloading crates from crates.io, for example
Normally versions are only added to disambiguate multiple versions of the -same package. This option causes all directories in the "vendor" directory -to be versioned, which makes it easier to track the history of vendored -packages over time, and can help with the performance of re-vendoring when -only a subset of the packages have changed.
-Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Vendor all dependencies into a local "vendor" folder
-cargo vendor-
Vendor all dependencies into a local "third-party/vendor" folder
-cargo vendor third-party/vendor-
Vendor the current workspace as well as another to "vendor"
-cargo vendor -s ../path/to/Cargo.toml-
cargo-verify-project - Check correctness of crate manifest
-cargo verify-project [OPTIONS]
This command will parse the local manifest and check its validity. It emits a -JSON object with the result. A successful validation will display:
-{"success":"true"}
-An invalid workspace will display:
-{"invalid":"human-readable error message"}
-Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
Path to the Cargo.toml file. By default, Cargo searches for the
-Cargo.toml file in the current directory or any parent directory.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-The workspace is OK.
-The workspace is invalid.
-Check the current workspace for errors:
-cargo verify-project-
cargo-version - Show version information
-cargo version [OPTIONS]
Displays the version of Cargo.
-Display additional version information.
-Display the version:
-cargo version-
The version is also available via flags:
-cargo --version -cargo -V-
Display extra version information:
-cargo -Vv-
cargo-yank - Remove a pushed crate from the index
-cargo yank [OPTIONS] --vers VERSION [CRATE]
The yank command removes a previously published crate’s version from the -server’s index. This command does not delete any data, and the crate will -still be available for download via the registry’s download link.
-Note that existing crates locked to a yanked version will still be able to -download the yanked version to use it. Cargo will, however, not allow any new -crates to be locked to any yanked version.
-This command requires you to be authenticated with either the --token option
-or using cargo-login(1).
If the crate name is not specified, it will use the package name from the -current directory.
-The version to yank or un-yank.
-Undo a yank, putting a version back into the index.
-API token to use when authenticating. This overrides the token stored in -the credentials file (which is created by cargo-login(1)).
-Cargo config environment variables can be
-used to override the tokens stored in the credentials file. The token for
-crates.io may be specified with the CARGO_REGISTRY_TOKEN environment
-variable. Tokens for other registries may be specified with environment
-variables of the form CARGO_REGISTRIES_NAME_TOKEN where NAME is the name
-of the registry in all capital letters.
The URL of the registry index to use.
-Name of the registry to use. Registry names are defined in Cargo config files.
-If not specified, the default registry is used, which is defined by the
-registry.default config key which defaults to crates-io.
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-Yank a crate from the index:
-cargo yank --vers 1.0.7 foo-
cargo - The Rust package manager
-cargo [OPTIONS] COMMAND [ARGS]
-cargo [OPTIONS] --version
-cargo [OPTIONS] --list
-cargo [OPTIONS] --help
-cargo [OPTIONS] --explain CODE
This program is a package manager and build tool for the Rust language, -available at https://rust-lang.org.
-Execute benchmarks of a package.
-Compile a package.
-Check a local package and all of its dependencies for errors.
-Remove artifacts that Cargo has generated in the past.
-Build a package’s documentation.
-Fetch dependencies of a package from the network.
-Automatically fix lint warnings reported by rustc.
-Run a binary or example of the local package.
-Compile a package, and pass extra options to the compiler.
-Build a package’s documentation, using specified custom flags.
-Execute unit and integration tests of a package.
-Generate Cargo.lock for a project.
Print a JSON representation of a Cargo.toml file’s location.
Output the resolved dependencies of a package, the concrete used versions -including overrides, in machine-readable format.
-Print a fully qualified package specification.
-Display a tree visualization of a dependency graph.
-Update dependencies as recorded in the local lock file.
-Vendor all dependencies locally.
-Check correctness of crate manifest.
-Create a new Cargo package in an existing directory.
-Build and install a Rust binary.
-Create a new Cargo package.
-Search packages in crates.io.
-Remove a Rust binary.
-Save an API token from the registry locally.
-Manage the owners of a crate on the registry.
-Assemble the local package into a distributable tarball.
-Upload a package to the registry.
-Remove a pushed crate from the index.
-Display help information about Cargo.
-Show version information.
-Print version info and exit. If used with --verbose, prints extra
-information.
List all installed Cargo subcommands. If used with --verbose, prints
-extra information.
Run rustc --explain CODE which will print out a detailed explanation of
-an error message (for example, E0004).
Use verbose output. May be specified twice for "very verbose" output which
-includes extra output such as dependency warnings and build script output.
-May also be specified with the term.verbose
-config value.
No output printed to stdout.
-Control when colored output is used. Valid values:
-auto (default): Automatically detect if color support is available on the
-terminal.
always: Always display colors.
never: Never display colors.
May also be specified with the term.color
-config value.
Either of these flags requires that the Cargo.lock file is
-up-to-date. If the lock file is missing, or it needs to be updated, Cargo will
-exit with an error. The --frozen flag also prevents Cargo from
-attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the
-Cargo.lock file is up-to-date (such as a CI build) or want to avoid network
-access.
Prevents Cargo from accessing the network for any reason. Without this -flag, Cargo will stop with an error if it needs to access the network and -the network is not available. With this flag, Cargo will attempt to -proceed without the network if possible.
-Beware that this may result in different dependency resolution than online -mode. Cargo will restrict itself to crates that are downloaded locally, even -if there might be a newer version as indicated in the local copy of the index. -See the cargo-fetch(1) command to download dependencies before going -offline.
-May also be specified with the net.offline config value.
If Cargo has been installed with rustup, and the first argument to cargo
-begins with +, it will be interpreted as a rustup toolchain name (such
-as +stable or +nightly).
-See the rustup documentation
-for more information about how toolchain overrides work.
Prints help information.
-Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
-details.
See the reference for -details on environment variables that Cargo reads.
-Cargo succeeded.
-Cargo failed to complete.
-~/.cargo/Default location for Cargo’s "home" directory where it stores various
-files. The location can be changed with the CARGO_HOME environment
-variable.
$CARGO_HOME/bin/Binaries installed by cargo-install(1) will be located here. If using -rustup, executables distributed with Rust are also located here.
-$CARGO_HOME/config.tomlThe global configuration file. See the reference -for more information about configuration files.
-.cargo/config.tomlCargo automatically searches for a file named .cargo/config.toml in the
-current directory, and all parent directories. These configuration files
-will be merged with the global configuration file.
$CARGO_HOME/credentials.tomlPrivate authentication information for logging in to a registry.
-$CARGO_HOME/registry/This directory contains cached downloads of the registry index and any -downloaded dependencies.
-$CARGO_HOME/git/This directory contains cached downloads of git dependencies.
-Please note that the internal structure of the $CARGO_HOME directory is not
-stable yet and may be subject to change.
Build a local package and all of its dependencies:
-cargo build-
Build a package with optimizations:
-cargo build --release-
Run tests for a cross-compiled target:
-cargo test --target i686-unknown-linux-gnu-
Create a new package that builds an executable:
-cargo new foobar-
Create a package in the current directory:
-mkdir foo && cd foo -cargo init .-
Learn about a command’s options and usage:
-cargo help clean-
See https://github.com/rust-lang/cargo/issues for issues.
-