2021 年路线图

摘要

本路线图概述了 Clippy 在 2021 年的计划

  • 提高可用性和可靠性
  • 改善贡献者和维护者的体验
  • 开发并规范流程

Clippy 团队的成员将从上述一个或多个主题中分配任务。然后，团队成员负责完成分配的任务。这可以通过实施它们或向感兴趣的贡献者提供指导来完成。

动机

随着 Rust 语言以及整个生态系统的不断发展，Clippy 的用户和贡献者也越来越多。这对项目有利，但也带来了一些挑战。其中一些挑战是：

  • 关于可靠性或可用性的问题越来越多
  • 对于一个小团队来说，流量很难处理
  • 由于缺乏流程和/或团队成员的时间，更大的项目无法完成

此外，根据 Rust 2021 年路线图，每个团队都应定义明确的流程，并在团队之间统一。本路线图是朝着这一目标迈出的第一步。

解释

本节将解释 2021 年应该完成的事情。需要注意的是，本文档侧重于“是什么？”，而不是“如何做？”。后者将在后续的跟踪问题中解决，并分配给团队成员。

以下分为两个主要部分。第一部分涵盖面向用户的计划，第二部分涵盖内部计划。

面向用户

Clippy 应该尽可能地易于使用和配置。本节涵盖了为改善 Clippy 在这方面的状况而应实施的计划。

可用性

以下是有关提高可用性的计划。

cargo check 后没有输出

目前，当在 cargo check 之后运行 cargo clippy 时，它不会产生任何输出。这尤其成问题，因为 rust-analyzer 正在兴起，并且它使用 cargo check 来检查代码。修复程序已经实现，但仍需要完成最后的工作。这还包括稳定 cargo clippy --fix 命令或在 rustfix 中支持多跨度建议。

lints.toml 配置

这是一个不时出现的问题：一个可重用的配置文件，可以在其中定义 lint 级别。关于此的讨论通常不会得出任何具体结果，或者会说“我们需要为此发布一个 RFC”。而这正是需要完成的事情。与 cargo 团队合作编写一个 RFC，并在某个地方以某种方式实现这样的配置文件。

Lint 组

关于在 Clippy 中管理 lint 的问题越来越多。在保证没有/很少误报 (FP) 的情况下，lint 很难实现。解决此问题的一种方法可能是引入更多的 lint 组，使用户能够更好地管理 lint，或改进 lint 的分类过程，以便因误报而禁用 lint 的情况变得罕见。需要注意的是，Clippy lint 不如 rustc lint 保守，这在未来不会改变。

可靠性

以下是有关提高可靠性的计划。

误报率

在最坏的情况下，新的 lint 仅在 nightly 版本中可用 2 周，然后进入 beta 版本，最终进入 stable 版本。这种情况以及现在使用 nightly Rust 的人减少的事实使得具有许多误报的 lint 更容易进入 stable 版本。这会导致用户恼火，他们会在最好的情况下禁用这些新的 lint，而在最坏的情况下，则会导致更多恼火的用户停止使用 Clippy。应开发并实施一个流程以防止这种情况发生。

内部

2020 年（末）表明，Clippy 必须考虑可用资源，尤其是在项目的管理和维护方面。本节讨论影响团队成员和贡献者的问题。

管理

2020 年，Clippy 达到了 1000 多个未解决的问题，并且通常有 25-35 个未解决的 PR。这既是胜利也是损失。更多的问题和 PR 意味着更多的人对 Clippy 感兴趣，并愿意为其做出贡献。另一方面，对于团队成员来说，这意味着更多的工作，对于贡献者来说，则意味着更长的审查等待时间。以下将描述如何改善团队成员和贡献者状况的计划。

明确团队成员的期望

根据 Rust 2021 年路线图，应生成一份文档，说明成为团队成员的意义。这不应给团队成员带来更大的压力，而是应帮助他们和感兴趣的人了解期望是什么。有了这一点，招募新的团队成员也应该更容易，并且如果他们有兴趣加入，可能会鼓励人们联系。

