cargo-fix(1)

名称

cargo-fix — 自动修复 rustc 报告的 lint 警告

概要

cargo fix [选项]

描述

这个 Cargo 子命令会自动将 rustc 从诊断(如警告)中给出的建议应用到你的源代码。这旨在帮助自动化 rustc 本身已经知道如何告诉你修复的任务!

在幕后执行 cargo fix 将会执行 cargo-check(1)。任何适用于你的 crate 的警告都将被自动修复(如果可能),并且在检查过程完成时将显示所有剩余的警告。例如,如果你想将所有修复应用于当前包,你可以运行

cargo fix

它的行为与 cargo check --all-targets 相同。

cargo fix 只能修复通常使用 cargo check 编译的代码。如果代码是通过可选的功能有条件地启用的,则你需要启用这些功能才能分析该代码

cargo fix --features foo

类似地,其他 cfg 表达式(如特定于平台的代码)将需要传递 --target 来修复给定目标的代码。

cargo fix --target x86_64-pc-windows-gnu

如果你在使用 cargo fix 时遇到任何问题,或者有任何问题或功能请求,请随时在 https://github.com/rust-lang/cargo 上提交 issue。

版本迁移

cargo fix 子命令也可用于将包从一个 版本 迁移到下一个版本。一般步骤是

  1. 运行 cargo fix --edition。如果你的项目有多个功能,请考虑同时使用 --all-features 标志。如果你的项目有由 cfg 属性控制的特定于平台的代码,你可能还需要使用不同的 --target 标志多次运行 cargo fix --edition
  2. 修改 Cargo.toml 以将 edition 字段 设置为新版本。
  3. 运行你的项目测试以验证一切仍然正常工作。如果发出新的警告,你可能需要考虑再次运行 cargo fix(不带 --edition 标志)以应用编译器给出的任何建议。

希望就这样了!请记住上面提到的注意事项,cargo fix 无法更新非活动功能或 cfg 表达式的代码。此外,在某些罕见的情况下,编译器无法自动将所有代码迁移到新版本,这可能需要在使用新版本构建后进行手动更改。

选项

修复选项

--broken-code
即使代码已经有编译器错误,也修复代码。如果 cargo fix 无法应用更改,这将非常有用。它将应用更改并将损坏的代码留在工作目录中,供你检查和手动修复。
--edition
应用将代码更新到下一个版本的更改。这不会更新 Cargo.toml 清单中的版本,必须在 cargo fix --edition 完成后手动更新。
--edition-idioms
应用将代码更新为当前版本的首选样式的建议。
--allow-no-vcs
即使未检测到 VCS,也修复代码。
--allow-dirty
即使工作目录有更改,也修复代码。
--allow-staged
即使工作目录有暂存的更改,也修复代码。

包选择

默认情况下,当没有给出包选择选项时,所选的包取决于所选的清单文件(如果未给出 --manifest-path,则基于当前工作目录)。如果清单是工作区的根,则选择工作区的默认成员,否则只选择由清单定义的包。

可以使用根清单中的 workspace.default-members 键显式设置工作区的默认成员。如果未设置此项,虚拟工作区将包括所有工作区成员(等效于传递 --workspace),而非虚拟工作区将仅包括根 crate 本身。

-p spec
--package spec
仅修复指定的包。有关 SPEC 格式,请参阅 cargo-pkgid(1)。此标志可以多次指定,并支持常见的 Unix glob 模式,如 *?[]。但是,为了避免 shell 在 Cargo 处理它们之前意外地扩展 glob 模式,你必须在每个模式周围使用单引号或双引号。
--workspace
修复工作区中的所有成员。
--all
--workspace 的已弃用别名。
--exclude SPEC
排除指定的包。必须与 --workspace 标志一起使用。此标志可以多次指定,并支持常见的 Unix glob 模式,如 *?[]。但是,为了避免 shell 在 Cargo 处理它们之前意外地扩展 glob 模式,你必须在每个模式周围使用单引号或双引号。

目标选择

当没有给出目标选择选项时,cargo fix 将修复所有目标(隐含 --all-targets)。如果二进制文件缺少 required-features,则会跳过它们。

传递目标选择标志将仅修复指定的目标。

请注意,--bin--example--test--bench 标志也支持常见的 Unix glob 模式,如 *?[]。但是,为了避免 shell 在 Cargo 处理它们之前意外地扩展 glob 模式,你必须在每个 glob 模式周围使用单引号或双引号。

