CARGO-RUSTC(1)

📦 version 1.81.0, in ubuntu jammy, ubuntu noble

💖 CARGO-RUSTC 💖

okay bestie, welcome to cargo-rustc(1) — it's a General Commands Manual page and it's giving "compile my package but also lemme whisper sweet flags to rustc". let's get into it 🎀

✨ NAME ✨

cargo-rustc — compile the current package, and pass extra options to the compiler 🫶

🌸 SYNOPSIS 🌸

cargo rustc [options] [-- args]

💅 DESCRIPTION 💅

so here's the vibe: the specified target for the current package (or the package you named with -p if you did that) gets compiled, along with all of its dependencies. no target left behind, fr fr.

now the cute part — those args you pass? they all go to the final compiler invocation, and not to any of the dependencies. only the last one gets to hear your little secrets. 💌

but lowkey important: the compiler is still gonna unconditionally receive arguments like -L, --extern, and --crate-type whether you like it or not — your args just get tacked on top of the invocation. you're adding, not replacing. periodt.

for the full tea on rustc flags, go look at https://doc.rust-lang.org/rustc/index.html ✨

okay and this one's a whole rule: this command requires that only one target is being compiled when you provide additional arguments. so if your current package has more than one target available, you must use the filters — --lib, --bin, etc. — to pick which target gets compiled. no being wishy-washy about it. 😭

and if what you actually want is to pass flags to every single compiler process Cargo spawns, that's a different girl — use the RUSTFLAGS environment variable (https://doc.rust-lang.org/cargo/reference/environment-variables.html) or the build.rustflags config value (https://doc.rust-lang.org/cargo/reference/config.html). iykyk 💜

👑 OPTIONS 👑

🎀 Package Selection

by default, the package sitting in the current working directory is the one that gets selected. you can use the -p flag to choose a different package inside a workspace. main character energy, choose your fighter. ✨

  • -p spec, --package spec — the package to build. check out cargo-pkgid(1) for the SPEC format 📦

🦋 Target Selection

when you give it no target selection options at all, cargo rustc will build all binary and library targets of the selected package. all of 'em. 💖

binary targets get automatically built if there's an integration test or benchmark being selected to build. this lets an integration test actually run the binary to exercise and test its behavior — iconic. the CARGO_BIN_EXE_<name> environment variable (https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates) is set when the integration test is built, so it can use the env macro (https://doc.rust-lang.org/std/macro.env.html) to locate the executable. very demure, very mindful. 🧚

passing target selection flags will build only the specified targets. narrowing it down, love that for us.

heads up bestie: --bin, --example, --test and --bench flags also support common Unix glob patterns like *, ? and []. BUT — to avoid your shell accidentally expanding those glob patterns before Cargo gets its hands on them, you must wrap each glob pattern in single quotes or double quotes. no cap. 🔥
  • --lib — build the package's library 📚
  • --bin name… — build the specified binary. this flag can be specified multiple times and supports common Unix glob patterns ✨
  • --bins — build all binary targets 🎯
  • --example name… — build the specified example. may be specified multiple times, supports common Unix glob patterns 💫
  • --examples — build all example targets 🌈
  • --test name… — build the specified integration test. may be specified multiple times, supports common Unix glob patterns 🧪
  • --tests — 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, plus integration tests. ⚠️ be aware this will also build any required dependencies, so the lib target may get 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.
  • --bench name… — build the specified benchmark. may be specified multiple times, supports common Unix glob patterns ⏱️
  • --benches — 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, plus bench targets. ⚠️ same deal — 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.
  • --all-targets — build all targets. this is equivalent to specifying --lib --bins --tests --benches --examples. literally all of them, go off 💅

🌸 Feature Selection

the feature flags let you control which features are enabled. when no feature options are given, the default feature is activated for every selected package. cute defaults. 💖

for more details, see the features documentation: https://doc.rust-lang.org/cargo/reference/features.html#command-line-feature-options

  • -F features, --features features — space or comma separated list of features to activate. features of workspace members may be enabled with package-name/feature-name syntax. this flag may be specified multiple times, which enables all specified features. stack 'em up 🍓
  • --all-features — activate all available features of all selected packages 🔥
  • --no-default-features — do not activate the default feature of the selected packages 🙈