扩大团队规模

更多的人意味着每个人承担的工作更少。除了有关团队成员期望的文档外，还应生成一份文档，定义如何加入团队的过程。如果当前成员（暂时）退出，这也可以提高团队的稳定性。团队中也可以有不同的角色，例如人员分类和人员审查。

定期会议

其他团队有定期会议。Clippy 足够大，也值得这样做。特别是如果更多的人加入团队，这对同步更新很重要。除了异步通信（对于处理单独的 lint 非常有效）之外，会议还会在已知的时间添加同步的替代方案。如果需要讨论更大的事情（如本路线图中的项目），这尤其有帮助。对于初学者，在 Rust 同步之前举行双周会议可能是有意义的。

分类

为了处理涌入的未解决问题，应制定一个对问题和 PR 进行分类的流程。官方而言，Clippy 遵循 Rust 分类流程，但目前没有人强制执行。可以通过在项目之间共享分类团队或通过实施简化分类的仪表板/工具来改进这一点。

开发

改善开发人员和贡献者的体验是 Clippy 团队定期努力的目标。尽管如此，有些事情可能需要特别注意和计划。以下列出了这些主题。

新 lint 和现有 lint 的流程

如上所述，对新 lint 进行分类变得相当困难，因为有问题的 lint 进入 stable 的可能性很高。应实施一个关于如何对 lint 进行分类的流程。此外，应开发一个测试系统，以找出哪些 lint 在现实世界的代码中存在问题，以便修复或禁用它们。

流程

与之前的观点相关，应实施一个用于建议和讨论重大变更的流程。当默认情况下应启用或禁用 lint 时，也没有明确的定义。可以通过上述测试系统来改进这一点。

开发工具

已经存在 cargo dev，这使得 Clippy 的开发更加轻松愉快。这仍然可以扩展，以便涵盖开发过程的更多领域。

贡献者指南

与描述如何使用 Clippy 的 Clippy Book 类似，一本关于如何为 Clippy 做出贡献的书籍可能对新的和现有的贡献者有帮助。Clippy 存储库中已经有 doc 目录，可以将其转换为 mdbook。

rustc 集成

最近，Clippy 通过 git subtree 集成到了 rust-lang/rust 存储库中。这使得两个存储库之间的同步更容易。仍然可以改进的 #[non_exhaustive] 列表如下：

  1. 使用与 rustc 相同的 rustfmt 版本和配置。
  2. 使 cargo dev 在 Rust 存储库中工作，就像它在 Clippy 存储库中工作一样。例如，cargo dev bless 或 cargo dev update_lints。甚至可以向其中添加更多可能对 Rust 存储库有用的内容，例如 cargo dev deprecate。
  3. 更简单的同步过程。subtree 的情况并不理想。

优先级

Clippy 用户最紧迫的问题当然是面向用户的问题。因此，应优先考虑这些问题，但同时也不应忽略本文档中列出的内部问题。

将 warn/deny-by-default lint 的误报率控制在一定范围内应具有最高的优先级。其他面向用户的问题也应获得高优先级，但不应妨碍解决内部问题。

为了更好地管理即将到来的项目，应尽快建立基本的内部流程，如会议、跟踪问题和文档。它们甚至可能对于妥善管理有关面向用户问题的项目是必要的。

现有技术

Rust 路线图

Rust 的路线图流程由 2016 年的 RFC 1728 建立。从那时起，每年都会发布一个路线图，定义未来几年的更大计划。今年的路线图可以在 此处 找到。

缺点

大型路线图

此路线图非常大，并非本文档中列出的所有项目都可以在 2021 年解决。因为这是 Clippy 的第一个路线图，所以在 2021 年底有未完成的任务是可以接受的，但应在 2022 年的路线图中重新审视它们。