Rust 团队很高兴宣布 Rust 的最新版本 1.12.1。Rust 是一种系统编程语言,专注于可靠性、性能和并发性。
像往常一样,您可以从我们网站上的相应页面 安装 Rust 1.12.1,或者通过 rustup 使用 rustup update stable
安装。
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。确保这一切顺利进行,并进行一些练习,如果我们将来需要由于安全公告或其他任何原因发布某种紧急补丁版本,这将非常有用。
这是自 Rust 0.3.1 以来第一个 Rust 补丁版本,早在 2012 年,并且标志着自 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' panicked at 'assertion failed: concrete_substs.is_normalized_for_trans()' #36381
- 双重否定和布尔值的混淆
- rustc 1.12.0 在发布模式下出现 SIGSEGV 错误(syn crate 0.8.0)
- Rustc 1.12.0 的
ethcore
crate 的 Windows 版本在 LLVM 错误下失败 - 1.12.0:在发布模式下使用调试信息链接时,内存使用量很高
- 更新到 1.12 后内存损坏
- "Let NullaryConstructor = something;" 导致内部编译器错误:"试图覆盖已插入的 AdtDef"
- 修复 ICE:如果类型不匹配,则注入位转换以进行调用/调用/存储。
- debuginfo:在 MIR-trans 中以更稳定的方式处理 spread_arg 案例。
此外,还有四个回归问题,我们决定出于各种原因不将其包含在 1.12.1 中,但我们也会尽快着手修复这些问题。
- ICE,可能与关联类型的关联类型有关?
- 使用大型静态映射的 crate 的编译在最新的 i686-pc-windows-gnu Beta 版本上失败
- 回归:当使用 HRTB impl 两次调用相同方法时,出现“未找到方法”错误
- ICE:虚构类型 sizing_type_of
您可以 在这里 查看 1.12.0 到 1.12.1 的完整差异。