Rust 团队很高兴地宣布 Rust 的最新版本 1.12.1。Rust 是一种系统编程语言,专注于可靠性、性能和并发性。
和往常一样,您可以从我们网站上的相应页面安装 Rust 1.12.1,或者使用 rustup update stable
通过 rustup 安装。
1.12.1 稳定版包含什么
等等...一点十二点...一点?
在几周前 1.12 的发布公告中,我们说过
1.12 的发布可能是自 1.0 以来最重要的 Rust 版本之一。
这是真的。最大的变化之一是启用了一个大型编译器重构,MIR,它重新架构了编译器的内部结构。整个过程是这样的
- 最初的 MIR 支持在 Rust 1.6 的 nightly 版本中落地。
- 在进行工作时,添加了一个标志
--enable-orbit
,以便从事编译器工作的人可以尝试它。 - 在 10 月份,我们总是会尝试构建 MIR,即使它没有被使用。
- 添加了一个标志
-Z orbit
,允许 nightly 版本上的用户尝试使用 MIR 而不是传统的编译步骤 ('trans')。 - 经过数月的广泛测试后,对于 Rust 1.12,我们默认启用了 MIR。
- 在 Rust 1.13 中,MIR 将是唯一的选择。
如此重大的变化是巨大且重要的。因此,正确地、小心地进行也很重要。这就是这个过程耗时如此之久的原因;我们定期针对 crates.io 上的每个 crate 测试编译器,我们要求人们在他们的私有代码上试用 -Z orbit
,并且在六周的 beta 测试后,没有出现重大问题。因此,我们决定在 1.12 中默认启用它。
但是,即使我们尽可能地降低了风险,大的改变仍然存在一定的风险。因此,在发布之后,1.12 出现了一些我们在测试中没有检测到的回归。并非所有这些都与 MIR 直接相关,但是当您如此大幅度地更改编译器内部结构时,它必然会向外扩散到所有方面。
为什么要发布一个点版本?
现在,考虑到我们有六周的发布周期,并且我们已经到了 Rust 1.13 的一半,您可能想知道为什么我们选择裁剪 Rust 1.12 的补丁版本,而不是告诉用户等待下一个版本。我们之前说过类似“点版本只应在极端情况下发生,例如标准库中的安全漏洞。”
Rust 团队非常关心 Rust 的稳定性,以及用户的使用体验。我们可以告诉你们所有人等待,但是我们想让您知道我们对此事的重视程度。我们认为,通过在此情况下发布点版本来表明我们对您的承诺是值得的。
此外,鉴于这与安全性无关,这是一个实际练习裁剪点版本的好时机。我们之前从未这样做过,发布过程是半自动化的,但仍然不是完全自动化。在世界上拥有一个点版本也将消除其他工具中处理点版本的任何错误,例如 rustup。确保一切顺利进行,并进行一些实践将非常有用,如果我们由于安全建议或其他任何原因而需要裁剪某种紧急点版本。
这是自 2012 年的 Rust 0.3.1 以来,Rust 的第一个点版本,并且标志着自 Rust 1.0 以来的 72 周,当时我们建立了六周的发布节奏以及对积极的稳定性保证的承诺。虽然我们对 1.12 出现这些回归感到失望,但我们对 Rust 的稳定性感到非常自豪,并将继续扩大我们的努力,以确保它是一个您可以依赖的平台。我们希望 Rust 成为世界上最可靠的编程平台。
关于在 beta 版本上进行测试的说明
作为 Rust 的用户,您可以帮助我们更快地解决这些问题的一件事是:针对 beta 频道测试您的代码!每个 beta 版本都是下一个稳定版本的候选版本,因此,为了在 CI 中进行额外的构建,您可以帮助我们了解在它到达稳定版本之前是否存在某种问题!这真的很容易。例如,在 Travis 上,您可以将此用作您的 .travis.yml
language: rust
rust:
- stable
- beta
并且您将同时针对两者进行测试。此外,如果您希望任何 beta 测试失败不会导致您自己的构建失败,请执行此操作
matrix:
allow_failures:
- rust: beta
beta 构建可能会变红,但您的构建将保持绿色。
大多数其他 CI 系统,例如 AppVeyor,都应支持类似的功能。请查阅您的特定持续集成产品的文档以获取完整详细信息。
完整详细信息
1.12.1 中修复了九个问题,所有这些修复也都已向后移植到 1.13 beta 版。
- ICE: 'rustc' 在 'assertion failed: concrete_substs.is_normalized_for_trans()' #36381 处崩溃
- 双重否定和布尔值混淆
- rustc 1.12.0 在发布模式下失败并出现 SIGSEGV (syn crate 0.8.0)
- Rustc 1.12.0 Windows 构建
ethcore
crate 失败并出现 LLVM 错误 - 1.12.0:在发布模式下使用调试信息链接时,内存使用率很高
- 更新到 1.12 后内存损坏
- "Let NullaryConstructor = something;" 导致内部编译器错误:"tried to overwrite interned AdtDef"
- 修复 ICE:如果 invokes/calls/stores 的类型不匹配,则注入 bitcast
- debuginfo:以更稳定的方式处理 MIR-trans 中的 spread_arg 情况。
此外,出于各种原因,我们决定不将另外四个回归包含在 1.12.1 中,但是我们也将尽快修复这些回归。
- ICE,可能与关联类型的关联类型有关?
- 在最新的 i686-pc-windows-gnu Beta 版上,使用大型静态映射的 crate 的编译失败
- 回归:当两次调用相同的方法时,出现“找不到方法”错误,并带有 HRTB impl
- ICE:虚构类型 sizing_type_of
您可以在 这里 查看从 1.12.0 到 1.12.1 的完整差异。