Rust 1.51.0 已正式发布，及其新特性详述 - 云上于天 - 泥芹

NiQin (blog: 泥芹) shared the aphorism --

失败只有一个原因，把做产品看作实现自己梦想的方式。但产品本质是帮他人解决问题，别人需要什么你就要做什么，而不是我只做我喜欢的。你的产品做到了你心中的最好，被你视若珍宝，但对别人没有任何特殊之处。 -- 佚名

[Rust] Rust 1.51.0 已正式发布，及其新特性详述

2021-03-26 03:45:22+08:00 by - NiQin [blog: 泥芹]

💥 内容涉及著作权，均归属作者本人。若非作者注明，默认欢迎转载：请注明出处，及相关链接。

Summary: Rust 1.51.0 稳定版，展示了相当长的时段内，Rust 语言和 Cargo 工具的特性迭代，稳定了最具价值的常量泛型（const generics），以及 Cargo 的新特性 `resolver`。另外，还包括适用于 macOS 的拆分调试信息、已稳定 APIs，以及 Clippy 工具的诸多改进。

Topics: rust rust-官方博客 cargo

2021 年 3 月 25 日，Rust 版本团队官宣发布新版本：1.51.0。

Rust 是一种编程语言，它赋能每个人都能够构建可靠和高效的软件。

如果您已通过 rustup 安装了早期版本的 Rust，那么获取 Rust 1.51.0 就很容易（各平台通用命令）：

rustup update stable

如果官网下载速度过慢，参考配置 Rust 工具链的国内源。

安装成功后，可以查看 rustc 和 cargo 版本：

rustc -V; cargo -V
    rustc 1.51.0 (2fd73fabe 2021-03-23)
    cargo 1.51.0 (43b129a20 2021-03-16)

如果您未安装过 Rust，可以从 Rust 官网页面获取 rustup，并可以在 GitHub 站点查看 Rust 1.51.0 的详细发行说明。

Rust 1.51.0 稳定版的新特性

Rust 1.51.0 稳定版，展示了相当长的时段内，Rust 语言和 Cargo 工具的特性迭代，稳定了最具价值的常量泛型（const generics），以及 Cargo 的新特性 resolver。让我们详细看一看：

常量泛型（Const Generics）最具价值

Rust 1.51.0 版本之前，Rust 允许您在生命周期（lifetime）或类型（type）中对您的具体类型进行参数化。例如，如果我们想定义一个结构体（struct），其字段类型为具有泛型元素的数组。我们可以编写以下代码：

struct FixedArray<T> {
              // ^^^ 泛型定义
    list: [T; 32]
        // ^ 使用泛型
}

若我们要使用 FixedArray<u8>，编译器将构造 FixedArray 的单态版本。如下所示：

struct FixedArray<u8> {
    list: [u8; 32]
}

这是一个强大的特性，允许您编写可重用的代码，并且无需运行时开销。但是，在 Rust 1.51.0 版本之前，很难将这些类型的值（value） 泛型化。对于类型定义（[T; N]）中包含长度的数组而言，这一点尤为明显，以前您无法对其泛型。现在使用 1.51.0，您在编程中，可对任意整数类型、布尔型（bool），或 char 类型做到泛型！

使用结构体（struct）或枚举（enum）值时，仍然不稳定。

有了这项改进，现在我们可以自定义数组结构体，它的类型和长度都是泛型的。让我们看一个定义数组结构体的示例，以及如何使用它。

struct Array<T, const LENGTH: usize> {
    //          ^^^^^^^^^^^^^^^^^^^ 常量泛型定义
    list: [T; LENGTH]
    //        ^^^^^^ 使用常量泛型
}

现在，如果我们使用 Array<u8, 32>，编译器将构造一个单态版本的 Array。如下所示：

struct Array<u8, 32> {
    list: [u8; 32]
}

常量泛型为类库设计人员带来了一个重要的新工具，以便于他们创建新的、强大的编译时安全 APIs。如果你想了解更多关于常量泛型的信息，你也可以查看博客文章最具价值的“常量泛型”特性测验，了解更多关于这个特性的信息，及其当前限制。

`array::IntoIter` 已稳定

作为常量泛型稳定化的一部分，Rust 团队还稳定了一个使用常量泛型特性的新 API：std::array::IntoIter，IntoIter 允许您在任何数组上创建值迭代器。以前的版本没有一种方便的方法来迭代数组的所有值，仅是引用它们。

fn main() {
  let array = [1, 2, 3, 4, 5];
  
  // 旧版本
  for item in array.iter().copied() {
      println!("{}", item);
  }
  
  // Rust 1.51.0 新版本
  for item in std::array::IntoIter::new(array) {
      println!("{}", item);
  }
}

请注意，IntoIter 是作为一个单独的方法添加的，而不是替代数组上的原有方法 .into_iter()，这是因为目前的 .into_iter() 方法有一些不足；目前，.into_iter() 方法是切片引用迭代器。Rust 团队正在探索，未来将使其更符合人体工程学。

Cargo 新特性 `resolver`

依赖项管理，是一个困难的问题。其中最困难的部分之一，是当依赖项被两个不同的包所依赖时，选择使用哪个版本的依赖项。这不仅包括它的版本号，还包括被包所启用，或未启用的特性。Cargo 的默认行为是：在依赖关系图中，当单个包被多次引用时，合并该包的特性。

