The Rust team is happy to announce a new version of Rust, 1.60.0. Rust is a programming language empowering everyone to build reliable and efficient software.
If you have a previous version of Rust installed via rustup, you can get 1.60.0 with:
$ rustup update stableIf you don't have it already, you can get rustup
from the appropriate page on our website, and check out the
detailed release notes for 1.60.0 on GitHub.
If you'd like to help us out by testing future releases, you might consider updating locally to use
the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!
Support for LLVM-based coverage instrumentation has been stabilized in rustc. You can try this out on your code by rebuilding your code with -Cinstrument-coverage, for example like this:
RUSTFLAGS="-C instrument-coverage" cargo buildAfter that, you can run the resulting binary, which will produce a
default.profraw file in the current directory. (The path and filename can be
overridden by an environment variable; see
documentation
for details).
The llvm-tools-preview component includes llvm-profdata for processing and
merging raw profile output (coverage region execution counts); and llvm-cov
for report generation. llvm-cov combines the processed output, from
llvm-profdata, and the binary itself, because the binary embeds a mapping from
counters to actual source code regions.
rustup component add llvm-tools-preview
$(rustc --print sysroot)/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-profdata merge -sparse default.profraw -o default.profdata
$(rustc --print sysroot)/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-cov show -Xdemangler=rustfilt target/debug/coverage-testing \
-instr-profile=default.profdata \
-show-line-counts-or-regions \
-show-instantiationsThe above commands on a simple helloworld binary produce this annotated report, showing that each line of the input was covered.
1| 1|fn main() {
2| 1| println!("Hello, world!");
3| 1|}For more details, please read the
documentation in the
rustc book. The baseline functionality is stable and will exist in some form
in all future Rust releases, but the specific output format and LLVM tooling which
produces it are subject to change. For this reason, it is important to make
sure that you use the same version for both the llvm-tools-preview and the
rustc binary used to compile your code.
cargo --timingsCargo has stabilized support for collecting information on build with the --timings flag.
$ cargo build --timings
Compiling hello-world v0.1.0 (hello-world)
Timing report saved to target/cargo-timings/cargo-timing-20220318T174818Z.html
Finished dev [unoptimized + debuginfo] target(s) in 0.98sThe report is also copied to target/cargo-timings/cargo-timing.html. A report on the release build of Cargo has been put up here. These reports can be useful for improving build performance.
More information about the timing reports may be found in the documentation.
This release introduces two new changes to improve support for Cargo features and how they interact with optional dependencies: Namespaced dependencies and weak dependency features.
Cargo has long supported features along with optional dependencies, as illustrated by the snippet below.
[dependencies]
jpeg-decoder = { version = "0.1.20", default-features = false, optional = true }
[features]
# Enables parallel processing support by enabling the "rayon" feature of jpeg-decoder.
parallel = ["jpeg-decoder/rayon"]There are two things to note in this example:
jpeg-decoder implicitly defines a feature of the same name. Enabling the jpeg-decoder feature will enable the jpeg-decoder dependency."jpeg-decoder/rayon" syntax enables the jpeg-decoder dependency and enables the jpeg-decoder dependency's rayon feature.Namespaced features tackles the first issue. You can now use the dep: prefix in the [features] table to explicitly refer to an optional dependency without implicitly exposing it as a feature. This gives you more control on how to define the feature corresponding to the optional dependency including hiding optional dependencies behind more descriptive feature names.
Weak dependency features tackle the second issue where the "optional-dependency/feature-name" syntax would always enable optional-dependency. However, often you want to enable the feature on the optional dependency only if some other feature has enabled the optional dependency. Starting in 1.60, you can add a ? as in "package-name?/feature-name" which will only enable the given feature if something else has enabled the optional dependency.
For example, let's say we have added some serialization support to our library, and it requires enabling a corresponding feature in some optional dependencies. That can be done like this:
[dependencies]
serde = { version = "1.0.133", optional = true }
rgb = { version = "0.8.25", optional = true }
[features]
serde = ["dep:serde", "rgb?/serde"]In this example, enabling the serde feature will enable the serde dependency. It will also enable the serde feature for the rgb dependency, but only if something else has enabled the rgb dependency.
Incremental compilation is re-enabled for the 1.60 release. The Rust team continues to work on fixing bugs in incremental, but no problems causing widespread breakage are known at this time, so we have chosen to reenable incremental compilation. Additionally, the compiler team is continuing to work on long-term strategy to avoid future problems of this kind. That process is in relatively early days, so we don't have anything to share yet on that front.
Instant monotonicity guaranteesOn all platforms Instant will try to use an OS API that guarantees monotonic
behavior if available (which is the case on all tier 1 platforms). In practice
such guarantees are -- under rare circumstances -- broken by hardware,
virtualization, or operating system bugs. To work around these bugs and platforms
not offering monotonic clocks, Instant::duration_since, Instant::elapsed and
Instant::sub now saturate to zero. In older Rust versions this led to a panic
instead. Instant::checked_duration_since can be used to detect and handle
situations where monotonicity is violated, or Instants are subtracted in the
wrong order.
This workaround obscures programming errors where earlier and later instants are accidentally swapped. For this reason future Rust versions may reintroduce panics in at least those cases, if possible and efficient.
Prior to 1.60, the monotonicity guarantees were provided through mutexes or
atomics in std, which can introduce large performance overheads to
Instant::now(). Additionally, the panicking behavior meant that Rust software
could panic in a subset of environments, which was largely undesirable, as the
authors of that software may not be able to fix or upgrade the operating system,
hardware, or virtualization system they are running on. Further, introducing
unexpected panics into these environments made Rust software less reliable and
portable, which is of higher concern than exposing typically uninteresting
platform bugs in monotonic clock handling to end users.
The following methods and trait implementations are now stabilized:
Arc::new_cyclicRc::new_cyclicslice::EscapeAscii<[u8]>::escape_asciiu8::escape_asciiVec::spare_capacity_mutMaybeUninit::assume_init_dropMaybeUninit::assume_init_readi8::abs_diffi16::abs_diffi32::abs_diffi64::abs_diffi128::abs_diffisize::abs_diffu8::abs_diffu16::abs_diffu32::abs_diffu64::abs_diffu128::abs_diffusize::abs_diffDisplay for io::ErrorKindFrom<u8> for ExitCodeNot for ! (the "never" type)Assign<$t> for Wrapping<$t>arch::is_aarch64_feature_detected!There are other changes in the Rust 1.60.0 release. Check out what changed in Rust, Cargo, and Clippy.
Many people came together to create Rust 1.60.0. We couldn't have done it without all of you. Thanks!
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。