--lib
修复包的库。
--bin name
修复指定的二进制文件。此标志可以多次指定,并支持常见的 Unix glob 模式。
--bins
修复所有二进制目标。
--example name
修复指定的示例。此标志可以多次指定,并支持常见的 Unix glob 模式。
--examples
修复所有示例目标。
--test name
修复指定的集成测试。此标志可以多次指定,并支持常见的 Unix glob 模式。
--tests
修复所有清单标志设置为 test = true 的目标。默认情况下,这包括作为单元测试构建的库和二进制文件,以及集成测试。请注意,这也将构建任何必需的依赖项,因此 lib 目标可能会构建两次(一次作为单元测试,一次作为二进制文件、集成测试等的依赖项)。可以通过在目标的清单设置中设置 test 标志来启用或禁用目标。
--bench name
修复指定的基准测试。此标志可以多次指定,并支持常见的 Unix glob 模式。
--benches
修复所有清单标志设置为 bench = true 的目标。默认情况下,这包括作为基准测试构建的库和二进制文件,以及基准测试目标。请注意,这也将构建任何必需的依赖项,因此 lib 目标可能会构建两次(一次作为基准测试,一次作为二进制文件、基准测试等的依赖项)。可以通过在目标的清单设置中设置 bench 标志来启用或禁用目标。
--all-targets
修复所有目标。这等效于指定 --lib --bins --tests --benches --examples

功能选择

功能标志允许你控制启用哪些功能。当没有给出功能选项时,将为每个选定的包激活 default 功能。

有关更多详细信息,请参阅 功能文档

-F features
--features features
以空格或逗号分隔的要激活的功能列表。可以使用 包名称/功能名称 语法启用工作区成员的功能。此标志可以多次指定,这将启用所有指定的功能。
--all-features
激活所有选定包的所有可用功能。
--no-default-features
不要激活所选包的 default 功能。

编译选项

--target triple
为给定的架构修复。默认值为宿主架构。triple 的一般格式为 <arch><sub>-<vendor>-<sys>-<abi>。运行 rustc --print target-list 以获取支持的目标列表。此标志可以多次指定。

也可以使用 build.target 配置值 指定此项。

请注意,指定此标志会使 Cargo 在不同的模式下运行,其中目标构件放置在单独的目录中。有关更多详细信息,请参阅 构建缓存 文档。

-r
--release
使用 release 配置文件修复优化的构件。另请参阅 --profile 选项,按名称选择特定配置文件。
--profile name
使用给定的配置文件修复。

作为特殊情况,指定 test 配置文件也将启用在测试模式下的检查,这将启用检查测试并启用 test cfg 选项。有关更多详细信息,请参阅 rustc tests

有关配置文件的更多详细信息,请参阅 参考

--timings=fmts
输出每个编译花费的时间信息,并跟踪随时间变化的并发信息。接受可选的逗号分隔的输出格式列表;不带参数的 --timings 将默认为 --timings=html。指定输出格式(而不是默认格式)是不稳定的,并且需要 -Zunstable-options。有效的输出格式

  • html(不稳定,需要 -Zunstable-options):将人类可读的文件 cargo-timing.html 写入 target/cargo-timings 目录,其中包含编译报告。如果你想查看旧的运行,还可以将带有时间戳的报告写入同一目录中的文件名。HTML 输出仅适用于人类消费,不提供机器可读的计时数据。
  • json(不稳定,需要 -Zunstable-options):发出有关计时信息的机器可读 JSON 信息。

输出选项

--target-dir directory
所有生成工件和中间文件的目录。也可以通过 CARGO_TARGET_DIR 环境变量或 build.target-dir 配置值 指定。默认为工作区根目录下的 target 目录。

显示选项

-v
--verbose
使用详细输出。可以指定两次以获得“非常详细”的输出,其中包含额外的输出,例如依赖项警告和构建脚本输出。也可以通过 term.verbose 配置值 指定。
-q
--quiet
不打印 cargo 日志消息。也可以通过 term.quiet 配置值 指定。
--color when
控制何时使用彩色输出。有效值:

  • auto (默认): 自动检测终端是否支持颜色。
  • always: 始终显示颜色。
  • never: 永不显示颜色。

也可以通过 term.color 配置值 指定。

--message-format fmt
诊断消息的输出格式。可以指定多次,并包含逗号分隔的值。有效值:

  • human (默认): 以人类可读的文本格式显示。与 shortjson 冲突。
  • short: 发出更短、人类可读的文本消息。与 humanjson 冲突。
  • json: 将 JSON 消息输出到 stdout。有关更多详细信息,请参阅参考文档。与 humanshort 冲突。
  • json-diagnostic-short: 确保 JSON 消息的 rendered 字段包含来自 rustc 的“short”渲染。不能与 humanshort 一起使用。
  • json-diagnostic-rendered-ansi: 确保 JSON 消息的 rendered 字段包含嵌入的 ANSI 颜色代码,以遵循 rustc 的默认颜色方案。不能与 humanshort 一起使用。
  • json-render-diagnostics: 指示 Cargo 不要在打印的 JSON 消息中包含 rustc 诊断信息,而是 Cargo 本身应该渲染来自 rustc 的 JSON 诊断信息。Cargo 自己的 JSON 诊断信息和来自 rustc 的其他诊断信息仍然会输出。不能与 humanshort 一起使用。

