Announcing Rust 1.74.0

The Rust team is happy to announce a new version of Rust, 1.74.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.74.0 with:

rustup update stable

If 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.74.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!

What's in 1.74.0 stable

Lint configuration through Cargo

As proposed in RFC 3389, the Cargo.toml manifest now supports a [lints] table to configure the reporting level (forbid, deny, warn, allow) for lints from the compiler and other tools. So rather than setting RUSTFLAGS with -F/-D/-W/-A, which would affect the entire build, or using crate-level attributes like:

#![forbid(unsafe_code)]
#![deny(clippy::enum_glob_use)]

You can now write those in your package manifest for Cargo to handle:

[lints.rust]
unsafe_code = "forbid"

[lints.clippy]
enum_glob_use = "deny"

These can also be configured in a [workspace.lints] table, then inherited by[lints] workspace = true like many other workspace settings. Cargo will also track changes to these settings when deciding which crates need to be rebuilt.

For more information, see the lints and workspace.lints sections of the Cargo reference manual.

Cargo Registry Authentication

Two more related Cargo features are included in this release: credential providers and authenticated private registries.

Credential providers allow configuration of how Cargo gets credentials for a registry. Built-in providers are included for OS-specific secure secret storage on Linux, macOS, and Windows. Additionally, custom providers can be written to support arbitrary methods of storing or generating tokens. Using a secure credential provider reduces risk of registry tokens leaking.

Registries can now optionally require authentication for all operations, not just publishing. This enables private Cargo registries to offer more secure hosting of crates. Use of private registries requires the configuration of a credential provider.

For further information, see theCargo docs.

Projections in opaque return types

If you have ever received the error that a "return type cannot contain a projection or Self that references lifetimes from a parent scope," you may now rest easy! The compiler now allows mentioning Self and associated types in opaque return types, like async fn and -> impl Trait. This is the kind of feature that gets Rust closer to how you might just_expect_ it to work, even if you have no idea about jargon like "projection".

This functionality had an unstable feature gate because its implementation originally didn't properly deal with captured lifetimes, and once that was fixed it was given time to make sure it was sound. For more technical details, see the stabilization pull request, which describes the following examples that are all now allowed:

struct Wrapper<'a, T>(&'a T);

// Opaque return types that mention `Self`:
impl Wrapper<'_, ()> {
    async fn async_fn() -> Self { /* ... */ }
    fn impl_trait() -> impl Iterator<Item = Self> { /* ... */ }
}

trait Trait<'a> {
    type Assoc;
    fn new() -> Self::Assoc;
}
impl Trait<'_> for () {
    type Assoc = ();
    fn new() {}
}

// Opaque return types that mention an associated type:
impl<'a, T: Trait<'a>> Wrapper<'a, T> {
    async fn mk_assoc() -> T::Assoc { /* ... */ }
    fn a_few_assocs() -> impl Iterator<Item = T::Assoc> { /* ... */ }
}

Stabilized APIs

• core::num::Saturating
• impl Fromio::Stdout for std::process::Stdio
• impl Fromio::Stderr for std::process::Stdio
• impl From for std::process::Child{Stdin, Stdout, Stderr}
• impl From for std::process::Child{Stdin, Stdout, Stderr}
• std::ffi::OsString::from_encoded_bytes_unchecked
• std::ffi::OsString::into_encoded_bytes
• std::ffi::OsStr::from_encoded_bytes_unchecked
• std::ffi::OsStr::as_encoded_bytes
• std::io::Error::other
• impl TryFrom for u16
• impl<T: Clone, const N: usize> From<&[T; N]> for Vec
• impl<T: Clone, const N: usize> From<&mut [T; N]> for Vec
• impl<T, const N: usize> From<[T; N]> for Arc<[T]>
• impl<T, const N: usize> From<[T; N]> for Rc<[T]>

These APIs are now stable in const contexts:

• core::mem::transmute_copy
• str::is_ascii
• [u8]::is_ascii

Compatibility notes

• As previously announced, Rust 1.74 has increased its requirements on Apple platforms. The minimum versions are now:
  • macOS: 10.12 Sierra (First released 2016)
  • iOS: 10 (First released 2016)
  • tvOS: 10 (First released 2016)

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.74.0

Many people came together to create Rust 1.74.0. We couldn't have done it without all of you. Thanks!

Continue Reading…

Faster compilation with the parallel front-end in nightly

The Rust compiler's front-end can now use parallel execution to significantly reduce compile times. To try it, run the nightly compiler with the -Z threads=8 option. This feature is currently experimental, and we aim to ship it in the stable compiler in 2024.

Keep reading to learn why a parallel front-end is needed and how it works, or just skip ahead to the How to use itsection.

Compile times and parallelism

Rust compile times are a perennial concern. The Compiler Performance Working Grouphas continually improved compiler performance for several years. For example, in the first 10 months of 2023, there were mean reductions in compile time of13%, in peak memory use of15%, and in binary size of7%, as measured by our performance suite.

However, at this point the compiler has been heavily optimized and new improvements are hard to find. There is no low-hanging fruit remaining.

But there is one piece of large but high-hanging fruit: parallelism. Current Rust compiler users benefit from two kinds of parallelism, and the newly parallel front-end adds a third kind.

Existing interprocess parallelism

When you compile a Rust program, Cargo launches multiple rustc processes, compiling multiple crates in parallel. This works well. Try compiling a large Rust program with the -j1 flag to disable this parallelization and it will take a lot longer than normal.

You can visualise this parallelism if you build with Cargo's--timings flag, which produces a chart showing how the crates are compiled. The following image shows the timeline when building ripgrep on a machine with 28 virtual cores.

There are 60 horizontal lines, each one representing a distinct process. Their durations range from a fraction of a second to multiple seconds. Most of them are rustc, and the few orange ones are build scripts. The first twenty run all start at the same time. This is possible because there are no dependencies between the relevant crates. But further down the graph, parallelism reduces as crate dependencies increase. Although the compiler can overlap compilation of dependent crates somewhat thanks to a feature called pipelined compilation, there is much less parallel execution happening towards the end of compilation, and this is typical for large Rust programs. Interprocess parallelism is not enough to take full advantage of many cores. For more speed, we need parallelism within each process.

Existing intraprocess parallelism: the back-end

The compiler is split into two halves: the front-end and the back-end.

The front-end does many things, including parsing, type checking, and borrow checking. Until this week, it could not use parallel execution.

The back-end performs code generation. It generates code in chunks called "codegen units" and then LLVM processes these in parallel. This is a form of coarse-grained parallelism.

We can visualize the difference between the serial front-end and the parallel back-end. The following image shows the output of a profiler calledSamply measuring rustc as it does a release build of the final crate in Cargo. The image is superimposed with markers that indicate front-end and back-end execution.

Each horizontal line represents a thread. The main thread is labelled "rustc" and is shown at the bottom. It is busy for most of the execution. The other 16 threads are LLVM threads, labelled "opt cgu.00" through to "opt cgu.15". There are 16 threads because 16 is the default number of codegen units for a release build.

There are several things worth noting.

• Front-end execution takes 10.2 seconds.
• Back-end execution occurs takes 6.2 seconds, and the LLVM threads are running for 5.9 seconds of that.
• The parallel code generation is highly effective. Imagine if all those LLVM executed one after another!
• Even though there are 16 LLVM threads, at no point are all 16 executing at the same time, despite this being run on a machine with 28 cores. (The peak is 14 or 15.) This is because the main thread translates its internal code representation (MIR) to LLVM's code representation (LLVM IR) in serial. This takes a brief period for each codegen unit, and explains the staircase shape on the left-hand side of the code generation threads. There is some room for improvement here.
• The front-end is entirely serial. There is a lot of room for improvement here.

New intraprocess parallelism: the front-end

The front-end is now capable of parallel execution. It usesRayon to perform compilation tasks using fine-grained parallelism. Many data structures are synchronized by mutexes and read-write locks, atomic types are used where appropriate, and many front-end operations are made parallel. The addition of parallelism was done by modifying a relatively small number of key points in the code. The vast majority of the front-end code did not need to be changed.

When the parallel front-end is enabled and configured to use eight threads, we get the following Samply profile when compiling the same example as before.

Again, there are several things worth nothing.

• Front-end execution takes 5.9 seconds (down from 10.2 seconds).
• Back-end execution takes 5.3 seconds (down from 6.2 seconds), and the LLVM threads are running for 4.9 seconds of that (down from 5.9 seconds).
• There are seven additional threads labelled "rustc" operating in the front-end. The reduced front-end time shows they are reasonably effective, but the thread utilization is patchy, with the eight threads all having periods of inactivity. There is room for significant improvement here.
• Eight of the LLVM threads start at the same time. This is because the eight "rustc" threads create the LLVM IR for eight codegen units in parallel. (For seven of those threads that is the only work they do in the back-end.) After that, the staircase effect returns because only one "rustc" thread does LLVM IR generation while seven or more LLVM threads are active. If the number of threads used by the front-end was changed to 16 the staircase shape would disappear entirely, though in this case the final execution time would barely change.

Putting it all together

Rust compilation has long benefited from interprocess parallelism, via Cargo, and from intraprocess parallelism in the back-end. It can now also benefit from intraprocess parallelism in the front-end.

You might wonder how interprocess parallelism and intraprocess parallelism interact. If we have 20 parallel rustc invocations and each one can have up to 16 threads running, could we end up with hundreds of threads on a machine with only tens of cores, resulting in inefficient execution as the OS tries its best to schedule them?

Fortunately no. The compiler uses the jobserver protocolto limit the number of threads it creates. If a lot of interprocess parallelism is occuring, intraprocess parallelism will be limited appropriately, and the number of threads will not exceed the number of cores.

How to use it

The nightly compiler is now shipping with the parallel front-end enabled. However, by default it runs in single-threaded mode and won't reduce compile times.

Keen users can opt into multi-threaded mode with the -Z threads option. For example:

$ RUSTFLAGS="-Z threads=8" cargo build --release

Alternatively, to opt in from aconfig.toml file (for one or more projects), add these lines:

[build]
rustflags = ["-Z", "threads=8"]

It may be surprising that single-threaded mode is the default. Why parallelize the front-end and then run it in single-threaded mode? The answer is simple: caution. This is a big change! The parallel front-end has a lot of new code. Single-threaded mode exercises most of the new code, but excludes the possibility of threading bugs such as deadlocks that can affect multi-threaded mode. Even in Rust, parallel programs are harder to write correctly than serial programs. For this reason the parallel front-end also won't be shipped in beta or stable releases for some time.

