Announcing Rust 1.47.0

The Rust team is happy to announce a new version of Rust, 1.47.0.
Published At: 2021-01-17

What's in 1.47.0 stable

This release contains no new language features, though it does add one long-awaited standard library feature. It is mostly quality of life improvements, library stabilizations and const-ifications, and toolchain improvements. See the detailed release notes to learn about other changes not covered by this post.

Traits on larger arrays

Rust does not currently have a way to be generic over integer values. This has long caused problems with arrays, because arrays have an integer as part of their type; \[T; N\] is the type of an array of type T of N length. Because there is no way to be generic over N, you have to manually implement traits for arrays for every N you want to support. For the standard library, it was decided to support up to N of 32.

We have been working on a feature called "const generics" that would allow you to be generic over N. Fully explaining this feature is out of the scope of this post, because we are not stabilizing const generics just yet. However, the core of this feature has been implemented in the compiler, and it has been decided that the feature is far enough along that we are okay with the standard library using it to implement traits on arrays of any length. What this means in practice is that if you try to do something like this on Rust 1.46:

fn main() {     let xs = [0; 34];      println!("{:?}", xs); } 

you'd get this error:

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) 

But with Rust 1.47, it will properly print out the array.

This should make arrays significantly more useful to folks, though it will take until the const generics feature stabilizes for libraries to be able to do this kind of implementation for their own traits. We do not have a current estimated date for the stabilization of const generics.

Shorter backtraces

Back in Rust 1.18, we made some changes to the backtraces rustc would print on panic. There are a number of things in a backtrace that aren't useful the majority of the time. However, at some point, these regressed. In Rust 1.47.0, the culprit was found, and this has now been fixed. Since the regression, this program:

fn main() {     panic!(); } 

would give you a backtrace that looks like this:

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 

Now, in Rust 1.47.0, you'll see this instead:

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 

This makes it much easier to see where the panic actually originated, and you can still set RUST_BACKTRACE=full if you want to see everything.

LLVM 11

We have upgraded to LLVM 11. The compiler still supports being compiled with LLVM versions as old as 8, but by default, 11 is what you'll be getting.

Control Flow Guard on Windows

rustc now supports -C control-flow-guard, an option that will turn on Control Flow Guard on Windows. Other platforms ignore this flag.

Library changes

Additionally, nine new APIs were stabilized this release:

The following previously stable APIs have now been made const:

See the detailed release notes for more.

Other changes

Rustdoc has gained support for the Ayu theme.

There are other changes in the Rust 1.47.0 release: check out what changed in Rust, Cargo, and Clippy.

source:Link