清单选项

--manifest-path path
Cargo.toml 文件的路径。默认情况下,Cargo 会在当前目录或任何父目录中搜索 Cargo.toml 文件。
--ignore-rust-version
忽略包中的 rust-version 规范。
--locked
断言使用的依赖项和版本与最初生成现有 Cargo.lock 文件时完全相同。当出现以下任何一种情况时,Cargo 将退出并显示错误:

  • 缺少 lock 文件。
  • Cargo 试图由于不同的依赖项解析而更改 lock 文件。

它可以在需要确定性构建的环境中使用,例如在 CI 管道中。

--offline
阻止 Cargo 以任何理由访问网络。如果没有此标志,如果 Cargo 需要访问网络但网络不可用,则会停止并显示错误。有了此标志,如果可能,Cargo 将尝试在没有网络的情况下继续进行。

请注意,这可能会导致与在线模式不同的依赖项解析。Cargo 将把自己限制在本地下载的 crate,即使本地索引副本中指示可能存在较新的版本。请参阅 cargo-fetch(1) 命令,在离线前下载依赖项。

也可以通过 net.offline 配置值 指定。

--frozen
等效于同时指定 --locked--offline
--lockfile-path PATH
将 lock 文件的路径从默认路径 (<workspace_root>/Cargo.lock) 更改为 PATHPATH 必须以 Cargo.lock 结尾 (例如 --lockfile-path /tmp/temporary-lockfile/Cargo.lock)。请注意,提供 --lockfile-path 将忽略默认路径中的现有 lock 文件,而是使用来自 PATH 的 lock 文件,或者如果不存在,则将新的 lock 文件写入提供的 PATH 中。此标志可用于在只读目录中运行大多数命令,将 lock 文件写入提供的 PATH 中。

此选项仅在 nightly 频道上可用,并且需要 -Z unstable-options 标志才能启用(请参阅 #14421)。

常用选项

+toolchain
如果 Cargo 是通过 rustup 安装的,并且 cargo 的第一个参数以 + 开头,则它将被解释为 rustup 工具链名称(例如 +stable+nightly)。有关工具链覆盖如何工作的更多信息,请参阅 rustup 文档
--config KEY=VALUEPATH
覆盖 Cargo 配置值。参数应采用 KEY=VALUE 的 TOML 语法,或作为指向额外配置文件的路径提供。此标志可以指定多次。有关更多信息,请参阅命令行覆盖部分
-C PATH
在执行任何指定的操作之前,更改当前工作目录。这会影响诸如 cargo 默认查找项目清单 (Cargo.toml) 的位置,以及搜索发现 .cargo/config.toml 的目录。此选项必须出现在命令名称之前,例如 cargo -C path/to/my-project build

此选项仅在 nightly 频道上可用,并且需要 -Z unstable-options 标志才能启用(请参阅 #10098)。

-h
--help
打印帮助信息。
-Z flag
Cargo 的不稳定(仅限 nightly)标志。运行 cargo -Z help 以获取详细信息。

其他选项

-j N
--jobs N
要运行的并行作业数。也可以通过 build.jobs 配置值 指定。默认为逻辑 CPU 的数量。如果为负数,则会将最大并行作业数设置为逻辑 CPU 的数量加上提供的值。如果提供字符串 default,则会将该值设置回默认值。不应为 0。
--keep-going
在依赖关系图中尽可能多地构建 crate,而不是在第一个构建失败的 crate 上中止构建。

例如,如果当前包依赖于依赖项 failsworks,其中一个构建失败,cargo fix -j1 可能或者可能不会构建成功的一个(取决于 Cargo 选择首先运行哪一个构建),而 cargo fix -j1 --keep-going 肯定会运行这两个构建,即使首先运行的构建失败了。

环境变量

有关 Cargo 读取的环境变量的详细信息,请参阅参考文档

退出状态

  • 0: Cargo 成功。
  • 101: Cargo 未能完成。

示例

  1. 将编译器建议应用于本地包

    cargo fix
    
  2. 更新一个包,使其为下一个版本做好准备

    cargo fix --edition
    
  3. 应用当前版本的建议习惯用法

    cargo fix --edition-idioms
    

另请参阅

cargo(1), cargo-check(1)