Performance effects

When the parallel front-end is run in single-threaded mode, compilation times are typically 0% to 2% slower than with the serial front-end. This should be barely noticeable.

When the parallel front-end is run in multi-threaded mode with -Z threads=8, our measurements on real-world code show that compile times can be reduced by up to 50%, though the effects vary widely and depend on the characteristics of the code and its build configuration. For example, dev builds are likely to see bigger improvements than release builds because release builds usually spend more time doing optimizations in the back-end. A small number of cases compile more slowly in multi-threaded mode than single-threaded mode. These are mostly tiny programs that already compile quickly.

We recommend eight threads because this is the configuration we have tested the most and it is known to give good results. Values lower than eight will see smaller benefits. Values greater than eight will give diminishing returns and may even give worse performance.

If a 50% improvement seems low when going from one to eight threads, recall from the explanation above that the front-end only accounts for part of compile times, and the back-end is already parallel. You can't beat Amdahl's Law.

Memory usage can increase significantly in multi-threaded mode. We have seen increases of up to 35%. This is unsurprising given that various parts of compilation, each of which requires a certain amount of memory, are now executing in parallel.

Correctness

Reliability in single-threaded mode should be high.

In multi-threaded mode there are some known bugs, including deadlocks. If compilation hangs, you have probably hit one of them.

Feedback

If you have any problems with the parallel front-end, please check the issues marked with the "WG-compiler-parallel" label. If your problem does not match any of the existing issues, please file a new issue.

For more general feedback, please start a discussion on the wg-parallel-rustc Zulip channel. We are particularly interested to hear the performance effects on the code you care about.

Future work

We are working to improve the performance of the parallel front-end. As the graphs above showed, there is room to improve the utilization of the threads in the front-end. We are also ironing out the remaining bugs in multi-threaded mode.

We aim to stabilize the -Z threads option and ship the parallel front-end running by default in multi-threaded mode on stable releases in 2024.

Acknowledgments

The parallel front-end has been under development for a long time. It was started by @Zoxc, who also did most of the work for several years. After a period of inactivity, the project was revived this year by @SparrowLii, who led the effort to get it shipped. Other members of the Parallel Rustc Working Group have also been involved with reviews and other activities. Many thanks to everyone involved.

Continue Reading…

crates.io: Dropping support for non-canonical downloads

TL;DR

• We want to improve the reliability and performance of crate downloads.
• "Non-canonical downloads" (that use URLs containing hyphens or underscores where the crate published uses the opposite) are blocking these plans.
• On 2023-11-20 support for "non-canonical downloads" will be disabled.
• cargo users are unaffected.

What are "non-canonical downloads"?

The "non-canonical downloads" feature allows everyone to download the serde_derive crate from https://crates.io/api/v1/crates/serde%5Fderive/1.0.189/download, but also from https://crates.io/api/v1/crates/SERDE-derive/1.0.189/download, where the underscore was replaced with a hyphen (crates.io normalizes underscores and hyphens to be the same for uniqueness purposes, so it isn't possible to publish a crate named serde-derive because serde_derive exists) and parts of the crate name are using uppercase characters. The same also works vice versa, if the canonical crate name uses hyphens and the download URL uses underscores instead. It even works with any other combination for crates that have multiple such characters (please don't mix them…!).

Why remove it?

Supporting such non-canonical download requests means that the crates.io server needs to perform a database lookup for every download request to figure out the canonical crate name. The canonical crate name is then used to construct a download URL and the client is HTTP-redirected to that URL.

While we have introduced a caching layer some time ago to address some of the performance concerns, having all download requests go through our backend servers has still started to become problematic and at the current rate of growth will not become any easier in the future.

Having to support "non-canonical downloads" however prevents us from using CDNs directly for the download requests, so if we can remove support for non-canonical download requests, it will unlock significant performance and reliability gains.

Who is using "non-canonical downloads"?

cargo always uses the canonical crate name from the package index to construct the corresponding download URLs. If support was removed for this on the crates.io side then cargo would still work exactly the same as before.

Looking at the crates.io request logs, the following user-agents are currently relying on "non-canonical downloads" support:

• cargo-binstall/1.1.2
• Faraday v0.17.6
• Go-http-client/2.0
• GNU Guile
• python-requests/2.31.0

Three of these are just generic HTTP client libraries. GNU Guile is apparently a programming language, so most likely this is also a generic user-agent from a custom user program.

cargo-binstall is a tool enabling installation of binary artifacts of crates. The maintainer is already aware of the upcoming change and confirmed that more recent versions of cargo-binstall should not be affected by this change.

We recommend that any scripts relying on non-canonical downloads be adjusted to use the canonical names from the package index, the database dump, or the crates.io API instead. If you don't know which data source is best suited for you, we welcome you to take a look at the crates.io data access page.

What is the plan?

1. Today: Announce the removal of support for non-canonical downloads on the main Rust blog.
2. 2023-11-20: Disable support for non-canonical downloads and return a migration error message instead, to alert remaining users of this feature of the need to migrate. This still needs to put load on the application to detect a request is using a non-canonical download URL.
3. 2023-12-18: Return a regular 404 error instead of the migration error message, allowing us to get rid of (parts of) the database query.

Note that we will still need the database query for download counting purposes for now. We have plans to remove this requirement as well, but those efforts are blocked by us still supporting non-canonical downloads.

If you want to follow the progress on implementing these changes or if you have comments you can subscribe to the corresponding tracking issue. Related discussions are also happening on the crates.io Zulip stream.

Continue Reading…

A tale of broken badges and 23,000 features

Around mid-October of 2023 the crates.io team was notified by one of our users that a shields.io badge for their crate stopped working. The issue reporter was kind enough to already debug the problem and figured out that the API request that shields.io sends to crates.io was most likely the problem. Here is a quote from the original issue:

This crate makes heavy use of feature flags which bloat the response payload of the API.

Apparently the API response for this specific crate had broken the 20 MB mark and shields.io wasn't particularly happy with this. Interestingly, this crate only had 9 versions published at this point in time. But how do you get to 20 MB with only 9 published versions?

As the quote above already mentions, this crate is using features… a lot of features… almost 23,000! 😱

What crate needs that many features? Well, this crate provides SVG icons for Rust-based web applications… and it uses one feature per icon so that the payload size of the final WebAssembly bundle stays small.

At first glance there should be nothing wrong with this. This seems like a reasonable thing to do from a crate author perspective and neither cargo, nor crates.io, were showing any warnings about this. Unfortunately, some of the internals are not too happy about such a high number of features…

The first problem that was already identified by the crate author: the API responses from crates.io are getting veeeery large. Adding to the problem is the fact that the crates.io API currently does not paginate the list of published versions. Changing this is obviously a breaking change, so our team had been a bit reluctant to change the behavior of the API in that regard, though this situation has shown that we will likely have to tackle this problem in the near future.

The next problem is that the index file for this crate is also getting large. With 9 published versions it already contains 11 MB of data. And just like the crates.io API, there is currently no pagination built into the package index file format.

Now you may ask, why do the package index and cargo need to know about features? Well, the easy answer is: for dependency resolution. Features can enable optional dependencies, so when a dependency feature is used it might influence the dependency resolution. Our initial thought was that we could at least drop all empty feature declarations from the index file (e.g. foo = []), but the cargo team informed us that cargo relies on them being available there too, and so for backwards-compatibility reasons this is not an option.

On the bright side, most Rust users are on cargo versions these days that use the sparse package index by default, which only downloads index files for packages actually being used. In other words: only users of this icon crate need to pay the price for downloading all the metadata. On the flipside, this means users who are still using the git-based index are all paying for this one crate using 23,000 features.

So, where do we go from here? 🤔

While we believe that supporting such a high number of features is conceptually a valid request, with the current implementation details in crates.io and cargo we cannot support this. After analyzing all of these downstream effects from a single crate having that many features, we realized we need some form of restriction on crates.io to keep the system from falling apart.

Now comes the important part: on 2023-10-16 the crates.io team deployed a change limiting the number of features a crate can have to 300 for any new crates/versions being published.

… for now, or at least until we have found solutions for the above problems.

We are aware of a couple of crates that also have legitimate reasons for having more than 300 features, and we have granted them appropriate exceptions to this rule, but we would like to ask everyone to be mindful of these limitations of our current systems.

We also invite everyone to participate in finding solutions to the above problems. The best place to discuss ideas is the crates.io Zulip stream, and once an idea is a bit more fleshed out it will then be transformed into an RFC.

Finally, we would like to thank Charles Edward Gagnon for making us aware of this problem. We also want to reiterate that the author and their crate are not to blame for this. It is hard to know of these crates.io implementation details when developing crates, so if anything, the blame would be on us, the crates.io team, for not having limits on this earlier. Anyway, we have them now, and now you all know why! 👋

Continue Reading…

Announcing the New Rust Project Directors

We are happy to announce that we have completed the process to elect new Project Directors.

The new Project Directors are:

• Scott McMurray
• Jakob Degen
• Santiago Pastorino

They will join Ryan Levick and Mark Rousskov to make up the five members of the Rust Foundation Board of Directors who represent the Rust Project.

The board is made up of Project Directors, who come from and represent the Rust Project, and Member Directors, who represent the corporate members of the Rust Foundation.

Both of these director groups have equal voting power.

We look forward to working with and being represented by this new group of project directors.

We were fortunate to have a number of excellent candidates and this was a difficult decision. We wish to express our gratitude to all of the candidates who were considered for this role! We also extend our thanks to the project as a whole who participated by nominating candidates and providing additional feedback once the nominees were published. Finally, we want to share our appreciation for the Project Director Elections Subcommittee for working to design and facilitate running this election process.

This was a challenging decision for a number of reasons.

This was also our first time doing this process and we learned a lot to use to improve it going forward. The Project Director Elections Subcommittee will be following up with a retrospective outlining how well we achieved our goals with this process and making suggestions for future elections. We are expecting another election next year to start a rotating cadence of 2-year terms. Project governance is about iterating and refining over time.

Once again, we thank all who were involved in this process and we are excited to welcome our new Project Directors.

Continue Reading…

Announcing Rust 1.73.0

The Rust team is happy to announce a new version of Rust, 1.73.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.73.0 with:

rustup update stable

If 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.73.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!

What's in 1.73.0 stable

Cleaner panic messages

The output produced by the default panic handler has been changed to put the panic message on its own line instead of wrapping it in quotes. This can make panic messages easier to read, as shown in this example:

fn main() {
    let file = "ferris.txt";
    panic!("oh no! {file:?} not found!");
}