🧚 Compilation Options

  • --target triple — 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 flag may be specified multiple times. 🎯 this may also be specified with the build.target config value (https://doc.rust-lang.org/cargo/reference/config.html).
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 (https://doc.rust-lang.org/cargo/guide/build-cache.html) for more details. 👀
  • -r, --release — build optimized artifacts with the release profile. see also the --profile option for choosing a specific profile by name. glow up your binaries ✨
  • --profile name — build with the given profile. 💅 the rustc subcommand will treat the following named profiles with special behaviors:
    • check — builds in the same way as the cargo-check(1) command with the dev profile.
    • test — builds in the same way as the cargo-test(1) command, enabling building in test mode which will enable tests and enable the test cfg option. see rustc tests (https://doc.rust-lang.org/rustc/tests/index.html) for more detail.
    • bench — builds in the same was as the cargo-bench(1) command, similar to the test profile. (yes bestie, "same was" — we keep the original's typo, that's the law 🫡) see the reference (https://doc.rust-lang.org/cargo/reference/profiles.html) for more details on profiles.
  • --timings=fmts — output information how long each compilation takes, and track concurrency information over time. accepts an optional comma-separated list of output formats; --timings without an argument will default to --timings=html. ⏱️ specifying an output format (rather than the default) is unstable and requires -Zunstable-options. valid output formats:
    • html (unstable, requires -Zunstable-options): write a human-readable file cargo-timing.html to the target/cargo-timings directory with a report of the compilation. also write a report to the same directory with a timestamp in the filename if you want to look at older runs. HTML output is suitable for human consumption only, and does not provide machine-readable timing data. 📊
    • json (unstable, requires -Zunstable-options): emit machine-readable JSON information about timing information. 🤖
  • --crate-type crate-type — build for the given crate type. this flag accepts a comma-separated list of 1 or more crate types, of which the allowed values are the same as the crate-type field in the manifest for configuring a Cargo target. see crate-type field (https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-crate-type-field) for possible values. 💖 if the manifest contains a list, and --crate-type is provided, the command-line argument value will override what is in the manifest. the CLI wins, always. 👑 this flag only works when building a lib or example library target. 🎀

🌈 Output Options

  • --target-dir directory — 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 (https://doc.rust-lang.org/cargo/reference/config.html). defaults to target in the root of the workspace. 📁

💜 Display Options

  • -v, --verbose — 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 (https://doc.rust-lang.org/cargo/reference/config.html). 🗣️
  • -q, --quiet — do not print cargo log messages. may also be specified with the term.quiet config value (https://doc.rust-lang.org/cargo/reference/config.html). 🤫
  • --color when — control when colored output is used. valid values: 🎨
  • --message-format fmt — 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. conflicts with short and json.
    • short: emit shorter, human-readable text messages. conflicts with human and json.
    • json: emit JSON messages to stdout. see the reference (https://doc.rust-lang.org/cargo/reference/external-tools.html#json-messages) for more details. conflicts with human and short.
    • json-diagnostic-short: ensure the rendered field of JSON messages contains the "short" rendering from rustc. cannot be used with human or short.
    • json-diagnostic-rendered-ansi: ensure the rendered field of JSON messages contains embedded ANSI color codes for respecting rustc's default color scheme. cannot be used with human or short.

to be continued, bestie — there's more of this page coming 💖

  • json-render-diagnostics — tells Cargo to NOT put rustc's diagnostics inside the JSON messages it prints. Instead, Cargo itself renders the JSON diagnostics that come from rustc. Cargo's own JSON diagnostics, plus the other ones coming from rustc, still get emitted like normal. Cannot be used with human or short. pick a lane bestie 💅

💖 Manifest Options 💖

These ones are all about which manifest and which dependency resolution we're rolling with. lowkey the most important section, ngl.

  • --manifest-path path — the path to the Cargo.toml file. If you don't say anything, Cargo goes looking for Cargo.toml in the current directory, and then keeps climbing up through every parent directory until it finds one. 🧚
  • --ignore-rust-version — just... ignore the rust-version specification in packages. pretend you didn't see it. 🙈
  • --locked — asserts that the exact same dependencies and versions are used as when the existing Cargo.lock file was originally generated. Cargo will bail out with an error when either of these happens:
    • the lock file is straight up missing 🫥
    • Cargo tried to change the lock file because the dependency resolution came out different

it's giving very "we are not doing surprises today". use it in environments where you want deterministic builds, like CI pipelines. ⭐

  • --offline — stops Cargo from touching the network for literally any reason. Without this flag, Cargo just stops with an error if it needs the network and the network isn't there. With this flag, Cargo will attempt to keep going without the network if it possibly can. 🌸
⚠️ beware bestie, this can give you a different dependency resolution than online mode. Cargo will restrict itself to crates that are already downloaded locally, even if a newer version exists as indicated in the local copy of the index. See the cargo-fetch(1) command to download dependencies before you go offline. 💀

May also be specified with the net.offline config value: https://doc.rust-lang.org/cargo/reference/config.html.

  • --frozen — literally equivalent to specifying both --locked and --offline at the same time. one flag, two flags' worth of chaos. 🎀

✨ Common Options ✨

  • +toolchain — if Cargo was installed with rustup, and the first argument to cargo starts with +, it gets interpreted as a rustup toolchain name (things like +stable or +nightly). See the rustup documentation at https://rust-lang.github.io/rustup/overrides.html for more on how toolchain overrides work. 🦋
  • --config KEY=VALUE or PATH — overrides a Cargo configuration value. The argument should be in TOML syntax of KEY=VALUE, or given as a path to an extra configuration file. You can pass this flag multiple times, no cap. See the command-line overrides section at https://doc.rust-lang.org/cargo/reference/config.html#command-line-overrides for more info. ✨
  • -C PATH — changes the current working directory before executing any of the specified operations. This affects stuff like where cargo looks by default for the project manifest (Cargo.toml), and also the directories it searches when discovering .cargo/config.toml, for example. This option must appear before the command name, like:
cargo -C path/to/my-project build
💀 heads up: this option is only available on the nightly channel (https://doc.rust-lang.org/book/appendix-07-nightly-rust.html) and it requires the -Z unstable-options flag to enable (see #10098 at https://github.com/rust-lang/cargo/issues/10098).
  • -h, --help — prints help information. the classic. 🫶
  • -Z flag — unstable (nightly-only) flags for Cargo. Run cargo -Z help for the details. iykyk. 🔥

🎀 Miscellaneous Options 🎀

  • -j N, --jobs N — the number of parallel jobs to run. May also be specified with the build.jobs config value (https://doc.rust-lang.org/cargo/reference/config.html). Defaults to the number of logical CPUs. If it's negative, it sets the maximum number of parallel jobs to the number of logical CPUs plus the provided value. If the string default is provided, it sets the value back to defaults. Should not be 0. 🚫
  • --keep-going — build as many crates in the dependency graph as possible, instead of aborting the build on the first one that fails to build. queen behavior honestly 👑

For example, if the current package depends on dependencies fails and works, one of which fails to build, cargo rustc -j1 may or may not build the one that succeeds (depending on which one of the two builds Cargo picked to run first), whereas cargo rustc -j1 --keep-going would definitely run both builds, even if the one run first fails.

  • --future-incompat-report — displays a future-incompat report for any future-incompatible warnings produced during execution of this command. 🌈

See cargo-report(1).

🌈 ENVIRONMENT 🌈

See the reference at https://doc.rust-lang.org/cargo/reference/environment-variables.html for details on environment variables that Cargo reads. ✨

💀 EXIT STATUS 💀

  • 0 — Cargo succeeded. we love to see it 💖
  • 101 — Cargo failed to complete. it's giving tragedy 😭

🦋 EXAMPLES 🦋

  1. Check if your package (not including dependencies) uses unsafe code:
cargo rustc --lib -- -D unsafe-code
  1. Try an experimental flag on the nightly compiler, such as this one which prints the size of every type:
cargo rustc --lib -- -Z print-type-sizes
  1. Override the crate-type field in Cargo.toml with a command-line option:
cargo rustc --lib --crate-type lib,cdylib

👑 SEE ALSO 👑

and that's the whole page bestie, no crumbs left 🎀 this was CARGO-RUSTC(1) straight from the Cargo manual — the official source, with its version and date up in the header — so go forth and cargo rustc responsibly. mwah 💅✨

📦 where this page comes from