Cargo 的本开发周期：1.78
我们想分享过去 6 周发生的事情，以便更好地让社区了解并参与其中。对于在周期结束时创建 beta 分支之前合并的工作，它将在接下来的 6 周内进入 Beta 通道，之后将普遍可用。
这与 Rust 本周 不同，因为它试图更多地关注全局，而不是单个 PR，并从更多来源（如 Cargo 团队会议和 Zulip）中提取信息。
这是寻找与社区更好互动方式的一次尝试，我们将看看它的效果如何以及我们能否跟上它的步伐。
本周期插件
Cargo 不可能满足每个人的需求，如果说有原因的话，那就是它必须坚持的兼容性保证。插件在 Cargo 生态系统中发挥着重要作用，我们希望庆祝它们。
我们本周期的插件是 cargo-sweep，它会删除未使用的构建文件。另请参阅 cargo-cache。有关 Cargo 内部的相关工作，请参阅 #12633。
感谢 LukeMathWalker 的建议！
实现
终端样式
虽然 Cargo 有 UI 测试，但它们没有验证终端样式，如颜色。Rustc 通过将 ANSI 转义码写入文本文件来管理此问题，这些文件在 cat stdout.log 之外很难可视化。在 #13461 中，epage 将 Cargo 的 UI 快照从文本移植到 SVG，从而可以捕获终端样式。为了实现这一点，他们创建了 anstyle-svg，以将 ANSI 转义码呈现为 SVG 中的样式（功劳归于 term-transcript 的原始想法），并将其集成到 snapbox 中 (trycmd#256)，我们使用它来快照我们的 UI 测试。
（不是屏幕截图，而是从 cargo 的输出生成的）
虽然这验证了 Cargo 的大部分终端样式，但我们无法强制在 --help 中启用样式以进行快照。虽然我们在 #12578 中向 --help 添加了样式，但我们忽略了它受 term.color 控制，因为这一切都发生在配置初始化之前。在 #13463 中，我们重构了 Cargo 的初始化，以便在解析命令行参数之前至少可以使用一些配置，从而允许 --help 受配置控制。这仍然使 cargo --color=never --help 不受支持 (#9012)。
在查看 SVG 快照时，我们发现 #12578 中被忽略的一些 CLI 帮助输出，并在 #13479 中对其进行了处理。
此后，rustc（感谢 estebank 在 rust#121877 中所做的工作）和 annotate-snippets（感谢 Muscraft 在 annotate-snippets-rs#86 中所做的工作）都采用了终端样式的 SVG 快照测试
用户控制的 Cargo 诊断
1.77 的更新。总之，此举旨在添加 用户控制的 lint，它们看起来像 rustc，并通过 [lints] 表 进行控制
我们在 SVG 快照测试中遇到的一个问题是 annotate-snippets，它是 Cargo 正在使用的类似 rustc 的诊断渲染器。Rustc 以及扩展的 annotate-snippets 为每个平台专门化了颜色，以最大程度地兼容 每个平台最常用终端使用的默认颜色。为了解决这个问题，我们必须在样式名称的位置放置快照通配符，这使得 SVG 的渲染效果与您在终端上获得的效果不同。Muscraft 向 annotate-snippets 添加了 testing-colors 功能，以强制跨平台测试时保持颜色一致 (annotate-snippets-rs#82)，从而使我们能够在所有平台上更好地匹配终端的 SVG。
为了准备将重点从 annotate-snippets 转移到 Cargo 的诊断系统，我们审查了 Cargo 用于生成 TOML 解析错误消息的代码，以便对 Cargo 和/或 annotate-snippets 应用任何清理。annotate-snippets 要求调用者处理列，但这取决于您要渲染的媒介的 UX 问题，因此 Muscraft 将 API 的重点转移到字节索引 (annotate-snippets-rs#90)。仍然存在许多复杂性需要提取消息的行，并将文档相关的范围转换为与行相关的范围。我们曾想知道是否可以使用 annotate-snippets 的“fold 未注释的行”机制来传入整个文件，并让 annotate-snippets 为我们完成。它在折叠文件的开头和结尾时存在一些不一致，因此在 annotate-snippets-rs#109 中，我们犯了一个错误，使调用者（如 Cargo）更容易使用。在从 Cargo 中删除行提取时，我们发现 Cargo 中有一个 hack 用于 annotate-snippets 如何突出显示 EOF，因此我们合并了 annotate-snippets-rs#107。
Muscraft 本来打算在研究 rustc 之前专注于 Cargo 采用 annotate-snippets。但是，有些人正在讨论在 GSoC 中为 rustc 工作 (zulip)。为了保持变更的分解，epage 重新检查了 API，着眼于 rustc 以及如何使其发展以适应我们遗漏的任何内容（主要是通过使用构建器模式）。请参阅 annotate-snippets-rs#94。我们还发现 API 中公开了一些我们之前抽象出来时忽略的实现细节 (annotate-snippets-rs#67)，Muscraft 在 annotate-snippets-rs#105 中修复了这些细节。
要了解这些更改如何简化调用者，请参阅
annotate-snippets 最初被引入 Cargo 是为了渲染 TOML 错误。这很容易实现，因为 toml 在 Error 上公开了 字节范围。对于 lint，我们将需要在文档上查找任意键和值的范围。toml 在反序列化期间公开范围，但这与 serde 存在一些阻抗失配，并且要求我们在整个 Cargo 中显式跟踪并转发我们关心的任何范围。作为替代方案，我们计划依赖一个非常糟糕的 serde hack，尽管重新解析 TOML 以查找每个范围会产生性能开销，但 dtolnay 指出了这一点。在考虑如何提高性能时，epage 为 toml_edit 设计了一个 API，允许查找文档中节点的范围，该 API 在 toml-rs#698 中实现。为了确保此信息可用于添加 lint 的位置，我们扁平化了用于解析清单的代码 (#13589)，以便我们可以将源和范围附加到整个 cargo 中使用的数据结构 (#13593)。
有了这些构建块，我们就可以开始 Cargo 的诊断系统了。
顺便提一下，为了有一天我们可以在诊断（和进度更新）中使用更精美的 unicode 字符，我们已将 cargo tree --charset 概括为配置 term.unicode，在 #13337 中。
性能
在 1.78 开发周期结束时，davidlattimore 在 加速 Rust 编辑-构建-运行周期 上发帖。这引起了 epage 对 Cargo 时间去向的好奇，并希望使用户更容易深入了解这一点。Cargo 有 --timings，但不包括 Cargo 的开销。还有一个 CARGO_PROFILE 环境变量，用于使 Cargo 捕获并转储几个特定阶段。受 git-branchless 的启发，epage 决定尝试在 Cargo 中支持 tracing-chrome，该功能在 #13399 中合并，并隐藏在 CARGO_LOG_PROFILE 环境变量 之后。
（渲染 cargo 构建的跟踪）
epage 在 cargo-nextest 上试用了此功能，并在 zulip 上记录了笔记。重要的是要注意，Cargo 的开销要么是每次运行的少量固定成本，要么是每个包更小的成本。这些可能会被 Rustc 淹没（如果您知道其他情况，请在该 zulip 线程 上告知我们！）。因此，epage 主要关注 cargo script 用例，特别是自从第三方前身经历了 在 Cargo 之上实现自己的缓存方案 的麻烦，以避免 Cargo 的开销。
最长的单次操作与 git2 相关。由于正在积极用 gitoxide 替换它 (进度报告)，我们倾向于放弃此操作，而不是通过推迟初始化工作来增加复杂性和风险。
另一个主要的开销来源是解析依赖项，特别是
- 解析
Cargo.toml文件 - 枚举推断的构建目标（特别是测试）
- 检查推断的构建目标（特别是测试）
在用户控制的诊断信息的重构基础上，为了访问 span，epage 正在努力在已发布的包的 Cargo.toml 中显式枚举推断出的构建目标。除了消除推断目标带来的开销之外，这将改进维护人员的错误信息（#13456），并使 crates.io 更容易在其前端添加更多功能（例如 crates.io#5882 和 crates.io#814）。
我们希望能够在此基础上进一步将 lint 延迟到清单解析之外，从而允许我们在针对依赖项时跳过 lint 分析（感谢 cap-lints）。
MSRV 感知的 Cargo
RFC #3537 在此开发周期的开始时通过了 FCP。这是一个经过激烈辩论的 RFC，对该 RFC 的发展方向存在许多截然不同的观点。为了帮助解决这场辩论，我们举行了扩展的 Office Hours，以便就此主题进行更高吞吐量的沟通。最终，Cargo 团队认为我们应该按原样推进该 RFC。Cargo 团队 发布 了
感谢大家的反馈！
您的参与帮助我们更好地了解人们使用 Cargo 的不同方式以及人们的需求是什么。我们认识到，对于如何满足用户需求，存在许多相互竞争的观点。
无论我们选择哪种方式，都有一个我们需要前进的时间点。然而，重要的是要记住，RFC 并非最终规范。特别是这个 RFC 将分阶段逐步稳定（
cargo new的更改可能会最后进行）。在准备稳定某个功能时，我们将考虑生态系统的变化以及来自测试不稳定功能的反馈。基于该评估，我们可能会对该 RFC 的内容进行更改。无论我们是否进行更改，稳定化都需要 cargo 团队的批准才能合并（所有成员中除 2 名外都明确承认，并且没有任何成员提出异议），然后是其余 2 名团队成员和更广泛社区的 10 天最终评论期 (FCP)。Cargo FCP 现在在 “This Week in Rust” 中进行跟踪，以确保社区在发生这种情况时知晓并可以参与。即便如此，像cargo new提出的更改也可以在没有 RFC 的情况下进行回滚，可能只需要遵循 FCP 流程即可。
不久之后，epage 跟进，充实了 cargo add 的版本要求自动选择功能，以便可以在 #13608 中使其稳定。
解析器工作的第一步是帮助用户了解依赖项已被保留。这不仅仅是一个 MSRV 感知解析器问题，而是一个 SemVer 感知解析器问题。为了谨慎地避免用信息淹没用户，epage 将其分解为一个单独的问题（#13539）以进行更集中的对话，并在 zulip 上开始了讨论。在 Cargo 团队会议中讨论这个问题时，我们决定继续推进，并将其合并到 #13561 中。
下一个可能产生争议的领域是如何组织和命名用于控制解析器的配置字段。这正在 #13540 中进行跟踪。
注册表身份验证
当添加对替代形式的注册表身份验证的支持时，纯文本凭据存储的默认值并未延续到替代注册表。这种差异至少使用户感到困惑（#13343）。在反思这个问题时，似乎应该弃用 cargo:token 内置凭据提供程序的隐式使用。用户可以通过显式选择加入来抑制弃用警告。
在准备弃用此功能时，epage 决定试用凭据提供程序的文档。第一件事是文档根据用户的平台推荐凭据提供程序。拥有一个与机器无关的配置更容易让用户维护，因此 epage 尝试合并所有条目，依赖于每个提供程序在不可用时声明自己不受支持（例如在非 Windows 平台上的 cargo:wincred）。但是，如果未安装 libsecret，则 cargo:libsecret 将会出错，而不是被跳过。在 zulip 和团队会议上进行了一些讨论后，创建了 #13558。
Git 扩展
arlosi 在一次会议上提出，如果 Cargo 位于使用 libgit2 不支持的功能的 git 存储库中，则无法使用 Cargo 构建。在这种特定情况下，问题是 Split Index。特别是，这会导致带有构建脚本的 vendoring 包出现问题，因为构建脚本的默认行为是，除非发出 cargo::rerun-if-changed，否则只要任何源代码发生更改，就会重新运行。他们目前正在通过修改 vendored 包使其具有一个 package.include 字段来解决此问题，该字段禁用了 Cargo 的 git 遍历。
这也将影响 cargo package。在讨论这个问题时，可能会出现的另一种情况是任何 cargo doc 调用，因为 rustdoc 与 rustc 不同，不会告诉 cargo doc 查看了哪些文件，因此 cargo doc 必须进行猜测。
一种选择是使用 ignore 包手动遍历目录。但是，这不仅仅是尊重 .gitignore，还要检查阶段。
这让我们面临以下选择
- 将目录扫描切换到 gitoxide，因为它支持 Split Index
- 包装
gitCLI，并隐式回退或创建一个类似于net.git-fetch-with-cli的配置，这不仅支持 Split Index，还支持 libgit2 或 gitoxide 等重新实现当前不支持的任何 git 扩展。 - 尝试逐步淘汰构建脚本中的隐式“扫描全部”，将修复限制在仅限此特定用例中。这将使用新的 Edition 完成。我们一直对使用 Edition 更改构建脚本犹豫不决，因为很多时候它们依赖于库来发出指令，这些指令可能在不同的 Edition 上。
Byron 介入并在 #13592 中提供了 gitoxide 实现。关于在 zulip 上稳定这项工作的讨论正在进行中。
垃圾回收
我们正在努力自动清理磁盘上的缓存。最初，我们从全局状态开始。这项工作正在 #12633 中进行跟踪。
作为向前迈出的一小步，ehuss 建议我们在 #13492 中稳定全局缓存跟踪。这将确保您的机器具有确定一旦我们稳定了这部分内容后要进行垃圾回收的缓存所需的历史数据。
默认 Edition
kpreid 在 Internals 上建议我们弃用依赖默认 Edition。如今，如果创建一个没有设置 package.edition 的 Cargo.toml，则 Cargo 将默认使用 2015 Edition。如果直接运行 rustc 而不传递 --edition（人们为了“快速实验”而这样做），情况也是如此。同样，有些人没有意识到 rustfmt 更像 rustc，需要 --edition 标志，而他们可能需要 cargo fmt 来尊重他们的 Cargo.toml edition。
如果我们弃用依赖默认 Edition，则可能会减少用户的困惑。这也将有助于 RFC #3502：cargo script，因为它以不同的方式定义了嵌入式清单的默认值：使用当前 Edition 但发出警告。发出警告和用户习惯于显式设置 Edition 将有助于消除其默认值差异。
Cargo 团队对此进行了讨论，并赞成继续推进，并在 #13505 中合并了此项。
虽然编译器团队得出不同的结论可能是合理的，但我们不希望 Cargo 在调用 rustc 时省略 --edition 来阻止他们，因此我们确保在 #13499 中始终传递它。
有时，很容易忽略为什么现有项目与新项目相比发展速度较慢。一个挑战是现有功能的负担。在这种情况下，它是这些功能的测试。要了解该负担是什么，请考虑在 #13504 中完成的手动测试更新，以解除此项工作的阻塞。
开放命名空间
最近，批准了 RFC #3243，这是 Rust 的一项重大转变。以前，库命名空间对扩展是封闭的。通过此 RFC，我们正在向允许受限扩展库命名空间的 Python 靠拢。您将能够将包命名为 foo::bar，使您的包成为 foo 命名空间的一部分。对此的一个主要限制是，crates.io 将让 foo 的所有者控制谁可以发布 foo::* 包。这对于 Clap、Bevy 或 Gitoxide 等具有大量具有独立版本控制的库，但作为一个整体发挥作用的项目很有用。从技术上讲，这可以用作注册表命名空间（将所有包命名为 my-org::*），但由于此功能并非为此用例而设计，因此它们可能会遇到阻抗不匹配的问题。
第一步，epage 在 Cargo 中实现了对此的初步支持，详见 #13591。你可以运行 cargo metadata，但是 cargo check 会失败。关于 cargo/编译器交互的讨论正在 rustc 的跟踪问题中进行。这个不稳定的功能被命名为 open-namespaces，希望能更具有语义上的明确性，以减少人们无意中认为这是注册表命名空间的情况。
设计讨论
已弃用的 Cargo.toml 字段
在审查一个 PR 时，epage 观察到贡献者访问了
manifest.dev_dependencies （用于 [dev-dependencies]），忽略了 manifest.dev_dependencies2 （用于 [dev_dependencies]）。考虑到 manifest.dev_dependencies 字段的显而易见的名称以及对 [dev_dependencies] 的不了解（甚至其他被调查的 Cargo.toml 解析器都不支持它），这是可以理解的。
这些字段的存在提醒我们，Cargo 团队内部就应该如何处理它们进行了讨论。
快速概览
| 预期 | 替代 | 如果使用替代项 | 如果两者都使用 |
|---|---|---|---|
package |
project |
已弃用，计划移除 | 警告 |
build-dependencies |
build_dependencies |
无 | 警告并说明替代项已弃用 |
dev-dependencies |
dev_dependencies |
无 | 警告并说明替代项已弃用 |
proc-macro |
proc_macro |
无 | 警告并说明替代项已弃用 |
crate-type |
crate_type |
无 | 警告并说明替代项已弃用 |
我们的计划是研究所有已弃用功能的使用情况，包括
- 何时引入的？
- 何时被取代的？
- 在 crates.io 上的使用有多普遍？
- 在生态系统中的使用有多普遍（Cargo 可能会在发布时规范化其中一些）？
我们的选项包括
- 警告它已弃用，但保留它
- 警告它在现有版本中已弃用，并禁止在未来版本中使用它
- 由于大多数替代方案的出现时间都足够早，我们假设不需要根据软件包声明的最低支持 Rust 版本 (MSRV) 来限制警告
- 发出警告，并在经过足够的时间后，移除该功能（仅限于我们认为超出兼容性保证范围的功能，例如当我们移除对解析无效清单的支持时，详见 #9932）
这正在 #13629 中进行跟踪，并在 zulip 上进行讨论。
RFC #3452：嵌套包
RFC #3452 将允许 cargo publish 将选定的 路径依赖项捆绑到已发布的软件包 .crate 文件中。这可以消除为 proc-macros 发布两个软件包的需求，或者允许将较大的软件包拆分为较小的编译单元，以加快增量重建速度。一个类似的想法在 2017 年以 RFC #2224 的形式发布，但被推迟了。在 2022 年，yoshuawuyts 在他们的帖子 内联 Crates 中从语言方面着手解决这个问题。
kpreid 解决了他们 RFC 中的其余反馈。与 T-cargo 和 T-crates-io 开启了讨论主题，希望在 FCP 之前发现其他需要解决的基本领域。
Cargo 团队就 RFC #3452 进行了高级别讨论，以衡量对此的普遍兴趣，以推动其前进。
提出的一个担忧是记录此过程的复杂性，尤其是在向用户提供有关何时使用构建目标、软件包、嵌套软件包或工作区的指导时（另请参见 何时使用软件包或工作区？）。
还存在潜在的意外副作用。如果我们不限制可以嵌套哪些依赖项，它可能会使供应链可追溯性更加困难，就像 SBOMS 一样，并可能使解决依赖项问题的解决方法成为快乐路径，而不是鼓励人们保持生态系统的高质量。
为什么被取消发布？
长期以来一直有人要求在运行 cargo yank 时允许包含消息 (#2608)。当我们允许在更多地方使用被取消发布的软件包时，这可能会变得更加重要（请参阅 1.77 中的 cargo update --precise <yanked>）。
hi-rustin 在 crates.io 团队会议上提出了这个问题。事实证明，他们正在为他们的管理员管理功能考虑类似的东西。那么 Cargo 应该如何获取和报告这些信息呢？
从 crates.io 获取信息的第一个工具是 索引，我们使用它来解析依赖项。我们还为以这种方式扩展 Cargo 的注册表支持铺平了道路，而不会对第三方注册表产生负面影响。但是，我们通常将索引限制为依赖项解析所需的内容。这主要是出于性能/磁盘空间的原因。使用 Git 索引，你必须下载整个索引。使用稀疏索引可以改进这一点，你只需下载正在考虑的软件包，但仍然是所有版本。然后我们必须解析这些条目以查找相关版本。
为此辅助的、更可变的元数据创建一个额外的数据库需要更多前期工作，但这可能会给我们带来其他好处。我们还可以使用此数据库的其他一些方式包括
- 未维护状态（与 rustsec 重叠）
- 弃用状态（crates.io#7146），特别是如果你可以指向一个替代方案（例如 rustsec 的“未维护”），例如，帮助
structopt用户发现他们的升级路径是切换到clap，类似于rlua到mlua - 为因删除错误兼容性 hacks 而导致的构建失败做好准备 (rust#106060)
- 甚至可能允许第三方注册表为 依赖项解析挂钩分发规则
目前，我们倾向于 cargo yank 能够向注册表提供此信息，并且 crates.io 存储此信息并将其报告给用户。稍后，我们可以探索我们希望 Cargo 如何使用此信息。届时，我们可以使用 crates.io 的数据库回填 Cargo 使用的任何数据库。
Cargo 的 Linter
去年在 zulip 上，我们讨论了 Cargo lints 应该放在哪里，是全部放在 cargo 中并作为每个命令的一部分运行，还是其中一些应该放在专用的 linter 命令中。一个出现的想法是，其中一些 lints 应该放在 cargo clippy 中，特别是 cargo 子命令，而不是 clippy-driver，这是所有 clippy lints 当前所在的位置（包括一些 cargo lints）。
在 1.78 的开发开始时，当一位贡献者希望在 clippy 中实现另一个 Cargo lint 时，这个问题再次出现 (clippy#10306)。正如在 zulip 上讨论的那样，其中一个挑战是获取 lint 所需的信息。cargo metadata 实际上并不是用来暴露这些较低级别详细信息的，因此这需要在 clippy-driver 中重新实现 Cargo 的部分内容。 cargo-util-schema 的存在有所帮助，但并没有解决所有问题。如果 lint 可以在 cargo clippy 内部实现，并且 cargo clippy 依赖于 cargo 作为库，或者被烘焙到 Cargo 中，那么它将可以访问所有现有的机制，从而更容易在 Cargo 发展时保持最新。
有关潜在 lints 的列表，不考虑它们是否会放在 cargo 中还是显式的 lint 命令中，请参见
当 clippy 退出“预览”时，将 cargo-clippy 直接烘焙到 cargo 中的想法出现了，当时被 Cargo 团队拒绝了（从人们的记忆中）。除了必须定义在未安装 clippy-driver 时的语义之外，cargo 团队还将接管另一个团队的命令的所有权，并使我们减少了对一流、复杂的外部子命令的自检。
还有一个问题是，为什么 lint 应该每次都运行，而不是在显式的 lint 操作中运行。正如在 性能 中讨论的那样，lint 分析可能会有明显的开销。这也为 lints 提供了一个试验场，并提供了默认情况下更主观的机会。
深入研究 rustc 开发指南 和 clippy 书，为这次讨论提供了大量有用的信息，并且当我们向 cargo 添加 lints 时，即使“为什么”并不总是明确说明。特别是，有关于 rustc lints、clippy lints 和将 clippy lints 过渡到 rustc lints 的指导。
在我们继续讨论事物的归属之前，我们仍然需要从 clippy 团队那里获得更多背景信息。
弱特性语法
RFC #3491 计划在下一个版本中过渡掉隐式特性。在 #10556 中提出的另一个特性更改是通过使 dep/feature 始终为弱依赖，来过渡掉弱依赖语法 (dep?/feature)。最近在 zulip 上讨论了这个问题。
当你希望特性激活依赖项的特性时，可以使用 dep/feature 语法。如果依赖项也是可选的，这也会激活该依赖项。弱特性语法 (dep?/feature) 允许你仅在依赖项以其他方式激活时才激活特性。这种情况的常见用例是如果你有一个 serde 特性，并且你希望在你的可选依赖项中启用 serde 特性。换句话说，"foo/serde" 与 "dep:foo", "foo?/serde" 相同。
我们怀疑这可能会令人困惑，并且减少语法量会更优雅，但尚不清楚这在实践中对用户来说有多大的问题，这对于权衡过渡成本非常重要。
我们也可以通过首先弃用 foo/serde 语法来逐步淘汰它。这将更好地传达变化，并扩大征求反馈的窗口。我们可以将此弃用与软件包的 MSRV 联系起来，以便他们只有在可以选择更改时才会看到它。
在讨论令人困惑的语法时，出现的一个令人困惑的点是 dep:foo/serde 不受支持。
其他
- baby230211 修复了
cargo publish，使其在剥离 dev-dependencies 时，也会在 #13518 中剥离这些依赖项的激活。 - Muscraft 在 #13409 中进行了出色的工作，将
Config重命名为GlobalContext。 - epage 改进了 clap 的错误输出，以帮助用户了解如何将参数传递给包装的命令（如测试），详见 #13448。
未取得进展的重点领域
这些是 Cargo 团队成员感兴趣的领域，但在本开发周期中没有可报告的进展。
准备开发
- 将
cargo upgrade合并到cargo update - 工作区的
cargo publish - 自动生成补全
- 通用化 cargo 的测试断言代码
cargo update --precise与预发布依赖项
需要设计和/或实验
规划
- Cargo 脚本 (RFC #3502, RFC #3503)
- 禁用默认功能
- RFC #3416：
features元数据- RFC #3485：描述（descriptions）
- RFC #3487：可见性（visibility）
- RFC #3486：弃用
- 不稳定的功能
你如何提供帮助
如果您有改进 cargo 的想法，我们建议首先查看我们的积压问题，然后在Internals上探讨该想法。
如果此处未讨论您希望解决的特定问题，您可以采取一些步骤来帮助推进它，包括：
- 总结现有的对话（示例：更好地支持 docker 层缓存，
Cargo.lock策略的更改，支持 MSRV 的解析器） - 记录其他生态系统的现有技术，以便我们可以在他人工作的基础上进行构建，并在有意义的情况下为用户提供熟悉的东西
- 记录 Cargo 中相关的问题和解决方案，以便我们了解我们是否正在解决正确抽象层的问题
- 在这些帖子的基础上，提出一个考虑到上述信息和 cargo 兼容性要求的解决方案（示例）
我们可以在 zulip 上帮助指导 S-accepted 问题的人们，您可以在贡献者办公时间与我们实时交谈。如果您希望帮助完成此处提到的大型项目之一，并且刚刚开始，修复一些问题将有助于您熟悉流程和期望，从而使事情更顺利地进行。 如果您想处理一个 没有导师 的问题，那么对您自己需要做的事情的期望将会更高。