Output before Rust 1.73:

thread 'main' panicked at 'oh no! "ferris.txt" not found!', src/main.rs:3:5

Output starting in Rust 1.73:

thread 'main' panicked at src/main.rs:3:5:
oh no! "ferris.txt" not found!

This is especially useful when the message is long, contains nested quotes, or spans multiple lines.

Additionally, the panic messages produced by assert_eq and assert_ne have been modified, moving the custom message (the third argument) and removing some unnecessary punctuation, as shown below:

fn main() {
    assert_eq!("🦀", "🐟", "ferris is not a fish");
}

Output before Rust 1.73:

thread 'main' panicked at 'assertion failed: `(left == right)`
 left: `"🦀"`,
right: `"🐟"`: ferris is not a fish', src/main.rs:2:5

Output starting in Rust 1.73:

thread 'main' panicked at src/main.rs:2:5:
assertion `left == right` failed: ferris is not a fish
 left: "🦀"
right: "🐟"

Thread local initialization

As proposed in RFC 3184, LocalKey<Cell<T>> and LocalKey<RefCell<T>> can now be directly manipulated with get(), set(), take(), and replace() methods, rather than jumping through a with(|inner| ...) closure as needed for general LocalKey work. LocalKey<T> is the type of thread_local! statics.

The new methods make common code more concise and avoid running the extra initialization code for the default value specified in thread_local! for new threads.

thread_local! {
    static THINGS: Cell<Vec<i32>> = Cell::new(Vec::new());
}

fn f() {
    // before:
    THINGS.with(|i| i.set(vec![1, 2, 3]));
    // now:
    THINGS.set(vec![1, 2, 3]);

    // ...

    // before:
    let v = THINGS.with(|i| i.take());
    // now:
    let v: Vec<i32> = THINGS.take();
}

Stabilized APIs

• Unsigned {integer}::div_ceil
• Unsigned {integer}::next_multiple_of
• Unsigned {integer}::checked_next_multiple_of
• std::ffi::FromBytesUntilNulError
• std::os::unix::fs::chown
• std::os::unix::fs::fchown
• std::os::unix::fs::lfchown
• LocalKey::<Cell>::get
• LocalKey::<Cell>::set
• LocalKey::<Cell>::take
• LocalKey::<Cell>::replace
• LocalKey::<RefCell>::with_borrow
• LocalKey::<RefCell>::with_borrow_mut
• LocalKey::<RefCell>::set
• LocalKey::<RefCell>::take
• LocalKey::<RefCell>::replace

These APIs are now stable in const contexts:

• rc::Weak::new
• sync::Weak::new
• NonNull::as_ref

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.73.0

Many people came together to create Rust 1.73.0. We couldn't have done it without all of you. Thanks!

Continue Reading…

Increasing the minimum supported Apple platform versions

As of Rust 1.74 (to be released on November 16th, 2023), the minimum version of Apple's platforms (iOS, macOS, and tvOS) that the Rust toolchain supports will be increased to newer minimums. These changes affect both the Rust compiler itself (rustc), other host tooling, and most importantly, the standard library and any binaries produced that use it. With these changes in place, any binaries produced will stop loading on older versions or exhibit other, unspecified, behavior.

The new minimum versions are now:

• macOS: 10.12 Sierra (First released 2016)
• iOS: 10 (First released 2016)
• tvOS: 10 (First released 2016)

If your application does not target or support macOS 10.7-10.11 or iOS 7-9 already these changes most likely do not affect you.

Affected targets

The following contains each affected target, and the comprehensive effects on it:

• x86_64-apple-darwin (Minimum OS raised)
• aarch64-apple-ios (Minimum OS raised)
• aarch64-apple-ios-sim (Minimum iOS and macOS version raised.)
• x86_64-apple-ios (Minimum iOS and macOS version raised. This is also a simulator target.)
• aarch64-apple-tvos (Minimum OS raised)
• armv7-apple-ios (Target removed. The oldest iOS 10-compatible device uses ARMv7s.)
• armv7s-apple-ios (Minimum OS raised)
• i386-apple-ios (Minimum OS raised)
• i686-apple-darwin (Minimum OS raised)
• x86_64-apple-tvos (Minimum tvOS and macOS version raised. This is also a simulator target.)

From these changes, only one target has been removed entirely: armv7-apple-ios. It was a tier 3 target.

Note that Mac Catalyst and M1/M2 (aarch64) Mac targets are not affected, as their minimum OS version already has a higher baseline. Refer to the Platform Support Guide for more information.

Affected systems

These changes remove support for multiple older mobile devices (iDevices) and many more Mac systems. Thanks to @madsmtm for compiling the list.

As of this update, the following device models are no longer supported by the latest Rust toolchain:

iOS

• iPhone 4S (Released in 2011)
• iPad 2 (Released in 2011)
• iPad, 3rd generation (Released in 2012)
• iPad Mini, 1st generation (Released in 2012)
• iPod Touch, 5th generation (Released in 2012)

macOS

A total of 27 Mac system models, released between 2007 and 2009, are no longer supported.

The affected systems are not comprehensively listed here, but external resources exist which contain lists of the exact models. They can be found from Apple and Yama-Mac, for example.

tvOS

The third generation AppleTV (released 2012-2013) is no longer supported.

Why are the requirements being changed?

Prior to now, Rust claimed support for very old Apple OS versions, but many never even received passive testing or support. This is a rough place to be for a toolchain, as it hinders opportunities for improvement in exchange for a support level many people, or everyone, will never utilize. For Apple's mobile platforms, many of the old versions are now even unable to receive new software due to App Store publishing restrictions.

Additionally, the past two years have clearly indicated that Apple, which has tight control over toolchains for these targets, is making it difficult-to-impossible to support them anymore. As of XCode 14, last year's toolchain release, building for many old OS versions became unsupported. XCode 15 continues this trend. After enough time, continuing to use an older toolchain can even lead to breaking build issues for others.

We want Rust to be a first-class option for developing software for and on Apple's platforms, but to continue this goal we have to set an easier, and more realistic compatibility baseline. The new requirements were determined after surveying what Apple and third-party statistics are available to us and picking a middle ground that balances compatibility with Rusts's needs and limitations.

Do I need to do anything?

If you or an application you develop are affected by this change, there are different options which may be helpful:

• If possible, raise your minimum supported OS versions. All OS versions discussed in above have no support from the vendor. Not even security updates.
• If you are running the Rust compiler or other host tools that were previously supported, consider cross-compiling from a newer host instead. You may also no longer be able to depend on the Rust standard library.
• If none of these options work, you may need to freeze the version of the Rust toolchain your project builds with. Alternatively, you may be able to maintain a custom toolchain that supports your requirements for any sub-component of it.

If your project does not directly support a specific version, but instead depends on a default previously used by Rust, there are some steps you can take to help improve. For example, a number of crates in the ecosystem have hardcoded Rust's default support versions since they haven't changed for a long time:

• If you use the cc crate to include build languages into your project, a future update will handle this transparently.
• If you need a minimum OS version for anything else, crates should query the new rustc --print deployment-target option for a default, or user-set, value on toolchains using Rust 1.71 or newer going forward. Hardcoded defaults should only be used for older toolchains where this is unavailable.

Continue Reading…

crates.io Policy Update RFC

Around the end of July the crates.io team opened an RFC to update the current crates.io usage policies. This policy update addresses operational concerns of the crates.io community service that have arisen since the last significant policy update in 2017, particularly related to name squatting and spam. The RFC has caused considerable discussion, and most of the suggested improvements have since been integrated into the proposal.

At the last team meeting the crates.io team decided to move the RFC forward and start the final comment period process.

We have been made aware by a couple of community members though that the RFC might not have been visible enough in the Rust community. We hope that this blog post changes that.

We invite you all to review the RFC and let us know if there are still any major concerns with these proposed policies.

Here is a quick TL;DR:

• The current policies are quite vague on a couple of topics. The new policies are more explicit.
• Reserving names is still allowed, but only to a certain degree and if you have a good reason for it.
• The crates.io team will try to contact crate owners before taking any actions.

Finally, if you have any comments, please open threads on the RFC diff, instead of using the main comment box, to keep the discussion more structured. Thank you!

Continue Reading…

Announcing Rust 1.72.1

The Rust team has published a new point release of Rust, 1.72.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, getting Rust 1.72.1 is as easy as:

rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website.

What's in 1.72.1

1.72.1 resolves a few regressions introduced in 1.72.0:

• Partially revert codegen change, improving codegen
• rustdoc: Fix self ty params in objects with lifetimes
• Fix regression in compile times
• Resolve some ICEs in the compiler:
  • #115215
  • #115559

Contributors to 1.72.1

Many people came together to create Rust 1.72.1. We couldn't have done it without all of you. Thanks!

Continue Reading…

Electing New Project Directors

Today we are launching the process to elect new Project Directors to the Rust Foundation Board of Directors. As we begin the process, we wanted to spend some time explaining the goals and procedures we will follow. We will summarize everything here, but if you would like to you can read the official process documentation.

We ask all project members to begin working with their Leadership Council representative to nominate potential Project Directors. See the Candidate Gathering section for more details. Nominations are due by September 15, 2023.

What are Project Directors?

The Rust Foundation Board of Directors has five seats reserved for Project Directors. These Project Directors serve as representatives of the Rust project itself on the Board. Like all Directors, the Project Directors are elected by the entity they represent, which in the case of the Rust Project means they are elected by the Rust Leadership Council. Project Directors serve for a term of two years and will have staggered terms. This year we will appoint two new directors and next year we will appoint three new directors.

The current project directors are Jane Losare-Lusby, Josh Stone, Mark Rousskov, Ryan Levick and Tyler Mandry. This year, Jane Losare-Lusby and Josh Stone will be rotating out of their roles as Project Directors, so the current elections are to fill their seats. We are grateful for the work the Jane and Josh have put in during their terms as Project Directors!

We want to make sure the Project Directors can effectively represent the project as a whole, so we are soliciting input from the whole project. The elections process will go through two phases: Candidate Gathering and Election. Read on for more detail about how these work.

Candidate Gathering

The first phase is beginning right now. In this phase, we are inviting the members of all of the top level Rust teams and their subteams to nominate people who will make good project directors. The goal is to bubble these up to the Council through each of the top-level teams. You should be hearing from your Council Representative soon with more details, but if not, feel free to reach out to them directly.

Each team is encouraged to suggest candidates. Since we are electing two new directors, it would be ideal for teams to nominate at least two candidates. Nominees can be anyone in the project and do not have to be a member of the team who nominates them.

