cargo-fix(1)

定义

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

概要

cargo fix [options]

描述

这个Cargo子命令会自动从诊断中获取rustc的建议，如警告，并将其应用于你的源代码。 帮助自动化那些rustc本身已经知道如何告诉你怎样修复的任务。

执行 cargo fix 将在引擎下执行 cargo-check(1) 。 自动修复包所有警告(如果可能的话)，在检查结束后显示剩余所有警告。 比如，想把所有修正应用于当前包，可以运行:

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 子命令也可以用来将包从一个Edition版次迁移到另一个版次。通常的过程是:

  1. 运行 cargo fix --edition 。如果项目有多个特性，也可以考虑使用 --all-features 标志。 如果你的项目有特定平台的代码被 cfg 属性控制，你可能需要使用不同的 --target 标志，多次运行 cargo fix --edition 。
  2. 修改 Cargo.toml ，将edition field设置为新版本。
  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
即使工作目录VCS有变化，也可以修复代码。
--allow-staged
即使工作目录有VCS暂存变化，也能修复代码。

包的选择

默认情况下，如果没有提供选择包的选项，那么会按照选择的配置清单文件来选择包(当没有指定 --manifest-path 时，按照当前工目录来查找配置清单文件)。 如果工作空间根目录的配置清单文件，则会选择该工作空间的默认成员，否则仅选取配置清单文件所在的那个包。

可以通过 workspace.default-members 来显式设置工作空间的默认成员。如果没有设置，在虚拟工作空间下会选择所有的成员，在非虚拟工作空间下仅会选择根 package 。

-p spec...
--package spec...
只修复指定的包。 见 cargo-pkgid(1) 了解 SPEC 格式。这个标志可以多次指定，并支持常见的 Unix 通配符模式，如 *, ? 和 []. 然而，为了避免shell在Cargo处理通配符模式之前意外地扩展它们，必须在每个模式周围使用单引号或双引号。
--workspace
修复工作空间的所有成员。
--all
弃用的 --workspace 的别名。
--exclude SPEC...
排除指定的包。必须与 --workspace 标志一起使用。 这个标志可以多次指定，并支持常见的 Unix 通配符模式，如 *, ? 和 [] 。 然而，为了避免shell在Cargo处理通配符模式之前意外地扩展它们，必须在每个模式周围使用单引号或双引号。

目标选择

当没有给出目标选择选项时， cargo fix 将修复所有目标(隐含 --all-targets )。如果二进制文件的 required-features 缺失，将被跳过。

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

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

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

特性选择

特性标志允许你控制开启哪些特性。当没有提供特性选项时，会为每个选择的包启用 default 特性。

见 特性文档 了解更多内容。

-F features
--features features
激活的特性列表用空格或逗号分隔。可以用package-name/feature-name语法启用工作空间成员的特性。这个标志可以多次指定，从而可以启用所有指定的特性。
--all-features
激活所有选定包的所有可用特性。
--no-default-features
不激活所选包的default特性。

编译选项

--target triple
对给定的架构进行修复。默认是主机架构。三元组的一般格式是<arch><sub>-<vendor>-<sys>-<abi> 。 运行rustc --print target-list以获得支持的目标列表。这个标志可以多次指定。

也可以通过 build.target 配置。

注意，指定这个标志会使Cargo在不同的模式下运行，目标制品放在单独目录。 参见 构建缓存 文档了解详情。

-r
--release
修复release编译设置的优化制品。 参见 --profile选项，以按名称选择特定的编译设置。
--profile name
用给定的编译设置进行修复。

作为一种特殊情况，指定 test 编译设置也将启用测试模式下的检查，这将启用检查测试并启用test cfg选项。 见 rustc tests 了解细节。

见 参考 了解编译设置细节。

--ignore-rust-version
即使所选的Rust编译器比项目rust-version字段中配置的所需Rust版本更早，也可以修复目标。
--timings=fmts
输出每次编译需要多长时间的信息，并跟踪时间段的并发信息。 接受可选的逗号分隔的输出格式列表；没有参数的--timings将默认为--timings=html。 指定未稳定的输出格式(而不是默认)，需要-Zunstable-options。 有效的输出格式:

  • html (未稳定, 要求 -Zunstable-options): 在target/cargo-timings目录下生成可阅读的 cargo-timing.html 文件，并附编译报告。 如果你想查看更早的运行情况，也可以将报告写到同一目录下，文件名带有时间戳。 HTML输出适合人类阅读，机器不可读。
  • json (未稳定, 要求 -Zunstable-options): 发送机器可读的关于时间信息的JSON。

