Rust 1.47.0 发布

2020年10月10日

Rust 1.47.0 已经发布了,此版本引入了一个标准库功能,但整体上不包含任何新的语言特性,主要关注的是质量的改善、库的稳定以及工具链的改进等。

目前 Rust 没有办法对整型进行泛型,这会导致数组出现问题,因为数组的类型部分包含整型。比如 [T; N] 是长度为 N 的 T 型数组的类型,因为无法进行 N 泛型,所以必须为每个要支持的 N 手动实现数组的 traits。现在有一个新特性“const generics"用于解决这一问题,可以让 N 进行泛型。此功能的核心已在编译器中实现,意味着如果尝试在 Rust 1.46 上执行以下操作:

fn main() {
    let xs = [0; 34];

    println!("{:?}", xs);
}

会返回错误:

error[E0277]: arrays only have std trait implementations for lengths 0..=32
 --> src/main.rs:4:22
  |
4 |     println!("{:?}", xs);
  |                      ^^ the trait `std::array::LengthAtMost32` is not implemented for `[{integer}; 34]`
  |
  = note: required because of the requirements on the impl of `std::fmt::Debug` for `[{integer}; 34]`
  = note: required by `std::fmt::Debug::fmt`
  = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

但是 1.47.0 中,则可以正常输出数组。不过该特性还不稳定。

此版本另一项改进是现在有更加精简的 panic 回溯,以往如下程序:

fn main() {
    panic!();
}

将输出如下回溯信息:

thread 'main' panicked at 'explicit panic', src/main.rs:2:5
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1076
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1537
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:217
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:526
  11: std::panicking::begin_panic
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/libstd/panicking.rs:456
  12: playground::main
             at src/main.rs:2
  13: std::rt::lang_start::{{closure}}
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/libstd/rt.rs:67
  14: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
  15: std::panicking::try::do_call
             at src/libstd/panicking.rs:348
  16: std::panicking::try
             at src/libstd/panicking.rs:325
  17: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  18: std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  19: std::rt::lang_start
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/libstd/rt.rs:67
  20: main
  21: __libc_start_main
  22: _start

不过现在变成了更加容易找到 panic 原因的回溯信息:

thread 'main' panicked at 'explicit panic', src/main.rs:2:5
stack backtrace:
   0: std::panicking::begin_panic
             at /rustc/d6646f64790018719caebeafd352a92adfa1d75a/library/std/src/panicking.rs:497
   1: playground::main
             at ./src/main.rs:2
   2: core::ops::function::FnOnce::call_once
             at /rustc/d6646f64790018719caebeafd352a92adfa1d75a/library/core/src/ops/function.rs:227

此外,1.47.0 还升级到了 LLVM 11,编译器仍然支持使用早于 v8 的 LLVM 版本进行编译,但是默认情况下启用的是 v11。

另有一些库的改变/API 的稳定等信息,可以查看完整发布说明:

https://blog.rust-lang.org/2020/10/08/Rust-1.47.html

展开阅读全文
6 收藏
分享
加载中
精彩评论
这种编译型语言,包括C++,项目大了之后编译都是很慢的,你用C++编译一个GCC源码或QT源码试试看,至少要60多个小时。哈哈
2020-10-11 11:36
3
举报
rust早就有泛型了 go在设计之初就没打算弄泛型 现在想弄又不太好弄是最尴尬的
2020-10-21 04:25
2
举报
受不了
2020-10-10 11:54
2
举报
为什么新的语言的关键字 和声明都要重新来一套?兼容老的声明和关键字 减少学习成本不好吗?
2020-10-21 09:03
1
举报
80核心就别来说了 双核小水管的苦你不懂
2020-10-21 04:26
1
举报
最新评论 (20)
vga
从编译速度角度来说:目前 Delphi 没有对手!!!
2020-10-21 09:47
0
回复
举报
为什么新的语言的关键字 和声明都要重新来一套?兼容老的声明和关键字 减少学习成本不好吗?
2020-10-21 09:03
1
回复
举报
看了go和rust解决泛型上的痛苦,才感叹c++泛型的强大
2020-10-21 00:01
0
回复
举报
rust早就有泛型了 go在设计之初就没打算弄泛型 现在想弄又不太好弄是最尴尬的
2020-10-21 04:25
2
回复
举报
屠龙少年终成恶龙
2020-10-10 19:50
1
回复
举报
简单的语言
2020-10-10 17:15
0
回复
举报
跌出前20了
2020-10-10 15:20
1
回复
举报
编译太慢了
2020-10-10 15:17
1
回复
举报
再慢也比c++快啊
2020-10-10 18:32
1
回复
举报
代码5分钟,编译2小时,要是编译能搞快点就完美了
2020-10-11 08:21
0
回复
举报
这种编译型语言,包括C++,项目大了之后编译都是很慢的,你用C++编译一个GCC源码或QT源码试试看,至少要60多个小时。哈哈
2020-10-11 11:36
3
回复
举报
好处就是性能和安全方面了,有利有弊
2020-10-11 11:41
1
回复
举报
怎么可能要60小时,我在一普通配置的服务器上跑一晚上就编译好了。
2020-10-13 22:21
0
回复
举报
回复 @Pader : 你确定?具体还是看配置 在普通i5/8g内存的笔记本上没有60小时是搞不定的 特别是mingw-gcc 要80小时 甚至更久
2020-10-14 07:26
1
回复
举报
回复 @WindSpeed : 非常确定,我是在公司的服务器上编译的,是老 E5 处理器。
2020-10-14 13:24
0
回复
举报
回复 @Pader : 那就对了 编译过程核心数越多的cpu速度越快 e5不管你是老的还是新的 至少也有个8核啥的吧 我用i5双核8g内存的笔记本编译 至少用了60多个小时
2020-10-16 04:59
1
回复
举报
公司服务器80核心160线程,几分钟就编好了.
2020-10-20 20:19
1
回复
举报
80核心就别来说了 双核小水管的苦你不懂
2020-10-21 04:26
1
回复
举报
我曾经编译一个东西,下午开始编译,第二天中午才编译完成。当时感觉这个是个噩梦。
2020-10-21 10:43
0
回复
举报
受不了
2020-10-10 11:54
2
回复
举报
更多评论
20 评论
6 收藏
分享
返回顶部
顶部