例如，假设您有一个名为 foo 的依赖项，它的特性是 A 和 B，bar 和 baz 正在使用这个依赖项，但是 bar 依赖于 foo+A，baz 依赖于 foo+B。Cargo 将合并这两个特性，并将 foo 编译为 foo+AB。这样做的好处是，您只需编译 foo 一次，然后它就可以被 bar 和 baz 重用。

然而，这也带来了不利的一面。如果在构建依赖项时，启用的特性与您构建的目标（target）不兼容怎么办？

生态系统中，一个常见示例是：许多 #![no_std] crate 中包含可选的 std 特性，其允许 crate 在 std 可用时提供附加功能。现在想象一下，你想在 #![no_std] 的可执行文件中，使用用 foo 的 #![no_std] 版本，并在您 build.rs 编译时，使用 foo。如果编译时，依赖项依赖于 foo+std，那么可执行文件现在也依赖于 foo+std，这意味着它将不再编译，因为 std 对目标平台不可用。

在 cargo 中，这是一个长期存在的问题。Rust 1.51.0 版本中，Cargo.toml 中将有一个新的可选域 resolver。您可以通过设置 resolver="2"，来告诉 cargo 尝试一种新的方式来解析特性。您可以查看 RFC 2957 以获得 resolver 行为的详细描述，其总结如下。

Dev dependencies — 当包被普通依赖项和开发依赖项所共享，仅当当前编译包含开发依赖项时，才启用开发依赖项的特性。
Host dependencies — 当包被普通依赖项和编译依赖项，或过程宏共享时，普通依赖项的特性将独立于编译依赖项或过程宏。
Target dependencies — 当包在编译图中多次出现，并且其中一个实例是特定目标的依赖项，则仅当当前目标正在编译时，才会启用特定目标的依赖项特性。

虽然，这可能会导致一些 crate 编译不止一次，但在对 cargo 使用特性时，这将提供更直观的开发体验。如果您想了解更多信息，还可以阅读 Cargo 文档中的“Resolver 特性”部分。我们要感谢 cargo 团队和所有参与者，在设计和实现新的解析器过程中的辛勤工作！

[package]
resolver = "2"
# 或者，你使用 workspace
[workspace]
resolver = "2"

拆分调试信息

虽然在以往的版本发布中不经常强调，但是 Rust 团队一直在努力改进 Rust 的编译时间。Rust 1.51.0 版本，是 Rust 在 macOS 上长期以来最大的改进之一。调试信息将二进制代码映射回源代码，这样程序就可以提供有关运行时出错的更多信息。在 macOS 中，以前的调试信息，是使用一个名为 dsymutil 的工具收集到一个单独的 .dSYM 文件夹中，这可能需要一些时间，并占用大量磁盘空间。

将所有调试信息收集到此目录，有助于在运行时找到它，特别是在二进制文件被移动时。但是，它确实有一个缺点：即使您对程序做了一个小的更改，dsymutil 也需要运行整个二进制文件，以来生成最终的 .dSYM 文件夹。有时这样做会增加很多编译时间，特别是对于大型项目，因为所有依赖项都会被重新收集。但这又是必要的步骤，因为没有收集和编译，Rust 的标准库将不知道如何在 macOS 上加载调试信息。

最近，Rust 回溯（backtraces）已切换，将使用不同的后端，该后端支持在不需要运行 dsymutil 的情况下加载调试信息。并且，对跳过 dsymutil 运行的支持，已经稳定了。这可以显著提升包含调试信息的编译速度，并显著减少磁盘空间量的使用。虽然，Rust 团队还没有运行过广泛的基准测试，但是已经看到了很多关于在 macOS 上使用这种行为后的报告，反映编译速度提升很大。

在运行 rustc 时，您可以通过设置 -Csplit-debuginfo=unpacked 标志，或者将可选项 split-debuginfo [profile] 设置为 unpacked，用来在 Cargo 中启用此新行为。“unpacked” 选项指示 rustc 将 .o 对象文件保留在编译时的输出目录中，而不是删除它们，并跳过运行 dsymutil 的步骤。Rust 的回溯支持非常聪明，知道如何找到这些 .o 文件。lldb 等工具也知道如何做到这一点。只要你不需要在保留调试信息的同时，将二进制文件移动到其它位置，就应该可以这样做。

[profile.dev]
split-debuginfo = "unpacked"

已稳定 APIs

总体来讲，可以看到，这次发布有 18 种不同类型的新方法已经稳定，比如 slice 和 Peekable。值得注意的补充是稳定的 ptr::addr_of! 和 ptr::addr_of_mut!，它允许您创建指向未对齐（unaligned）字段的原始指针。以前这是不可能的，因为 Rust 要求 &/&mut 对齐，并指向已经初始化的数据，而 &addr as *const _ 将导致未定义的行为，因为 &addr 需要对齐。这两个宏现在允许您安全地创建未对齐（unaligned）指针。

use std::ptr;

#[repr(packed)]
struct Packed {
    f1: u8,
    f2: u16,
}

let packed = Packed { f1: 1, f2: 2 };
// `&packed.f2` 将创建一个未对齐（unaligned）引用，因此是不确定的行为！
let raw_f2 = ptr::addr_of!(packed.f2);
assert_eq!(unsafe { raw_f2.read_unaligned() }, 2);

下述方法已经稳定：