The candidate gathering process will be open until September 15, at which point each team's Council Representative will share their team's nominations and reasoning with the whole Leadership Council. At this point, the Council will confirm with each of the nominees that they are willing to accept the nomination and fill the role of Project Director. Then the Council will publish the set of candidates.

This then starts a ten day period where members of the Rust Project are invited to share feedback on the nominees with the Council. This feedback can include reasons why a nominee would make a good project director, or concerns the Council should be aware of.

The Council will announce the set of nominees by September 19 and the ten day feedback period will last until September 29. Once this time has passed, we will move on to the election phase.

Election

The Council will meet during the week of October 1 to complete the election process. In this meeting we will discuss each candidate and once we have done this the facilitator will propose a set of two of them to be the new Project Directors. The facilitator puts this to a vote, and if the Council unanimously agrees with the proposed pair of candidates then the process is completed. Otherwise, we will give another opportunity for council members to express their objections and we will continue with another proposal. This process repeats until we find two nominees who the Council can unanimously consent to. The Council will then confirm these nominees through an official vote.

Once this is done, we will announce the new Project Directors. In addition, we will contact each of the nominees, including those who were not elected, to tell them a little bit more about what we saw as their strengths and opportunities for growth to help them serve better in similar roles in the future.

Timeline

This process will continue through all of September and into October. Below are the key dates:

• Candidate nominations due: September 15
• Candidates published: September 19
• Feedback period: September 19 - 29
• Election meeting: Week of October 1

After the election meeting happens, the Rust Leadership Council will announce the results and the new Project Directors will assume their responsibilities.

Acknowledgements

A number of people have been involved in designing and launching this election process and we wish to extend a heartfelt thanks to all of them! We'd especially like to thank the members of the Project Director Election Proposal Committee: Jane Losare-Lusby, Eric Holk, and Ryan Levick. Additionally, many members of the Rust Community have provided feedback and thoughtful discussions that led to significant improvements to the process. We are grateful for all of your contributions.

Continue Reading…

Change in Guidance on Committing Lockfiles

For years, the Cargo team has encouraged Rust developers tocommit their Cargo.lock file for packages with binaries but not libraries. We now recommend peopledo what is best for their project. To help people make a decision, we do include some considerations and suggest committing Cargo.lock as a starting point in their decision making. To align with that starting point, cargo new will no longer ignoreCargo.lock for libraries as of nightly-2023-08-24. Regardless of what decision projects make, we encourage regulartesting against their latest dependencies.

Background

The old guidelines ensured libraries tested their latest dependencies which helped us keep quality high within Rust's package ecosystem by ensuring issues, especially backwards compatibility issues, were quickly found and addressed. While this extra testing was not exhaustive, We believe it helped foster a culture of quality in this nascent ecosystem.

This hasn't been without its downsides though. This has removed an important piece of history from code bases, making bisecting to find the root cause of a bug harder for maintainers. For contributors, especially newer ones, this is another potential source of confusion and frustration from an unreliable CI whenever a dependency is yanked or a new release contains a bug.

Why the change

A lot as changed for Rust since the guideline was written. Rust has shifted from being a language for early adopters to being more mainstream, and we need to be mindful of the on-boarding experience of these new-to-Rust developers. Also with this wider adoption, it isn't always practical to assume everyone is using the latest Rust release and the community has been working through how to manage support for minimum-supported Rust versions (MSRV). Part of this is maintaining an instance of your dependency tree that can build with your MSRV. A lockfile is an appropriate way to pin versions for your project so you can validate your MSRV but we found people were instead putting upperbounds on their version requirements due to the strength of our prior guideline despitelikely being a worse solution.

The wider software development ecosystem has also changed a lot in the intervening time. CI has become easier to setup and maintain. We also have products likeDependabotandRenovate. This has opened up options besides having version control ignore Cargo.lock to test newer dependencies. Developers could have a scheduled job that first runs cargo update. They could also have bots regularly update their Cargo.lock in PRs, ensuring they pass CI before being merged.

Since there isn't a universal answer to these situations, we felt it was best to leave the choice to developers and give them information they need in making a decision. For feedback on this policy change, see rust-lang/cargo#8728. You can also reach out the the Cargo team more generally onZulip.

Continue Reading…

Announcing Rust 1.72.0

The Rust team is happy to announce a new version of Rust, 1.72.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.72.0 with:

rustup update stable

If 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.72.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!

What's in 1.72.0 stable

Rust reports potentially useful cfg-disabled items in errors

You can conditionally enable Rust code using cfg, such as to provide certain functions only with certain crate features, or only on particular platforms. Previously, items disabled in this way would be effectively invisible to the compiler. Now, though, the compiler will remember the name and cfg conditions of those items, so it can report (for example) if a function you tried to call is unavailable because you need to enable a crate feature.

   Compiling my-project v0.1.0 (/tmp/my-project)
error[E0432]: unresolved import `rustix::io_uring`
   --> src/main.rs:1:5
    |
1   | use rustix::io_uring;
    |     ^^^^^^^^^^^^^^^^ no `io_uring` in the root
    |
note: found an item that was configured out
   --> /home/username/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.8/src/lib.rs:213:9
    |
213 | pub mod io_uring;
    |         ^^^^^^^^
    = note: the item is gated behind the `io_uring` feature

For more information about this error, try `rustc --explain E0432`.
error: could not compile `my-project` (bin "my-project") due to previous error

Const evaluation time is now unlimited

To prevent user-provided const evaluation from getting into a compile-time infinite loop or otherwise taking unbounded time at compile time, Rust previously limited the maximum number of statements run as part of any given constant evaluation. However, especially creative Rust code could hit these limits and produce a compiler error. Worse, whether code hit the limit could vary wildly based on libraries invoked by the user; if a library you invoked split a statement into two within one of its functions, your code could then fail to compile.

Now, you can do an unlimited amount of const evaluation at compile time. To avoid having long compilations without feedback, the compiler will always emit a message after your compile-time code has been running for a while, and repeat that message after a period that doubles each time. By default, the compiler will also emit a deny-by-default lint (const_eval_long_running) after a large number of steps to catch infinite loops, but you canallow(const_eval_long_running) to permit especially long const evaluation.

Uplifted lints from Clippy

Several lints from Clippy have been pulled into rustc:

• clippy::undropped_manually_drops to undropped_manually_drops (deny)
  • ManuallyDrop does not drop its inner value, so calling std::mem::drop on it does nothing. Instead, the lint will suggest ManuallyDrop::into_inner first, or you may use the unsafe ManuallyDrop::drop to run the destructor in-place. This lint is denied by default.
• clippy::invalid_utf8_in_unchecked to invalid_from_utf8_unchecked (deny) and invalid_from_utf8 (warn)
  • The first checks for calls to std::str::from_utf8_unchecked and std::str::from_utf8_unchecked_mut with an invalid UTF-8 literal, which violates their safety pre-conditions, resulting in undefined behavior. This lint is denied by default.
  • The second checks for calls to std::str::from_utf8 and std::str::from_utf8_mut with an invalid UTF-8 literal, which will always return an error. This lint is a warning by default.
• clippy::cmp_nan to invalid_nan_comparisons (warn)
  • This checks for comparisons with f32::NAN or f64::NAN as one of the operands. NaN does not compare meaningfully to anything – not even itself – so those comparisons are always false. This lint is a warning by default, and will suggest calling the is_nan() method instead.
• clippy::cast_ref_to_mut to invalid_reference_casting (allow)
  • This checks for casts of &T to &mut T without using interior mutability, which is immediate undefined behavior, even if the reference is unused. This lint is currently allowed by default due to potential false positives, but it is planned to be denied by default in 1.73 after implementation improvements.

Stabilized APIs

• impl<T: Send> Sync for mpsc::Sender
• impl TryFrom<&OsStr> for &str
• String::leak

These APIs are now stable in const contexts:

• CStr::from_bytes_with_nul
• CStr::to_bytes
• CStr::to_bytes_with_nul
• CStr::to_str

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Future Windows compatibility

In a future release we're planning to increase the minimum supported Windows version to 10. The accepted proposal in compiler MCP 651 is that Rust 1.75 will be the last to officially support Windows 7, 8, and 8.1. When Rust 1.76 is released in February 2024, only Windows 10 and later will be supported as tier-1 targets. This change will apply both as a host compiler and as a compilation target.

Contributors to 1.72.0

Many people came together to create Rust 1.72.0. We couldn't have done it without all of you. Thanks!

Continue Reading…

2022 Annual Rust Survey Results

Hello, Rustaceans!

For the 6th year in a row, the Rust Project conducted a survey on the Rust programming language, with participation from project maintainers, contributors, and those generally interested in the future of Rust. This edition of the annual State of Rust Survey opened for submissions on December 5 and ran until December 22, 2022.

First, we'd like to thank you for your patience on these long delayed results. We hope to identify a more expedient and sustainable process going forward so that the results come out more quickly and have even more actionable insights for the community.

The goal of this survey is always to give our wider community a chance to express their opinions about the language we all love and help shape its future. We’re grateful to those of you who took the time to share your voice on the state of Rust last year.

Before diving into a few highlights, we would like to thank everyone who was involved in creating the State of Rust survey with special acknowledgment to the translators whose work allowed us to offer the survey in English, Simplified Chinese, Traditional Chinese, French, German, Japanese, Korean, Portuguese, Russian, Spanish, and Ukrainian.

Participation

In 2022, we had 9,433 total survey completions and an increased survey completion rate of 82% vs. 76% in 2021. While the goal is always total survey completion for all participants, the survey requires time, energy, and focus – we consider this figure quite high and were pleased by the increase.

We also saw a significant increase in the number of people viewing but not participating in the survey (from 16,457 views in 2021 to 25,581 – a view increase of over 55%). While this is likely due to a number of different factors, we feel this information speaks to the rising interest in Rust and the growing general audience following its evolution.

In 2022, the survey had 11,482 responses, which is a slight decrease of 6.4% from 2021, however, the number of respondents that answered all survey questions has increased year over year. We were interested to see this slight decrease in responses, as this year’s survey was much shorter than in previous years – clearly, survey length is not the only factor driving participation.

Community

We were pleased to offer the survey in 11 languages – more than ever before, with the addition of a Ukrainian translation in 2022. 77% of respondents took this year’s survey in English, 5% in Chinese (simplified), 4% in German and French, 2% in Japanese, Spanish, and Russian, and 1% in Chinese (traditional), Korean, Portuguese, and Ukrainian. This is our lowest percentage of respondents taking the survey in English to date, which is an exciting indication of the growing global nature of our community!

