★ FEATURED ARTICLE 文档【免费下载链接】rfcsRFCs for changes to Rust项目地址https://gitcode.com/gh_mirrors/rf/rfcs点击查看免费下载本指南围绕已合并进 RFC 仓库的 RFC 2834对应实现追踪于 rust-lang/rust#71249展开系统讲解 Cargo 如何在构建结束阶段向开发者汇报上游依赖中触发未来不兼容future-incompatibility警告的 crate即使这些警告已被--cap-lintsallow或#[allow(..)]抑制。读完本文你将掌握该机制要解决的问题、rustc与 Cargo 的职责边界、构建结束报告的完整形态与cargo describe-future-incompatibilities的用法以及.cargo/config中报告频率控制配置的设计思路并理解其与仓库内相关 RFC 的演进关系。背景cap-lints机制及其副作用要理解 RFC 2834必须先理解它要对抗的机制——--cap-lints。仓库中的 RFC 1193 cap-lints 定义了该标志--cap-lints LEVEL设置本次编译的最高 lint 等级不能被其他标志或属性覆盖。其可接受值为allow、warn、deny、forbid。当传入--cap-lints allow时源码中所有#[warn]、#[deny]、#[forbid]都会被忽略传入--cap-lints warn时只有deny和forbid指令被忽略。RFC 1193 同时规定 Cargo 在编译所有上游依赖非 path 依赖时一律传入--cap-lints allow。这样做的理由很充分如果上游 crate 使用了#![deny(warnings)]而新版本 Rust 引入了新的警告上游依赖就可能编译失败形成隐式破坏性变更。将上游依赖的 lint 封顶可以让编译器在向后兼容的前提下自由演进 lint 集合。然而副作用也随之而来未来不兼容future-incompatibilitylints 同样被cap-lints抑制了。这类 lint 标记的是一段计划在未来的某个 Rust 版本中被移除/变成硬错误的代码模式通常涉及可能产生未定义行为unsound或语义未明确定义的构造。它们恰恰是开发者最需要提前知道的信号——因为一旦对应版本发布整个项目将直接编译失败。核心问题下游维护者被蒙在鼓里RFC 2834 引用了 rust-lang/rust#34596 中的一段经典描述如果你编写了一个被广泛使用的库但当下并未积极使用它你可能注意不到它将来会坏掉——而且你的用户也不会注意到因为 Cargo 在把你的库作为依赖编译时会封顶 lints。运行示例unwary与brashRFC 用一对虚构 crate 说明问题unwary依赖上游 cratebrash而brash的源码触发了未来不兼容 lint——对 packed 字段的借用x.data.0即safe packed borrows问题见 rust-lang/rust#46043。今天的实际行为如下由于brash是unwary的非 path 依赖构建unwary时 Cargo 会给rustc传入--cap-lintsallow从而在诊断输出中完全抑制brash的警告crates % cd unwary unwary % cargo build # no warning issued about problem in the brash dependency. Compiling brash v0.1.0 Compiling unwary v0.1.0 (/tmp/unwary) Finished dev [unoptimized debuginfo] target(s) in 0.30s unwary % cd ../brash brash % cargo build # (but a brash developer will see it when they build.) Compiling brash v0.1.0 (/tmp/brash) warning: borrow of packed field is unsafe and requires unsafe function or block (error E0133) -- src/lib.rs:13:9 | 13 | let y x.data.0; | ^^^^^^^^^ | note: #[warn(safe_packed_borrows)] on by default warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! note: for more information, see issue #46043 https://github.com/rust-lang/rust/issues/46043 note: fields of packed structs might be misaligned: dereferencing a misaligned pointer or even just creating a misaligned reference is undefined behavior Finished dev [unoptimized debuginfo] target(s) in 0.30s brash %也就是说brash的维护者自己构建时能看到警告但unwary的维护者构建项目时看不到任何提示——直到某个未来的 Rust 版本发布unwary直接编译失败。反馈不能只是原始诊断输出RFC 特别强调反馈不应仅仅是brash的原始诊断输出。unwary的维护者在短期内通常无法对上游 crate 的警告做任何事可以向brash提 issue 甚至贡献修复代码但在brash发布新版本之前这并不能解决眼前的问题。因此如果 Cargo 直接把上游的诊断一股脑铺在终端里对unwary的维护者而言只是噪音。正确做法是继续对上游依赖传递--cap-lintsallow同时让rustc通过某种渠道告诉 Cargo哪些 crate 触发了未来不兼容 lint再由 Cargo 在构建结束时给出简洁的汇总报告。提案总览保留 cap-lints增加汇总报告RFC 2834 的设计目标可以概括为三条继续传递--cap-lintsallow非 path 上游依赖的正常 lint 仍被封顶不改变既有行为。rustc上报触发信号即使警告被抑制rustc也要通过某种通道告知 Cargo 未来不兼容 lint 被触发了。cargo汇总反馈在构建结束时输出一份精炼报告列出哪些 crate 包含未来会被拒绝的代码并可选给出解决建议。RFC 还设想 Cargo 可以额外提供解决策略的反馈例如查询本地 index看上游 crate 是否有更新版本可用若有则建议用户通过cargo update升级这只是一种启发式手段并不会预先验证新版本是否真的解决了问题若 Cargo 未运行在 offline 模式也可进一步查询 crates.io 本身但查询 index 在实践中通常已足够建议提交 bug提示unwary维护者到上游 crate 的源码仓库提交或搜索已归档的 issuebrash作者可能自己都不知道这个问题——例如他在该 lint 随编译器发布之前就停止了维护标注截止时间rustc为每个未来不兼容 lint 内嵌距离变成硬错误还有多久的信息让维护者知道还有多少时间窗口去推动上游修复或更换 fork。这些建议的具体形式不在 RFC 的强制范围内详见后文未来可能性一节。用户视角构建结束时的报告形态什么是未来不兼容RFC 给出的定义未来不兼容future incompatibility是指计划在未来某个 Rust 版本中从语言中移除的代码模式。这类模式通常是无未定义行为但语义未完全定义、或确实 unsound 的构造但因为被广泛使用需要一段宽限期再移除。构建结束报告在 Cargo 完成一个 crate 及其上游依赖的编译后如果任何 crate或其上游依赖触发了未来不兼容警告、且整体编译没有错误Cargo 会在编译结束阶段列出所有触发该警告的 crate可能时报告还会包含预计 Rust 停止编译该代码的未来日期或版本号crates % cd unwary unwary % cargo build Compiling brash v0.1.0 Compiling bold v0.1.0 Compiling rash v0.1.0 Compiling unwary v0.1.0 Finished dev [unoptimized debuginfo] target(s) in 0.30s warning: the crates brash, bold, and rash contain code that will be rejected by a future version of Rust. note: the crate rash will stop compiling in Rust 1.50 (scheduled for February 2021). note: to see what the problems were, invoke cargo describe-future-incompatibilities unwary %注意这里报告的是crate 名级别的汇总而非逐个表达式的诊断这正是 RFC 刻意设计的简洁形态。依赖图中的多重版本如果当前 crate 的依赖图中存在同一 crate 的多个版本被列入了结束报告那么结束报告应明确指出是哪个或哪些版本触发了 lint。这对cargo tree里常见的传递依赖版本分叉场景至关重要——维护者需要知道该去升级哪一条依赖链。cargo describe-future-incompatibilities查看详细诊断报告末尾的 note 提示用户调用cargo describe-future-incompatibilities。该命令会让 Cargo 查询上一次构建缓存的信息打印出更有信息量的诊断unary % cargo describe-future-incompatibilities The brash crate currently triggers a future incompatibility warning with Rust, with the following diagnostic: warning: borrow of packed field is unsafe and requires unsafe function or block (error E0133) -- src/lib.rs:12:9 | 12 | let y x.data.0; // UB, also future-compatibility warning | ^^^^^^^^^ | note: #[warn(safe_packed_borrows)] on by default warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! note: for more information, see issue #46043 https://github.com/rust-lang/rust/issues/46043 note: fields of packed structs might be misaligned: dereferencing a misaligned pointer or even just creating a misaligned reference is undefined behavior The bold crate currently triggers a future incompatibility warning with Rust, with the following diagnostic: warning: private type foo::m::S in public interface (error E0446) -- src/lib.rs:5:5 | 5 | pub fn f() - S { S } | ^^^^^^^^^^^^^^^^^^^^^ | note: #[warn(private_in_public)] on by default warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! note: for more information, see issue #34537 https://github.com/rust-lang/rust/issues/34537 The rash crate currently triggers a future incompatibility warning with Rust, with the following diagnostic: error: defaults for type parameters are only allowed in struct, enum, type, or trait definitions. -- src/lib.rs:4:8 | 4 | fn barTi32(x: T) { } | ^ | note: #[deny(invalid_type_param_default)] on by default warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! note: for more information, see issue #36887 https://github.com/rust-lang/rust/issues/36887这个汇总报告 按需查看明细的两级设计让想搞清楚问题的开发者有路可循又不会用他们本地开发用不上的信息淹没所有人的诊断输出。重编译时报告仍会保留即使上游依赖没有重新编译重建unwary时结束报告依然会输出——因为 Cargo 会把未来不兼容状态缓存在target/目录中unwary % touch src/main.rs unwary % cargo build Compiling unwary v0.1.0 Finished dev [unoptimized debuginfo] target(s) in 0.30s warning: the crates brash, bold, and rash contain code that will be rejected by a future version of Rust. note: the crate rash will stop compiling in Rust 1.50 (scheduled for February 2021). unwary % note: to see what the problems were, invoke cargo describe-future-incompatibilities根 crate 自身触发时的一致性为了用户体验一致即使根 crate 自己是触发未来不兼容 lint 的唯一来源Cargo 也应在结束阶段发出同样的警告此时构建过程中的原始警告依然照常显示crates % cd brash brash % cargo build Compiling brash v0.1.0 (/tmp/brash) warning: borrow of packed field is unsafe and requires unsafe function or block (error E0133) -- src/lib.rs:13:9 | 13 | let y x.data.0; | ^^^^^^^^^ | note: #[warn(safe_packed_borrows)] on by default warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! note: for more information, see issue #46043 https://github.com/rust-lang/rust/issues/46043 note: fields of packed structs might be misaligned: dereferencing a misaligned pointer or even just creating a misaligned reference is undefined behavior Finished dev [unoptimized debuginfo] target(s) in 0.30s warning: the crate brash contains code that will be rejected by a future version of Rust. brash % cargo build Finished dev [unoptimized debuginfo] target(s) in 0.00s warning: the crate brash contains code that will be rejected by a future version of Rust. note: to see what the problems were, invoke cargo describe-future-incompatibilities brash %注意第二次构建增量、无编译发生依然输出了警告印证了报告依赖缓存、不依赖重建的设计。无警告时输出不变如果没有任何未来不兼容警告Cargo 的输出与今天完全一致。例如unwary升级了brash的版本、切换到bold2bold的 fork、并用本地代码替换了对rash的使用从而消除了所有触发点crates % cd unwary unwary % cargo build Compiling brash v0.2.0 Compiling bold2 v0.1.0 Compiling unwary v0.2.0 Finished dev [unoptimized debuginfo] target(s) in 0.30s unwary %参考级设计rustc与 Cargo 的职责划分RFC 2834 的核心约束是最小化对现有 Rust 用户的干扰正常 lint 检查继续被抑制因此 Cargo 继续对非 path 上游依赖传递--cap-lintsallow。-Dwarnings语义保持不变与 lint 直接交互的标志如-Dwarnings行为不变。以unwary为例无论是cargo rustc -- -Dwarnings还是RUSTFLAGS-Dwarnings cargo build每次rustc调用的方式都相同产出的诊断集合也与今天一致下游brash这个非 path 依赖中的警告 lint 依旧被 cap其未来不兼容警告仍被隐藏Cargo 在构建结束时输出的brash包含未来将被拒绝的代码报告不是 lint不与-Dwarnings交互结论即使你向rustc传了-Dwarnings收到未来不兼容报告也不会导致构建失败。rustc的职责编译器侧的行为会有轻微变化即使在--cap-lintsallow开启的情况下rustc也需要让 Cargo 知道未来不兼容 lint 何时被触发。具体而言rustc必须把未来不兼容 lints参见 PR #59658 Minimum Lint Levels与那些永远只是警告的普通 lints 区分开来rustc需要一种新的操作模式RFC 称之为future-incompatibility checking mode未来不兼容检查模式在该模式下无论是否设置了--cap-lintsallow都要检查未来不兼容 lints 的触发在该模式下无论代码是否出现在#[allow(..)]属性作用域内也要检查这类 lint在该模式下诊断本身的输出仍可按--cap-lintsallow或#[allow(..)]被静默——这些标志/注解的语义是静默诊断报告但不是静默关于源码中存在 lint 触发实例的反馈该模式旨在解决 rust-lang/rust#34596 的主体问题。Cargo 的职责以启用未来不兼容检查模式的方式调用rustc——无论是否同时传递--cap-lintsallow捕获检查模式产出的任何输出并在整个构建结束时汇总将每个 crate 的未来不兼容记录存储在target/目录某处从而在后续重建根 crate 时无需重编译即可输出同样报告RFC 指出这在今天是容易满足的约束nightly 渠道的 Cargo 已经在本地缓存构建上游 path 依赖时产生的警告向用户建议解决问题的途径具体策略不由本 RFC 强制规定。实现策略借助 JSON 错误格式RFC 认为最干净的实现方式是让rustc把--error-formatjson视作应当为当前 crate 输出未来不兼容汇总报告的信号——扩展rustc的 JSON 输出加入一条记录本次编译触发过的未来不兼容 lint 的新记录。选用 JSON 的好处在于JSON 记录更易于扩展可以稳健地承载该 lint 何时变为硬错误这类元数据。不过 RFC 并不强制这一选择其他选项包括使用环境变量 opt-in 改变rustc输出或让rustc把未来不兼容元数据写入文件系统。不是所有未来不兼容 lint 都有明确的变为硬错误时间表。RFC 假设会通过某种方式为它们建立排期并要求每个未来不兼容 lint 的元数据都应包含若已知其变为硬错误的预期 Rust 版本——这也是采用 JSON 诊断的另一层动机。相关政策考量RFC 指出不应盲目地把所有 lint 都纳入这套机制——当前被归类为C-future-incompatibility的 lint 并非都适合此机制这是相关团队的政策决策具体形态不在 RFC 范围内。无论政策形式如何有一点值得注意遇到上游未来不兼容问题的用户可能既没有空闲时间也没有外部开发资源。rustc开发者需要谨慎决定何时让某个 lint 开始通过该机制上报如果首要目标是最大程度减少用户对工具和生态的挫败感那么某个 lint 的未来不兼容上报应等到生态中大部分 crate 都已发布修复版本之后再开启换句话说应当追求一种稳态典型用户面对未来不兼容报告时的反应是运行cargo update或请求合并一个已存在的PR。频率控制.cargo/config的future_incompatibility_report配置每次构建都提醒对某些用户可能过于打扰——短期无法解决被标记的问题是很常见的。因此 RFC 提议扩展.cargo/config文件让用户微调 Cargo 打印报告的频率。完整的提议配置如下[future_incompatibility_report] # This setting can be used to reduce the frequency with which Cargo will report # future incompatibility issues. # # The possible values are: # * always (default): always emit the report if any future incompatibility # lint fires, # * never: never emit the report, # * post-cargo-update: emit the report the first time we encounter a given # future incompatibility lint after the most recent # cargo update run for a crate, # * daily: emit the report the first time any particular lint fires each day, # * weekly: emit the report the first time any particular lint fires # each week (starting from Monday, following ISO 8601), # * lunar: emit the report the first time any particular lint fires every # four weeks. (We recommend using this value in tandem with # an IDE that presents the current phase of the moon in its UI.) frequency always # This allows a further fine-tuning for lints that have been given an # explicit schedule for when they will be turned into hard errors. # # If false, such scheduled lints are treated the same as unscheduled ones. # # If true, such scheduled lints issue their report more frequently # as time marches towards the release date when the warning becomes an error. # # Specifically, # * 6 weeks before that release, the report is emitted at least once per week, # * 2 weeks before that release, the report is emitted on every build. # # (Note that a consequence of the above definition, this value of this setting # has no effect if the future_incompat_report_frequency is always.) telescoping_schedule true逐项解读frequency可选值为always默认只要有未来不兼容 lint 触发就报告、never永不报告、post-cargo-update自最近一次对该 crate 执行cargo update之后首次遇到某个未来不兼容 lint 时报告一次、daily每个 lint 每天首次触发时报告、weekly每周首次触发时报告从周一开始遵循 ISO 8601、lunar每四周首次触发时报告RFC 调侃建议配合一个能显示月相的 IDE 使用telescoping_schedule针对有明确变为硬错误排期的 lints 进一步微调。为false时有排期的 lint 与无排期的同等对待为true时随着发布日临近报告越发频繁——发布前 6 周起至少每周报告一次发布前 2 周起每次构建都报告。注意当frequency always时该设置不产生额外效果。RFC 明确表示它并不真正规定上述键值集合而是信任 Cargo 团队来确定向用户暴露哪些合适的旋钮。这种设计授权也让最终实现可能与 RFC 文字略有出入。缺陷与权衡Drawbacks该变更同时要求修改rustc和cargo两者协调可能比较棘手RFC 建议的松耦合方式是使用--error-formatjson即启用未来不兼容检查模式这避免了给rustc增加新的稳定命令行标志但任何使用--error-formatjson的非 Cargo 客户端可能觉得这是编译器语义上令人困惑的变化。备选方案辨析Rationale and alternatives不做改变可行吗有人认为现有做法一直在工作无需改变。RFC 的反驳是之所以至今没爆发恰恰是因为编译器和语言团队在把现有未来不兼容 lint 转为硬错误时被迫非常保守——这种转变成本极高而这在很大程度上正是本 RFC 要解决的那个问题。在少数已经转为硬错误的案例中团队花费了大量时间用 crater 评估破坏面并逐一修复。本 RFC 的变更希望能鼓励编译器/语言团队之外的更多 Rust 用户主动处理未来不兼容的破坏。能否仅靠 Cargo 实现一种思路是不改rustc、把实现完全隔离在 Cargo 内停止传--cap-lintsallow让 Cargo 捕获编译器的全部诊断输出并事后处理、判断哪些 lint 是未来不兼容警告。但这有三大问题脆弱依赖 Cargo 事后处理编译器的诊断输出低效编译器现在必须为 crate 的所有依赖运行全部 lint 检查而我们只关心其中一小部分不足它只能处理--cap-lints的场景无法捕捉上游依赖在源码中用#[allow(..)]属性规避警告的情况——而如果为了弥补这点去无条件改变rustc、让它无论--cap-lintsallow还是#[allow(..)]都输出未来不兼容反馈又会惹恼那些期望这些标志/注解让诊断输出保持安静的人也就是编译器不听我的。这正是 RFC 坚持--cap-lintsallow与#[allow(..)]继续静默诊断报告、仅把反馈限定为一句crate brash 包含未来会被拒绝的代码的原因。能否仅靠 rustc 实现PR #59658 Minimum Lint Levels 曾尝试在编译器内单独解决做法是把未来不兼容 lint 标记为特殊情形、使其不受--cap-lints和#[allow(..)]静默。该 PR 的讨论列举了诸多问题本质上是担心下游开发者被自己无能为力的 lints 刷屏。讨论的结论是可以重做以降低刷屏——对每个依赖只报告 lint 的一次实例而非该依赖中每个触发该 lint 的表达式各一条诊断。这确实是改进但仍不是理想体验。本 RFC 刻意把未来不兼容 lint 触发视为独立于普通诊断的严肃事件值得 Cargo 特殊对待甚至可能在线查询该 crate 是否有新版本。注意最低 lint 等级机制与本 RFC 不冲突可以并行推进只是它不足以单独解决眼前的问题。扩展cap-lints层级是否更好另一个低影响方案是扩展--cap-lints的层级使其变成allow warn-future-incompat warn deny-future-incompat deny这样--cap-lintswarn-future-incompat表示允许不警告所有非未来不兼容 lint仅对未来不兼容 lint 警告--cap-lintsdeny-future-incompat表示对非未来不兼容 lint 警告、对未来不兼容 lint 报错。并且关键一步把cargo build的默认值改为cap-lintswarn-future-incompat让开发者默认就能直接得知依赖中的未来不兼容。RFC 作者选择不采用该方案因为怀疑它会遭遇与minimum lint levels相同的困境抛出一堆开发者无法立即在本地解决的诊断。不过它仍可能是值得加入rustc和cargo的合理功能。未解决的问题Cargo 自身发出的未来不兼容警告如 rust-lang/cargo#6313 评论中所讨论的应当被纳入支持作者设想这不需要太多额外工作但未明确处理也未深入调研实现层面的问题用--error-formatjson作为把rustc切换进未来不兼容检查模式的方式是否合理一个变体是改用--json CONFIG选项让 Cargo opt-in 该功能——这样已经使用--error-formatjson的客户端就无需感知这一变化。未来可能性Cargo 给出的修复建议RFC 设想的主要后续工作是 Cargo 围绕问题给出的反馈建议列举了两种形态。查询 crate 的新版/替代版本当 crate 触发未来不兼容警告时Cargo 可以到 crates.io 上查找该依赖的更新版本crates % cd unwary unwary % cargo build Compiling brash v0.1.0 Compiling bold v0.1.0 Compiling rash v0.1.0 Compiling unwary v0.1.0 Finished dev [unoptimized debuginfo] target(s) in 0.30s warning: the crates brash, bold, and rash contain code that will be rejected by a future version of Rust. note: the crate rash will stop compiling in Rust 1.50 (scheduled for February 2021). note: newer versions of bold and rash are available; upgrading to them via cargo update may resolve their problems. unwary %该建议目前只覆盖升级到新版本。若得到 crates.io 的更多帮助还可以走得更远建议用户切换到的上游 crate 的潜在 fork——这对处理 abandoned无人维护的 crate 很有用。建议提交 bug report如果没有更新版本可用Cargo 可以输出一份用户可提交给上游 crate 的 bug report 模板crates % cd unwary unwary % cargo build Compiling brash v0.1.0 Compiling unwary v0.1.0 Finished dev [unoptimized debuginfo] target(s) in 0.30s warning: the crate brash contains code that will be rejected by a future version of Rust. note: the following gist contains a bug report you might consider filing with the maintainer of brash. https://gist.github.com/pnkfelix/ae03d3ea95160fb71a797b15e05f8d49 unwary %示例中模板被发布到 gist使用作者自己的 GitHub 账号RFC 坦言不确定能否让 Cargo 以匿名方式创建 gist但应该能找到某种 pastebin 服务。该模板的正文大致是这个 crate 目前触发了 Rust 的未来不兼容警告。 在 src/lib.rs:13:9 处有以下代码let y x.data.0;这导致rustc发出如下诊断来自 https://github.com/rust-lang/rust/issues/46043warning: borrow of packed field is unsafe and requires unsafe function or block (error E0133) ...由于该构造未来会变成硬错误我们应该消除它的出现。进一步细化如果开始建议 bug report 模板Cargo 或许还能在上游 crate 仓库中搜索与该模板描述匹配的既有 issue并建议用户去查看其当前状态而不是新开一个 issue——这样可以避免给上游维护者添麻烦。与仓库其他 RFC 的关联RFC 1193 cap-lints本 RFC 的基石。--cap-lints标志与Cargo 对上游依赖传--cap-lints allow的约定正是导致上游未来不兼容警告被隐藏的根源也是 RFC 2834 选择继续保留的机制RFC 1589 rustc-bug-fix-procedure展示了rustc侧如何注册未来不兼容 lint——通过store.register_future_incompatible(sess, vec![FutureIncompatibleInfo { id: LintId::of(..), reference: issue #.... }])把 lint 标记为FutureIncompatibleInfo。这正对应本 RFC 中rustc必须区分未来不兼容 lints 与其他 lints的职责要求RFC 3389 manifest lint其 Drawbacks 一节明确指出[lints]只影响关联包本身、不作用于依赖因此无法与针对依赖的未来不兼容 lints协同工作可能造成用户困惑——这从侧面印证了 RFC 2834 这类依赖级报告机制的必要性RFC 3874 与 RFC 3875均提及cargo reportRFC 2834 所述机制落地后的命令形态不会包含标准库 crate 及其依赖的报告说明这套报告机制在现代 Cargo 中已与 build-std 场景做了明确隔离。小结RFC 2834 为 Rust 生态解决了一个隐蔽而危险的定时炸弹问题上游依赖中的未来不兼容代码因cap-lints而被无声容忍直到某个 Rust 版本发布时项目猝然编译失败。它给出的答案是职责分离——rustc以 JSON 错误格式承载未来不兼容检查模式的信号Cargo 负责汇总、缓存target/目录与频率控制.cargo/config并把详细的逐 crate 诊断留给按需调用的cargo describe-future-incompatibilities。对于下游维护者这套设计把知道问题存在与不被原始诊断刷屏两件事同时做到了。赞分享文档【免费下载链接】rfcsRFCs for changes to Rust项目地址https://gitcode.com/gh_mirrors/rf/rfcs点击查看免费下载相关推荐Cargo 的 future-incompat 报告机制cargo report future-incompatibilities 命令全解析Cargo 的 future incompat 报告机制 cargo report future incompatibilities 命令全解析 导读 car开发工具包管理器CLI构建工具Rust RFCs 深度解析cargo install 与 cargo uninstall 的命令设计与实践RFC 1200Rust RFCs 深度解析cargo install 与 cargo uninstall 的命令设计与实践RFC 1200 本文以 Rust RFC 仓文档Rust RFC 2091 深度解读用 [track_caller] 让 unwrap()/expect() 报告真实调用位置Rust RFC 2091 深度解读用 track_caller 让 unwrap / expect 报告真实调用位置 本文以 Rust RFC 仓库中的 t文档上一篇BiliTools3分钟学会用这款开源工具箱管理你的B站收藏下一篇Cytoscape.js 集合过滤实战eles.filter() 选择器与函数两种过滤方式的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
