6 个版本
| 0.1.5 | 2023 年 5 月 10 日 |
|---|---|
| 0.1.4 | 2023 年 4 月 29 日 |
| 0.0.0-- |
|
| 0.0.0-0.0.0-0.0.0 |
|
#238 在 开发工具
每月 36 次下载
49KB
1K SLoC
目的
为 #[allow(...)] 本地代码检查权限/抑制提供别名。您可以拥有多个别名，每个别名都有自己的名称 - 语义。
问题
假设您在代码的多个地方对相同的代码检查（无论是 rustc 标准的前缀无代码检查，还是以 clippy:: 或 rustdoc:: 为前缀的代码检查）进行了允许，尽管是相同的代码检查，您可能有不同的允许原因。然而，#[allow(...)] 并不能传达您的意图。
不幸的是，我们也不能使用 use 来为代码检查创建别名。 (为什么？因为代码检查名称不是（过程）宏，而是特殊的编译器符号。)当然，您可以添加注释，但这是不确定的。
此crate为每个lint定义了一个属性宏（除了只适用于crate级别的lint，以下有更多说明）。这些宏不接受任何属性参数。它们将在你的代码前注入#[allow(lint-name-here)]。
你可以将相同的宏以所需的名字多次导入。例如
use allow::anonymous_parametersasallow_anonymous_params_legacy;use allow::rustdoc_missing_doc_code_examplesasallow_rustdoc_examples_linked;use allow::rustdoc_missing_doc_code_examplesasallow_rustdoc_examples_none_trivial;use allow::clippy_await_holding_lockasallow_clippy_await_holding_lock;
然后在你结构体/枚举/函数/变量等之前应用#[allow_anonymous_params_legacy]、#[allow_rustdoc_examples_linked]、#[allow_rustdoc_examples_none_trivial]、#allow_clippy_await_holding_lock（或你命名的名称），表明你的意图。
额外好处：Rust将验证（别名）名称，因此没有打字错误。因此，你可以在任何时候使用grep或搜索它们。你的团队可以有一个类似于导入模块的模块，或者crate，重新导出别名。
范围
在范围内
- Rust版本1.45、1.49.0、1.52.1、1.58.1、1.61.0、1.69.0、1.70.0-beta.1、1.71.0-nightly以及可能的一些，但似乎不是所有中间版本。请参阅下文的"范围外"。
stable和nightly（但我们可能需要你的帮助来维护）。rustclints（无前缀的“标准”）；clippy::&rustdoc::lints。但主要是当前lint。- Clippy：版本
allow0.1.0支持Rust 1.45`的所有Clippy lints。作者正在添加新的lint（并指定已弃用/删除的lint的版本范围）。
范围有限
-
针对Rust
1.63以下（直到1.45）的负构建测试。如果我们使用ui_testcrate进行测试，我们只能从Rust 1.63完全测试。或者，你能帮助使用trybuildcrate实现负构建测试吗？对于那些较低版本的Rust，lints（宏）也进行了验证。需要Rust
1.63+的测试覆盖了用于较低Rust版本的功能。这意味着：这是经过充分测试的。 -
Rustdoc 自动生成的 lint 宏文档无法提及在 Rust 中被别名的原始 lint，如下所示
1.54。我们能做的最好的是：“别名为#[allow(...)]，与从 allow 或 allow_prefixed 导入的具有相似名称的 lint。” -
自
1.45以来的所有可能的 Rust 版本都提供支持。根据 Rust 版本添加 lints（宏）、标记它们为过时以及删除它们并不是自动化的。错误是会发生的。请帮助我们报告并修复它们。好消息：多亏了我们的测试套件，任何错误的修复都意味着仅扩展兼容 Rust 版本的范围（针对任何特定 lint），而绝不会限制范围。因此，任何修复都具有向下兼容性。
不在此范围内
-
一些 Rust 版本，如 1.63、1.65.0、1.66.1、1.67.0、1.67.1、1.68.0、1.68.2（至少对于主流 x64 Linux 目标：
x86_64-unknown-linux-gnu）不支持某些rustc（标准、无前缀）lint，尽管这些 lint 在某些早期和后期版本中都存在。但是，中间的一些主要版本可能可以工作。而且，一些旧版本 是 受支持的。请参见上文。 -
lint 组（如
#[allow(unused)]）。确实，它们有其位置（例如：快速原型设计）。但它们与这个 crate 的目的相反：区分忽略相同 lint 的用例。 -
仅适用于 crate 级别（“内部”）的属性。它们不与
#[allow(...)]一起工作，但仅与#![allow(...)]一起工作，并且仅在 crate 级别。这意味着（在一般情况下）比在代码周围散布的#[allow(...)]有更少的重复（粒度更细）。---- <- TODO
您可以点赞 rust-lang/rust #54726。假设它被实现了。然而，顶级属性可能需要放在任何
use别名之前，因此我们无法对生成#![allow(...)]宏的别名进行别名化，不幸的是——没有语义上的好处。（我们可以在其他模块或crates中对其别名化，并且可以不带任何use导入来调用它们——使用完全限定路径，例如#![our_allow_crate::lints::non_ascii_idents_legacy]或#![crate::lints::non_ascii_idents_third_party]。待定。） -
Beta版本的rustc特定。Beta版本的孵化只有 6 周。或者，你会帮忙维护这个吗？ -
Rust 版本早于
1.45。如果有高需求，我们可能支持到1.31（由rustversioncrate 需要）。但那样，我们就会有丑陋且更复杂的进程宏。如果您想使用
allow，最可能的情况是您要抑制的lint非常普遍。因此，如果您选择重构这么多代码，您是否也希望将其升级到更新的Rust？ -
自定义lint（例如 使用 Dylint）。在原则上可能——您会承诺维护它吗？
报告问题和已知问题
测试还没有很好地覆盖 rustdoc:: 和 clippy::。并且 clippy:: lints 到 Rust 版本 1.45（目前）。
相关问题——请点赞
高效的进程宏
这确实使用了进程宏（特别是：属性宏）。很多：每个lint一个。
是的，进程宏通常会减慢编译速度。进程宏通常使用 syn 和 quote crates。这些都是强大的工具，它们解析和引用宏可以注入的代码。然而，它们的强大也伴随着成本：构建时间。
但是，这些宏的情况并非如此。 allow 并不会将新的（生成的）代码解析为 TokenStream（在它被注入使用之前）。相反，它通过 proc_macro API 进行组合。
测试确实有更多的依赖（如果我们继续使用 ui_test - 因为 trybuild 可能要快得多）。所以不要通过 cargo test 来判断其速度，而是通过 cargo build。此外，一些测试在 Windows 上无法运行 - 请参阅 CONTRIBUTING.md。当然，实际的项目包本身是平台无关的。
包、crates.io 和 GIT
该项目由四个包组成（可能还有一个第五个包可能会出现）。其中三个在 crates.io 上：allow、allow_impl 和 allow_internal。第四个包，allow_tests，不在 crates.io 上，因为它仅用于测试。（TODO 如果我们继续使用 ui_test，将不依赖于 ui_test 的部分移动到第五个包中，以便在 Rust 1.63 以下版本也能运行。）
它们都在同一个 GIT 仓库 下，这简化了维护。
贡献
请参阅 CONTRIBUTING.md。
你认识有人有
- 使用 https://github.com/dtolnay/trybuild 或 https://github.com/oli-obk/ui_test 的经验，或者
- 对 rustc（无前缀）的版本控制/规划/源代码生命周期有了解或参与，(较少的是
rustdoc::- 很少)，或者 (非常之多)clippy::的规则，或者 - 使用许多规则或频繁使用它们，并处理来自 rustc/rustdoc/clippy 的变更的经验吗？
许可协议
Allow 项目根据 MIT 许可协议和 Apache 许可协议（版本 2.0）的条款进行分发。
有关详细信息，请参阅 LICENSE-APACHE、LICENSE-MIT 和 COPYRIGHT。