The vast majority of our respondents reported being most comfortable communicating on technical topics in English (93%), followed by Chinese (7%).

Rust user respondents were asked which country they live in. The top 13 countries represented were as follows: United States (25%), Germany (12%), China (7%), United Kingdom (6%), France (5%), Canada (4%), Russia (4%), Japan (3%), Netherlands (3%), Sweden (2%), Australia (2%), Poland (2%), India (2%). Nearly 72.5% of respondents elected to answer this question.

While we see global access to Rust education as a critical goal for our community, we are proud to say that Rust was used all over the world in 2022!

Rust Usage

More people are using Rust than ever before! Over 90% of survey respondents identified as Rust users, and of those using Rust, 47% do so on a daily basis – an increase of 4% from the previous year.

30% of Rust user respondents can write simple programs in Rust, 27% can write production-ready code, and 42% consider themselves productive using Rust.

Of the former Rust users who completed the survey, 30% cited difficulty as the primary reason for giving up while nearly 47% cited factors outside of their control.

Similarly, 26% of those who did not identify as Rust users cited the perception of difficulty as the primary reason for not having used it, (with 62% reporting that they simply haven’t had the chance to prioritize learning Rust yet).

Rust Usage at Work

The growing maturation of Rust can be seen through the increased number of different organizations utilizing the language in 2022. In fact, 29.7% of respondents stated that they use Rust for the majority of their coding work at their workplace, which is a 51.8% increase compared to the previous year.