输出选项

--target-dir directory
所有生成制品和中间文件的目录。 也可以用 CARGO_TARGET_DIR 环境变量, 或 build.target-dir 配置。 默认为工作空间的根target。

Display Options

-v
--verbose
进行详细输出。可以指定两遍来开启 "非常详细" 模式，输出更多的额外信息，像是依赖项的警告和构建脚本的输出信息。 也可以通过 term.verbose 配置 。
-q
--quiet
不打印 cargo 日志信息。 也可以通过 term.quiet 配置。
--color when
控制使用彩色输出。可选值有:

  • auto (默认值): 自动检测终端是否支持彩色输出。
  • always: 总是显示彩色。
  • never: 从不显示彩色。

也可以在 term.color 配置。

--message-format fmt
特征信息的输出格式。可以多次指定，数值由逗号分隔。有效值:

  • human (默认): 以人可阅读的文本格式显示。 short 和 json 冲突。
  • short: 发出更短的、人可阅读的文本信息。 human 和 json 冲突。
  • json: 向标准输出发送JSON信息。 见 参考 了解详情. human 和 short 冲突。
  • json-diagnostic-short: 确保JSON消息的rendered字段包含rustc的"short"渲染。不能和 human short。
  • json-diagnostic-rendered-ansi: 确保JSON消息的rendered字段包含嵌入式ANSI颜色代码，以遵从rustc的默认颜色方案。 不能和 human short。
  • json-render-diagnostics: 指示Cargo在打印的JSON信息中不包含rustc的特征信息，而是由Cargo来渲染来自rustc的JSON信息。Cargo自身的JSON和其他来自rustc的信息仍会发送。不能和 human short。

配置选项

--manifest-path path
Cargo.toml 文件的路径。默认, Cargo 在当前目录和任意父目录搜索 Cargo.toml 文件。
--frozen
--locked
这些标志都要求 Cargo.lock 文件是最新的。 如果lock文件丢失, 或是需要更新, Cargo会返回错误并退出，--frozen 选项还会阻止cargo通过网络来判断其是否过期。

可以用于断言 Cargo.lock 文件是否最新状态(例如CI构建)或避免网络访问。

--offline
阻止Cargo访问网络。如果不指定该选项，Cargo会在需要使用网络但不可用时停止构建并返回错误。设置该标识，Cargo将尽可能不使用网络完成构建。

需注意，这样可能会导致与在线模式不同的依赖处理，Cargo将限制仅使用已下载到本地的crate，即使本地索引中有更新版本。 查阅 cargo-fetch(1) 命令，在脱机前下载依赖。

也可以用 net.offline 配置。

常规选项

+toolchain
如果Cargo已经通过rustup安装，并且第一个传给 cargo 的参数以 + 开头， 则当作rustup的工具链名称。(例如 +stable 或 +nightly). 查阅 rustup 文档 了解关于工具链覆盖的信息。
--config KEY=VALUE or PATH
覆盖Cargo配置项的值，该参数应当为TOML KEY=VALUE 语法， 或者提供附加的配置文件的路径。该标识可以多次指定。 查阅 命令行覆盖部分 获取更多信息
-h
--help
打印帮助信息。
-Z flag
Cargo不稳定的(每日构建)标志。运行 cargo -Z help 了解详情。

其他选项

-j N
--jobs N
并行执行的任务数。可以通过 build.jobs 配置。默认值为逻辑CPU数。如果设置为负值，则最大的并行任务数为*逻辑CPU数*加*这个负数*。该值不能为0。
--keep-going
尽可能的构建依赖图中的 crate ，而不是一个失败就停止。功能还不稳定，需要 -Zunstable-options。

环境

查阅 参考 了解Cargo读取环境变量。

退出状态

  • 0: Cargo 执行成功。
  • 101: Cargo 没有成功完成。

示例

  1. 将编译器建议修复本地包:

    cargo fix

  2. 更新包到下一版本前的准备:

    cargo fix --edition

  3. 应用当前版本建议的首选样式:

    cargo fix --edition-idioms

参阅

cargo(1), cargo-check(1)