There are numerous reasons why we are seeing increased use of Rust in professional environments. Top reasons cited for the use of Rust include the perceived ability to write "bug-free software" (86%), Rust's performance characteristics (84%), and Rust's security and safety guarantees (69%). We were also pleased to find that 76% of respondents continue to use Rust simply because they found it fun and enjoyable. (Respondents could select more than one option here, so the numbers don't add up to 100%.)

Of those respondents that used Rust at work, 72% reported that it helped their team achieve its goals (a 4% increase from the previous year) and 75% have plans to continue using it on their teams in the future.

But like any language being applied in the workplace, Rust’s learning curve is an important consideration; 39% of respondents using Rust in a professional capacity reported the process as “challenging” and 9% of respondents said that adopting Rust at work has “slowed down their team”. However, 60% of productive users felt Rust was worth the cost of adoption overall.

It is exciting to see the continued growth of professional Rust usage and the confidence so many users feel in its performance, control, security and safety, enjoyability, and more!

Supporting the Future of Rust

A key goal of the State of Rust survey is to shed light on challenges, concerns, and priorities Rustaceans are currently sitting with.

Of those respondents who shared their main worries for the future of Rust, 26% have concerns that the developers and maintainers behind Rust are not properly supported – a decrease of more than 30% from the previous year’s findings. One area of focus in the future may be to see how the Project in conjunction with the Rust Foundation can continue to push that number towards 0%.

While 38% have concerns about Rust “becoming too complex”, only a small number of respondents were concerned about documentation, corporate oversight, or speed of evolution. 34% of respondents are not worried about the future of Rust at all.

This year’s survey reflects a 21% decrease in fears about Rust’s usage in the industry since the last survey. Faith in Rust’s staying power and general utility is clearly growing as more people find Rust and become lasting members of the community. As always, we are grateful for your honest feedback and dedication to improving this language for everyone.

Another Round of Thanks

To quote an anonymous survey respondent, “Thanks for all your hard work making Rust awesome!” – Rust wouldn’t exist or continue to evolve for the better without the many Project members and the wider Rust community. Thank you to those who took the time to share their thoughts on the State of Rust in 2022!

Continue Reading…

Announcing Rust 1.71.1

The Rust team has published a new point release of Rust, 1.71.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, getting Rust 1.71.1 is as easy as:

rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website.

What's in 1.71.1 stable

Rust 1.71.1 fixes Cargo not respecting the umask when extracting dependencies, which could allow a local attacker to edit the cache of extracted source code belonging to another local user, potentially executing code as another user. This security vulnerability is tracked as CVE-2023-38497, and you can read more about it on the advisory we published earlier today. We recommend all users to update their toolchain as soon as possible.

Rust 1.71.1 also addresses several regressions introduced in Rust 1.71.0, including bash completion being broken for users of Rustup, and thesuspicious_double_ref_op being emitted when calling borrow() even though it shouldn't.

You can find more detailed information on the specific regressions, and other minor fixes, in the release notes.

Contributors to 1.71.1

Many people came together to create Rust 1.71.1. We couldn't have done it without all of you. Thanks!

Continue Reading…

Security advisory for Cargo (CVE-2023-38497)

This is a cross-post of the official security advisory. The official advisory contains a signed version with our PGP key, as well.

The Rust Security Response WG was notified that Cargo did not respect the umask when extracting crate archives on UNIX-like systems. If the user downloaded a crate containing files writeable by any local user, another local user could exploit this to change the source code compiled and executed by the current user.

This vulnerability has been assigned CVE-2023-38497.

Overview

In UNIX-like systems, each file has three sets of permissions: for the user owning the file, for the group owning the file, and for all other local users. The "umask" is configured on most systems to limit those permissions during file creation, removing dangerous ones. For example, the default umask on macOS and most Linux distributions only allow the user owning a file to write to it, preventing the group owning it or other local users from doing the same.

When a dependency is downloaded by Cargo, its source code has to be extracted on disk to allow the Rust compiler to read as part of the build. To improve performance, this extraction only happens the first time a dependency is used, caching the pre-extracted files for future invocations.

Unfortunately, it was discovered that Cargo did not respect the umask during extraction, and propagated the permissions stored in the crate archive as-is. If an archive contained files writeable by any user on the system (and the system configuration didn't prevent writes through other security measures), another local user on the system could replace or tweak the source code of a dependency, potentially achieving code execution the next time the project is compiled.

Affected Versions

All Rust versions before 1.71.1 on UNIX-like systems (like macOS and Linux) are affected. Note that additional system-dependent security measures configured on the local system might prevent the vulnerability from being exploited.

Users on Windows and other non-UNIX-like systems are not affected.

Mitigations

We recommend all users to update to Rust 1.71.1, which will be released later today, as it fixes the vulnerability by respecting the umask when extracting crate archives. If you build your own toolchain, patches for 1.71.0 source tarballs are available here.

To prevent existing cached extractions from being exploitable, the Cargo binary included in Rust 1.71.1 or later will purge the caches it tries to access if they were generated by older Cargo versions.

If you cannot update to Rust 1.71.1, we recommend configuring your system to prevent other local users from accessing the Cargo directory, usually located in ~/.cargo:

chmod go= ~/.cargo

Acknowledgments

We want to thank Addison Crump for responsibly disclosing this to us according to the Rust security policy.

We also want to thank the members of the Rust project who helped us disclose the vulnerability: Weihang Lo for developing the fix; Eric Huss for reviewing the fix; Pietro Albini for writing this advisory; Pietro Albini, Manish Goregaokar and Josh Stone for coordinating this disclosure; Josh Triplett, Arlo Siemen, Scott Schafer, and Jacob Finkelman for advising during the disclosure.

Continue Reading…

Announcing Rust 1.71.0

The Rust team is happy to announce a new version of Rust, 1.71.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.71.0 with:

rustup update stable

If 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.71.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!

What's in 1.71.0 stable

C-unwind ABI

1.71.0 stabilizes C-unwind (and other -unwind suffixed ABI variants1).

The behavior for unforced unwinding (the typical case) is specified in this table from the RFC which proposed this feature. To summarize:

Each ABI is mostly equivalent to the same ABI without -unwind, except that with -unwind the behavior is defined to be safe when an unwinding operation (panic or C++ style exception) crosses the ABI boundary. For panic=unwind, this is a valid way to let exceptions from one language unwind the stack in another language without terminating the process (as long as the exception is caught in the same language from which it originated); for panic=abort, this will typically abort the process immediately.

For this initial stabilization, no change is made to the existing ABIs (e.g."C"), and unwinding across them remains undefined behavior. A future Rust release will amend these ABIs to match the behavior specified in the RFC as the final part in stabilizing this feature (usually aborting at the boundary). Users are encouraged to start using the new unwind ABI variants in their code to remain future proof if they need to unwind across the ABI boundary.

Debugger visualization attributes

1.71.0 stabilizes support for a new attribute, #[debug_visualizer(natvis_file = "...")] and #[debug_visualizer(gdb_script_file = "...")], which allows embedding Natviz descriptions and GDB scripts into Rust libraries to improve debugger output when inspecting data structures created by those libraries. Rust itself has packaged similar scripts for some time for the standard library, but this feature makes it possible for library authors to provide a similar experience to end users.

See the referencefor details on usage.

raw-dylib linking

On Windows platforms, Rust now supports using functions from dynamic libraries without requiring those libraries to be available at build time, using the new kind="raw-dylib” option for #[link].

This avoids requiring users to install those libraries (particularly difficult for cross-compilation), and avoids having to ship stub versions of libraries in crates to link against. This simplifies crates providing bindings to Windows libraries.

Rust also supports binding to symbols provided by DLLs by ordinal rather than named symbol, using the new #[link_ordinal] attribute.

Upgrade to musl 1.2

As previously announced, Rust 1.71 updates the musl version to 1.2.3. Most users should not be affected by this change.

Const-initialized thread locals

Rust 1.59.0 stabilized const initialized thread local support in the standard library, which allows for more optimal code generation. However, until now this feature was missed in release notes anddocumentation. Note that this stabilization does not make const { ... } a valid expression or syntax in other contexts; that is a separate and currently unstablefeature.

use std::cell::Cell;

thread_local! {
    pub static FOO: Cell<u32> = const { Cell::new(1) };
}

Stabilized APIs

• CStr::is_empty
• BuildHasher::hash_one
• NonZeroI*::is_positive
• NonZeroI*::is_negative
• NonZeroI*::checked_neg
• NonZeroI*::overflowing_neg
• NonZeroI*::saturating_neg
• NonZeroI*::wrapping_neg
• Neg for NonZeroI*
• Neg for &NonZeroI*
• From<[T; N]> for (T...)(array to N-tuple for N in 1..=12)
• From<(T...)> for [T; N](N-tuple to array for N in 1..=12)
• windows::io::AsHandle for Box
• windows::io::AsHandle for Rc
• windows::io::AsHandle for Arc
• windows::io::AsSocket for Box
• windows::io::AsSocket for Rc
• windows::io::AsSocket for Arc

These APIs are now stable in const contexts:

• <*const T>::read
• <*const T>::read_unaligned
• <*mut T>::read
• <*mut T>::read_unaligned
• ptr::read
• ptr::read_unaligned
• <[T]>::split_at

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.71.0

Many people came together to create Rust 1.71.0. We couldn't have done it without all of you. Thanks!

1. List of stabilized ABIs can be found in the stabilization report: https://github.com/rust-lang/rust/issues/74990#issuecomment-1363473645 ↩

Continue Reading…

Announcing regex 1.9

The regex sub-team is announcing the release of regex 1.9. The regex crate is maintained by the Rust project and is the recommended way to use regular expressions in Rust. Its defining characteristic is its guarantee of worst case linear time searches with respect to the size of the string being searched.

Releases of the regex crate aren't normally announced on this blog, but since the majority of its internals have been rewritten in version 1.9, this announcement serves to encourage extra scrutiny. If you run into any problems or performance regressions, please report them on the issue tracker or ask questions on the Discussion forum.

Few API additions have been made, but one worth calling out is theCaptures::extract method that should make getting capture groups in some cases more convenient. Otherwise, the main change folks should see is hopefully faster search times.

You can read more in the CHANGELOG and in a more in depth blog post onregex crate internals as a library.

Continue Reading…

Rustfmt support for let-else statements

Rustfmt will add support for formatting let-else statements starting with the nightly 2023-07-02 toolchain, and then let-else formatting support should come to stable Rust as part of the 1.72 release.

Overview

let-else statements were stabilized back in 2022 as part of the 1.65.0 release. However, the current and previous versions of Rustfmt did not have formatting support for let-else statements. When Rustfmt encountered a let-else statement it would leave it alone and maintain the manual styling originally authored by the developer.

After updating to one of the toolchains with let-else formatting support, you may notice that cargo fmt/rustfmt invocations want to "change" the formatting of your let-else statements. However, this isn't actually a "change" in formatting, but instead is simply Rustfmt applying the let-else formatting rules for the very first time.

Rustfmt support for let-else statements has been a long standing request, and the Project has taken a number of steps to prevent a recurrence of the delay between feature stabilization and formatting support, as well as putting additional procedures in place which should enable more expeditious formatting support for nightly-only syntax.

Background and Context

Rust has an official Style Guide that articulates the default formatting style for Rust code. The Style Guide functions as a specification that defines the default formatting behavior for Rustfmt, and Rustfmt's primary mission is to provide automated formatting capabilities based around that Style Guide specification. Rustfmt is a direct consumer of the Style Guide, but Rustfmt does not unilaterally dictate what the default formatting style of language constructs should be.

The initial Style Guide was developed many years ago (beginning in 2016), and was driven by a Style Team in collaboration with the community through an RFC process. The Style Guide was then made official in 2018 via RFC 2436.

That initial Style Team was more akin to a Project Working Group in today's terms, as they had a fixed scope with a main goal to simply pull together the initial Style Guide. Accordingly that initial Style Team was disbanded once the Guide was made official.

There was subsequently no designated group within the Rust Project that was explicitly responsible for the Style Guide, and no group explicitly focused on determining the official Style for new language constructs.

The absence of a team/group with ownership of the Style Guide didn't really cause problems at first, as the new syntax that came along during the first few years was comparatively non-controversial when it came to default style and formatting. However, over time challenges started to develop when there was increasingly less community consensus and no governing team within the Project to make the final decision about how new language syntax should be styled.

This was certainly the case with let-else statements, with lots of varying perspectives on how they should be styled. Without any team/group to make the decision and update the Style Guide with the official rules for let-else statements, Rustfmt was blocked and was unable to proceed.

These circumstances around let-else statements resulted in a greater understanding across the Project of the need to establish a team to own and maintain the Style Guide. However, it was also well understood that spinning up a new team and respective processes would take some time, and the decision was made to not block the stabilization of features that were otherwise fully ready to be stabilized, like let-else statements, in the nascency of such a new team and new processes.

Accordingly, let-else statements were stabilized and released without formatting support and with an understanding that the new Style Team and then subsequently the Rustfmt Team would later complete the requisite work required to incorporate formatting support.

Steps Taken

A number of steps have been taken to improve matters in this space. This includes steps to address the aforementioned issues and deal with some of the "style debt" that accrued over the years in the absence of a Style Team, and also to establish new processes and mechanisms to bring about other formatting/styling improvements.

• Launched a new, permanent Style Team that's responsible for the Style Guide.
• Established a mechanism to evolve the default style while still maintaining stability guarantees (RFC 3338).
• Developed a nightly-syntax-policy that provides clarity around style rules for unstable/nightly-only syntax, and enables Rustfmt to provide earlier support for such syntax.

Furthermore, the Style Team is also continuing to diligently work through the backlog of those "style debt" items, and the Rustfmt team is in turn actively working on respective formatting implementation. The Rustfmt team is also focused on growing the team in order to improve contributor and review capacity.

Conclusion

We know that many have wanted let-else formatting support for a while, and we're sorry it's taken this long. We also recognize that Rustfmt now starting to format let-else statements may cause some formatting churn, and that's a highly undesirable scenario we strive to avoid.

However, we believe the benefits of delivering let-else formatting support outweigh those drawbacks. While it's possible there may be another future case or two where we have to do something similar as we work through the style backlog, we're hopeful that over time this new team and these new processes will reduce (or eliminate) the possibility of a recurrence by addressing the historical problems that played such an outsize role in the let-else delay, and also bring about various other improvements.

Both the Style and Rustfmt teams hang out on Zulip so if you'd like to get more involved or have any questions please drop by on T-Style and/or T-Rustfmt.

Continue Reading…

Improved API tokens for crates.io

If you recently generated a new API token on crates.io, you might have noticed our new API token creation page and some of the new features it now supports.

Previously, when clicking the "New Token" button on https://crates.io/settings/tokens, you were only provided with the option to choose a token name, without any additional choices. We knew that we wanted to offer our users more flexibility, but in the previous user interface that would have been difficult, so our first step was to build a proper "New API Token" page.

Our roadmap included two essential features known as "token scopes". The first of them allows you to restrict API tokens to specific operations. For instance, you can configure a token to solely enable the publishing of new versions for existing crates, while disallowing the creation of new crates. The second one offers an optional restriction where tokens can be limited to only work for specific crate names. If you want to read more about how these features were planned and implemented you can take a look at our correspondingtracking issue.

To further enhance the security of crates.io API tokens, we prioritized the implementation of expiration dates. Since we had already touched most of the token-related code this was relatively straight-forward. We are delighted to announce that our "New API Token" page now supports endpoint scopes, crate scopes and expiration dates:

Similar to the API token creation process on github.com, you can choose to not have any expiration date, use one of the presets, or even choose a custom expiration date to suit your requirements.

If you come across any issues or have questions, feel free to reach out to us onZulipor open an issue on GitHub.

Lastly, we, the crates.io team, would like to express our gratitude to theOpenSSF's Alpha-Omega Initiativeand JFrogfor their contributions to the Rust Foundationsecurity initiative. Their support has been instrumental in enabling us to implement these features and undertake extensive security-related work on the crates.io codebase over the past few months.

Continue Reading…

Introducing the Rust Leadership Council

As of today, RFC 3392 has been merged, forming the new top level governance body of the Rust Project: the Leadership Council. The creation of this Council marks the end of both the Core Team and the interim Leadership Chat.

The Council will assume responsibility for top-level governance concerns while most of the responsibilities of the Rust Project (such as maintenance of the compiler and core tooling, evolution of the language and standard libraries, administration of infrastructure, etc.) remain with the nine top level teams.

Each of these top level teams, as defined in the RFC, has chosen a representative who collectively form the Council:

• Compiler: Eric Holk
• Crates.io: Carol (Nichols || Goulding)
• Dev Tools: Eric Huss
• Infrastructure: Ryan Levick
• Language: Jack Huey
• Launching Pad1: Jonathan Pallant
• Library: Mara Bos
• Moderation: Khionu Sybiern
• Release: Mark Rousskov

First, we want to take a moment to thank the Core Team and interim Leadership Chat for the hard work they've put in over the years. Their efforts have been critical for the Rust Project. However, we do recognize that the governance of the Rust Project has had its shortcomings. We hope to build on the successes and improve upon the failures to ultimately lead to greater transparency and accountability.

We know that there is a lot of work to do and we are eager to get started. In the coming weeks we will be establishing the basic infrastructure for the group, including creating a plan for regular meetings and a process for raising agenda items, setting up a team repository, and ultimately completing the transition from the former Rust leadership structures.

We will post more once this bootstrapping process has been completed.

1. The RFC defines the launching pad team as a temporary umbrella team to represent subteams that do not currently have a top-level team. ↩

Continue Reading…

Announcing Rust 1.70.0

The Rust team is happy to announce a new version of Rust, 1.70.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.70.0 with:

rustup update stable

If 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.70.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!

What's in 1.70.0 stable

Sparse by default for crates.io

Cargo's "sparse" protocol is now enabled by default for reading the index from crates.io. This feature was previously stabilized with Rust 1.68.0, but still required configuration to use that with crates.io. The announced plan was to make that the default in 1.70.0, and here it is!

You should see substantially improved performance when fetching information from the crates.io index. Users behind a restrictive firewall will need to ensure that access to https://index.crates.io is available. If for some reason you need to stay with the previous default of using the git index hosted by GitHub, the registries.crates-io.protocol config setting can be used to change the default.

One side-effect to note about changing the access method is that this also changes the path to the crate cache, so dependencies will be downloaded anew. Once you have fully committed to using the sparse protocol, you may want to clear out the old $CARGO_HOME/registry/*/github.com-* paths.

OnceCell and OnceLock

Two new types have been stabilized for one-time initialization of shared data, OnceCell and its thread-safe counterpart OnceLock. These can be used anywhere that immediate construction is not wanted, and perhaps not even possible like non-const data in global variables.

use std::sync::OnceLock;

static WINNER: OnceLock<&str> = OnceLock::new();

fn main() {
    let winner = std::thread::scope(|s| {
        s.spawn(|| WINNER.set("thread"));

        std::thread::yield_now(); // give them a chance...

        WINNER.get_or_init(|| "main")
    });

    println!("{winner} wins!");
}

Crates such as lazy_static and once_cell have filled this need in the past, but now these building blocks are part of the standard library, ported from once_cell's unsync and sync modules. There are still more methods that may be stabilized in the future, as well as companion LazyCell and LazyLock types that store their initializing function, but this first step in stabilization should already cover many use cases.

IsTerminal

This newly-stabilized trait has a single method, is_terminal, to determine if a given file descriptor or handle represents a terminal or TTY. This is another case of standardizing functionality that existed in external crates, like atty and is-terminal, using the C library isatty function on Unix targets and similar functionality elsewhere. A common use case is for programs to distinguish between running in scripts or interactive modes, like presenting colors or even a full TUI when interactive.

use std::io::{stdout, IsTerminal};

fn main() {
    let use_color = stdout().is_terminal();
    // if so, add color codes to program output...
}

Named levels of debug information

The -Cdebuginfo compiler option has previously only supported numbers 0..=2 for increasing amounts of debugging information, where Cargo defaults to 2 in dev and test profiles and 0 in release and bench profiles. These debug levels can now be set by name: "none" (0), "limited" (1), and "full" (2), as well as two new levels, "line-directives-only" and "line-tables-only".

The Cargo and rustc documentation both called level 1 "line tables only" before, but it was more than that with information about all functions, just not types and variables. That level is now called "limited", and the new "line-tables-only" level is further reduced to the minimum needed for backtraces with filenames and line numbers. This may eventually become the level used for -Cdebuginfo=1. The other line-directives-only level is intended for NVPTX profiling, and is otherwise not recommended.

Note that these named options are not yet available to be used via Cargo.toml. Support for that will be available in the next release 1.71.

Enforced stability in the test CLI

When #[test] functions are compiled, the executable gets a command-line interface from the test crate. This CLI has a number of options, including some that are not yet stabilized and require specifying -Zunstable-options as well, like many other commands in the Rust toolchain. However, while that's only intended to be allowed in nightly builds, that restriction wasn't active in test -- until now. Starting with 1.70.0, stable and beta builds of Rust will no longer allow unstable test options, making them truly nightly-only as documented.

There are known cases where unstable options may have been used without direct user knowledge, especially --format json used in IntelliJ Rust and other IDE plugins. Those projects are already adjusting to this change, and the status of JSON output can be followed in its tracking issue.

Stabilized APIs

• NonZero*::MIN/MAX
• BinaryHeap::retain
• Default for std::collections::binary_heap::IntoIter
• Default for std::collections::btree_map::{IntoIter, Iter, IterMut}
• Default for std::collections::btree_map::{IntoKeys, Keys}
• Default for std::collections::btree_map::{IntoValues, Values}
• Default for std::collections::btree_map::Range
• Default for std::collections::btree_set::{IntoIter, Iter}
• Default for std::collections::btree_set::Range
• Default for std::collections::linked_list::{IntoIter, Iter, IterMut}
• Default for std::vec::IntoIter
• Default for std::iter::Chain
• Default for std::iter::Cloned
• Default for std::iter::Copied
• Default for std::iter::Enumerate
• Default for std::iter::Flatten
• Default for std::iter::Fuse
• Default for std::iter::Rev
• Default for std::slice::Iter
• Default for std::slice::IterMut
• Rc::into_inner
• Arc::into_inner
• std::cell::OnceCell
• Option::is_some_and
• NonNull::slice_from_raw_parts
• Result::is_ok_and
• Result::is_err_and
• std::sync::atomic::Atomic*::as_ptr
• std::io::IsTerminal
• std::os::linux::net::SocketAddrExt
• std::os::unix::net::UnixDatagram::bind_addr
• std::os::unix::net::UnixDatagram::connect_addr
• std::os::unix::net::UnixDatagram::send_to_addr
• std::os::unix::net::UnixListener::bind_addr
• std::path::Path::as_mut_os_str
• std::sync::OnceLock

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.70.0

Many people came together to create Rust 1.70.0. We couldn't have done it without all of you. Thanks!

Continue Reading…

On the RustConf keynote

On May 26th 2023, JeanHeyd Meneide announced they would not speak at RustConf 2023 anymore. They were invited to give a keynote at the conference, only to be told two weeks later the keynote would be demoted to a normal talk, due to a decision made within the Rust project leadership.

That decision was not right, and first off we want to publicly apologize for the harm we caused. We failed you JeanHeyd. The idea of downgrading a talk after the invitation was insulting, and nobody in leadership should have been willing to entertain it.

Everyone in leadership chat is still working to fully figure out everything that went wrong and how we can prevent all of this from happening again. That work is not finished yet. Still, we want to share some steps we are taking to reduce the risk of something like this from happening again.

The primary causes of the failure were the decision-making and communication processes of leadership chat. Leadership chat has been the top-level governance structure created after the previous Moderation Team resigned in late 2021. It’s made of all leads of top-level teams, all members of the Core Team, all project directors on the Rust Foundation board, and all current moderators. This leadership chat was meant as a short-term solution and lacked clear rules and processes for decision making and communication. This left a lot of room for misunderstandings about when a decision had actually been made and when individuals were speaking for the project versus themselves.

In this post we focus on the organizational and process failure, leaving room for individuals to publicly acknowledge their own role. Nonetheless, formal rules or governance processes should not be required to identify that demoting JeanHeyd’s keynote was the wrong thing to do. The fact is that several individuals exercised poor judgment and poor communication. Recognizing their outsized role in the situation, those individuals have opted to step back from top-level governance roles, including leadership chat and the upcoming leadership council.

Organizationally, within leadership chat we will enforce a strict consensus rule for all decision making, so that there is no longer ambiguity of whether something is an individual opinion or a group decision. We are going to launch the new governance council as soon as possible. We’ll assist the remaining teams to select their representatives in a timely manner, so that the new governance council can start and the current leadership chat can disband.

We wish to close the post by reiterating our apology to JeanHeyd, but also the wider Rust community. You deserved better than you got from us.

-- The members of leadership chat

Continue Reading…

Updating Rust's Linux musl targets

Beginning with Rust 1.71 (slated for stable release on 2023-07-13), the various *-linux-musl targets will ship with musl 1.2.3. These targets currently use musl 1.1.24. While musl 1.2.3 introduces some new features, most notably 64-bit time on all platforms, it is ABI compatible with earlier musl versions.

As such, this change is unlikely to affect you.

Updated targets

The following targets will be updated:

Target

Support Tier

aarch64-unknown-linux-musl

Tier 2 with Host Tools

x86_64-unknown-linux-musl

Tier 2 with Host Tools

arm-unknown-linux-musleabi

Tier 2

arm-unknown-linux-musleabihf

Tier 2

armv5te-unknown-linux-musleabi

Tier 2

armv7-unknown-linux-musleabi

Tier 2

armv7-unknown-linux-musleabihf

Tier 2

i586-unknown-linux-musl

Tier 2

i686-unknown-linux-musl

Tier 2

mips-unknown-linux-musl

Tier 2

mips64-unknown-linux-muslabi64

Tier 2

mips64el-unknown-linux-muslabi64

Tier 2

mipsel-unknown-linux-musl

Tier 2

hexagon-unknown-linux-musl

Tier 3

mips64-openwrt-linux-musl

Tier 3

powerpc-unknown-linux-musl

Tier 3

powerpc64-unknown-linux-musl

Tier 3

powerpc64le-unknown-linux-musl

Tier 3

riscv32gc-unknown-linux-musl

Tier 3

riscv64gc-unknown-linux-musl

Tier 3

s390x-unknown-linux-musl

Tier 3

thumbv7neon-unknown-linux-musleabihf

Tier 3

Note: musl 1.2.3 does not raise the minimum required Linux kernel version for any target.

Will 64-bit time break the libc crate on 32-bit targets?

No, the musl project made this change carefully preserving ABI compatibility. The libc crate will continue to function correctly without modification.

A future version of the libc crate will update the definitions of time-related structures and functions to be 64-bit on all musl targets however this is blocked on the musl targets themselves first being updated. At present, there is no anticipated date when this change will take place and care will be taken to help the Rust ecosystem transition successfully to the updated time-related definitions.

Continue Reading…

Announcing Rustup 1.26.0

The rustup working group is happy to announce the release of rustup version 1.26.0. Rustup is the recommended tool to install Rust, a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of rustup installed, getting rustup 1.26.0 is as easy as stopping any programs which may be using Rustup (e.g. closing your IDE) and running:

rustup self update

Rustup will also automatically update itself at the end of a normal toolchain update:

rustup update

If you don't have it already, you can get rustup from the appropriate page on our website.

What's new in rustup 1.26.0

This version of Rustup involves a significant number of internal cleanups, both in terms of the Rustup code and its tests. In addition to a lot of work on the codebase itself, due to the length of time since the last release this one has a record number of contributors and we thank you all for your efforts and time.

The headlines for this release are:

1. Add rust-analyzer as a proxy of rustup. Now you can call rust-analyzer and it will be proxied to the rust-analyzer component for the current toolchain.
2. Bump the clap dependency from 2.x to 3.x. It's a major version bump, so there are some help text changes, but the command line interface is unchanged.
3. Remove experimental GPG signature validation and the rustup show keys command. Due to its experimental status, validating the integrity of downloaded binaries did not rely on it, and there was no option to abort the installation if a signature mismatch happened. Multiple problems with its implementation were discovered in the recent months, which led to the decision to remove the experimental code. The team is working on the design of a new signature validation scheme, which will be implemented in the future.

Full details are available in the changelog!

Rustup's documentation is also available in the rustup book.

Thanks

Thanks again to all the contributors who made rustup 1.26.0 possible!

• Daniel Silverstone (kinnison)
• Sabrina Jewson (SabrinaJewson)
• Robert Collins (rbtcollins)
• chansuke (chansuke)
• Shamil (shamilsan)
• Oli Lalonde (olalonde)
• 二手掉包工程师 (hi-rustin)
• Eric Huss (ehuss)
• J Balint BIRO (jbalintbiro)
• Easton Pillay (jedieaston)
• zhaixiaojuan (zhaixiaojuan)
• Chris Denton (ChrisDenton)
• Martin Geisler (mgeisler)
• Lucio Franco (LucioFranco)
• Nicholas Bishop (nicholasbishop)
• SADIK KUZU (sadikkuzu)
• darkyshiny (darkyshiny)
• René Dudfield (illume)
• Noritada Kobayashi (noritada)
• Mohammad AlSaleh (MoSal)
• Dustin Martin (dmartin)
• Ville Skyttä (scop)
• Tshepang Mbambo (tshepang)
• Illia Bobyr (ilya-bobyr)
• Vincent Rischmann (vrischmann)
• Alexander (Alovchin91)
• Daniel Brotsky (brotskydotcom)
• zohnannor (zohnannor)
• Joshua Nelson (jyn514)
• Prikshit Gautam (gautamprikshit1)
• Dylan Thacker-Smith (dylanahsmith)
• Jan David (jdno)
• Aurora (lilith13666)
• Pietro Albini (pietroalbini)
• Renovate Bot (renovate-bot)

Continue Reading…

Announcing Rust 1.69.0

The Rust team is happy to announce a nice version of Rust, 1.69.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.69.0 with:

rustup update stable

If 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.69.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!

What's in 1.69.0 stable

Rust 1.69.0 introduces no major new features. However, it contains many small improvements, including over 3,000 commits from over 500 contributors.

Cargo now suggests to automatically fix some warnings

Rust 1.29.0 added the cargo fix subcommand to automatically fix some simple compiler warnings. Since then, the number of warnings that can be fixed automatically continues to steadily increase. In addition, support for automatically fixing some simple Clippy warnings has also been added.

In order to draw more attention to these increased capabilities, Cargo will now suggest running cargo fix or cargo clippy --fix when it detects warnings that are automatically fixable:

warning: unused import: `std::hash::Hash`
 --> src/main.rs:1:5
  |
1 | use std::hash::Hash;
  |     ^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: `foo` (bin "foo") generated 1 warning (run `cargo fix --bin "foo"` to apply 1 suggestion)

Note that the full Cargo invocation shown above is only necessary if you want to precisely apply fixes to a single crate. If you want to apply fixes to all the default members of a workspace, then a simple cargo fix (with no additional arguments) will suffice.

Debug information is not included in build scripts by default anymore

To improve compilation speed, Cargo now avoids emitting debug information in build scripts by default. There will be no visible effect when build scripts execute successfully, but backtraces in build scripts will contain less information.

If you want to debug a build script, you can add this snippet to your Cargo.toml to emit debug information again:

[profile.dev.build-override]
debug = true
[profile.release.build-override]
debug = true

Stabilized APIs

• CStr::from_bytes_until_nul
• core::ffi::FromBytesUntilNulError

These APIs are now stable in const contexts:

• SocketAddr::new
• SocketAddr::ip
• SocketAddr::port
• SocketAddr::is_ipv4
• SocketAddr::is_ipv6
• SocketAddrV4::new
• SocketAddrV4::ip
• SocketAddrV4::port
• SocketAddrV6::new
• SocketAddrV6::ip
• SocketAddrV6::port
• SocketAddrV6::flowinfo
• SocketAddrV6::scope_id

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.69.0

Many people came together to create Rust 1.69.0. We couldn't have done it without all of you. Thanks!

Continue Reading…

Announcing Rust 1.68.2

The Rust team has published a new point release of Rust, 1.68.2. Rust is a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.68.2 with:

rustup update stable

If you don't have it already, you can get rustupfrom the appropriate page on our website, and check out thedetailed release notes for 1.68.2 on GitHub.

What's in 1.68.2 stable

Rust 1.68.2 addresses GitHub's recent rotation of their RSA SSH host key, which happened on March 24th 2023 after their previous key accidentally leaked:

• GitHub's RSA key bundled in Cargo has been updated, to ensure systems that haven't interacted with GitHub yet won't connect trusting the leaked key.
• The leaked key has been hardcoded as revoked in Cargo, to ensure the key won't be used by Cargo even on systems that still trust the key.

Support for @revoked entries in.ssh/known_hosts (along with a better error message when the unsupported @cert-authority entries are used) is also included in Rust 1.68.2, as that change was a pre-requisite for backporting the hardcoded revocation.

If you cannot upgrade to Rust 1.68.2, we recommend following GitHub's instructionson updating the trusted keys in your system. Note that the keys bundled in Cargo are only used if no trusted key for github.com is found on the system.

Contributors to 1.68.2

Many people came together to create Rust 1.68.2. We couldn't have done it without all of you. Thanks!

Continue Reading…

Announcing Rust 1.68.1

The Rust team has published a new point release of Rust, 1.68.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.68.1 with:

rustup update stable

If you don't have it already, you can get rustupfrom the appropriate page on our website, and check out thedetailed release notes for 1.68.1 on GitHub.

What's in 1.68.1 stable

Rust 1.68.1 stable primarily contains a change to how Rust's CI builds the Windows MSVC compiler, no longer enabling LTO for the Rust code. This led to amiscompilation that the Rust team is debugging, but in the meantime we're reverting the change to enable LTO.

This is currently believed to have no effect on wider usage of ThinLTO. The Rust compiler used an unstable flag as part of the build process to enable ThinLTO despite compiling to a dylib.

There are a few other regression fixes included in the release:

• Fix building the compiler with --enable-local-rust
• Treat $prefix-clang as clang in linker detection code
• Fix a panic in the compiler

Contributors to 1.68.1

Many people came together to create Rust 1.68.1. We couldn't have done it without all of you. Thanks!

Continue Reading…

Announcing Rust 1.68.0

The Rust team is happy to announce a new version of Rust, 1.68.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.68.0 with:

rustup update stable

If you don't have it already, you can getrustup from the appropriate page on our website, and check out the detailed release notes for 1.68.0on 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). Pleasereport any bugs you might come across!

What's in 1.68.0 stable

Cargo's sparse protocol

Cargo's "sparse" registry protocol has been stabilized for reading the index of crates, along with infrastructure at https://index.crates.io/ for those published in the primary crates.io registry. The prior git protocol (which is still the default) clones a repository that indexes all crates available in the registry, but this has started to hit scaling limitations, with noticeable delays while updating that repository. The new protocol should provide a significant performance improvement when accessing crates.io, as it will only download information about the subset of crates that you actually use.

To use the sparse protocol with crates.io, set the environment variableCARGO_REGISTRIES_CRATES_IO_PROTOCOL=sparse, or edit your.cargo/config.toml fileto add:

[registries.crates-io]
protocol = "sparse"

The sparse protocol is currently planned to become the default for crates.io in the 1.70.0 release in a few months. For more information, please see the priorannouncementon the Inside Rust Blog, as well asRFC 2789and the currentdocumentationin the Cargo Book.

Local Pin construction

The new pin! macro constructs a Pin<&mut T> from a T expression, anonymously captured in local state. This is often called stack-pinning, but that "stack" could also be the captured state of an async fn or block. This macro is similar to some crates, like tokio::pin!, but the standard library can take advantage of Pin internals and temporary lifetime extensionfor a more expression-like macro.

/// Runs a future to completion.
fn block_on<F: Future>(future: F) -> F::Output {
    let waker_that_unparks_thread = todo!();
    let mut cx = Context::from_waker(&waker_that_unparks_thread);
    // Pin the future so it can be polled.
    let mut pinned_future = pin!(future);
    loop {
        match pinned_future.as_mut().poll(&mut cx) {
            Poll::Pending => thread::park(),
            Poll::Ready(result) => return result,
        }
    }
}

In this example, the original future will be moved into a temporary local, referenced by the new pinned_future with type Pin<&mut F>, and that pin is subject to the normal borrow checker to make sure it can't outlive that local.

Default alloc error handler

When allocation fails in Rust, APIs like Box::new and Vec::push have no way to indicate that failure, so some divergent execution path needs to be taken. When using the std crate, the program will print to stderr and abort. As of Rust 1.68.0, binaries which include std will continue to have this behavior. Binaries which do not include std, only including alloc, will now panic!on allocation failure, which may be further adjusted via a #[panic_handler] if desired.

In the future, it's likely that the behavior for std will also be changed to match that of alloc-only binaries.

Stabilized APIs

• {core,std}::pin::pin!
• impl From for {f32,f64}
• std::path::MAIN_SEPARATOR_STR
• impl DerefMut for PathBuf

These APIs are now stable in const contexts:

• VecDeque::new

Other changes

• As previously announced, Android platform support in Rust is now targeting NDK r25, which corresponds to a minimum supported API level of 19 (KitKat).

Check out everything that changed inRust,Cargo, and Clippy.

Contributors to 1.68.0

Many people came together to create Rust 1.68.0. We couldn't have done it without all of you.Thanks!

Continue Reading…

Announcing Rust 1.67.1

The Rust team has published a new point release of Rust, 1.67.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.67.1 with:

rustup update stable

If you don't have it already, you can get rustupfrom the appropriate page on our website, and check out thedetailed release notes for 1.67.1 on GitHub.

What's in 1.67.1 stable

Rust 1.67.1 fixes a regression for projects that link to thin archives (.a files that reference external .o objects). The new archive writer in 1.67.0 could not read thin archives as inputs, leading to the error "Unsupported archive identifier." The compiler now uses LLVM's archive writer again, until that format is supported in the new code.

Additionally, the clippy style lint uninlined_format_args is temporarily downgraded to pedantic -- allowed by default. While the compiler has supported this format since Rust 1.58, rust-analyzer does not support it yet, so it's not necessarily good to use that style everywhere possible.

The final change is a soundness fix in Rust's own bootstrap code. This had no known problematic uses, but it did raise an error when bootstrap was compiled with 1.67 itself, rather than the prior 1.66 release as usual.

Contributors to 1.67.1

Many people came together to create Rust 1.67.1. We couldn't have done it without all of you. Thanks!

Continue Reading…

Announcing Rustup 1.25.2

The rustup working group is announcing the release of rustup version 1.25.2. Rustup is the recommended tool to install Rust, a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of rustup installed, getting rustup 1.25.2 is as easy as stopping any programs which may be using Rustup (e.g. closing your IDE) and running:

rustup self update

Rustup will also automatically update itself at the end of a normal toolchain update:

rustup update

If you don't have it already, you can get rustup from the appropriate page on our website.

What's new in rustup 1.25.2

This version of rustup fixes a warning incorrectly saying that signature verification failed for Rust releases. The warning was due to a dependency of Rustup including a time-based check preventing the use of SHA-1 from February 1st, 2023 onwards.

Unfortunately Rust's release signing key uses SHA-1 to sign its subkeys, which resulted in all signatures being marked as invalid. Rustup 1.25.2 temporarily fixes the problem by allowing again the use of SHA-1.

Why is signature verification failure only a warning?

Signature verification is currently an experimental and incomplete feature included in rustup, as it's still missing crucial features like key rotation. Until the feature is complete and ready for use, its outcomes are only displayed as warnings without a way to turn them into errors.

This is done to avoid potentially breaking installations of rustup. Signature verification will error out on failure only after the design and implementation of the feature will be finished.

Thanks

Thanks again to all the contributors who made rustup 1.25.2 possible!

• Daniel Silverstone (kinnison)
• Pietro Albini (pietroalbini)

Continue Reading…