For most of 2018, we've been issue warnings about various bugs in the borrow checker that we plan to fix -- about two months ago, in the current Rust nightly, those warnings became hard errors. In about two weeks, when the nightly branches to become beta, those hard errors will be in the beta build, and they will eventually hit stable on December 19th, as part of Rust 1.40.0. If you're testing with Nightly, you should be all set -- but otherwise, you may want to go and check to make sure your code still builds. If not, we have advice for fixing common problems below.
Background: the non-lexical lifetime transition
When we released Rust 2018 in Rust 1.31, it included a new version of the borrow checker, one that implemented "non-lexical lifetimes". This new borrow checker did a much more precise analysis than the original, allowing us to eliminate a lot of unnecessary errors and make Rust easier to use. I think most everyone who was using Rust 2015 can attest that this shift was a big improvement.
The new borrow checker also fixed a lot of bugs
What is perhaps less well understood is that the new borrow checker implementation also fixed a lot of bugs. In other words, the new borrow checker did not just accept more programs -- it also rejected some programs that never should have been accepted in the first place!
Until recently, those fixed bugs produced warnings, not errors
As part of our commitment to stability, whenever we find bugs that impact existing code in a major way, we try to "phase in" those changes gradually. We usually begin with "Future Compatibility Warnings", for example, before moving those warnings to hard errors (sometimes a small bit at a time). Since the bug fixes to the borrow checker affected a lot of crates, we knew we needed a warning period before we could make them into hard errors.
To implement this warning period, we kept two copies of the borrow checker around (this is a trick we use quite frequently, actually). The new checker ran first. If it found errors, we didn't report them directly: instead, we ran the old checker in order to see if the crate used to compile before. If so, we reported the errors as Future Compatibility Warnings, since we were changing something that used to compile into errors.
All good things must come to an end; and bad ones, too
Over time we have been slowly transitioning those future compatibility warnings into errors, a bit at a time. About two months ago, we decided that the time had come to finish the job. So, over the course of two PRs, we converted all remaining warnings to errors and then removed the old borrow checker implementation.
What this means for you
If you are testing your package with nightly, then you should be fine. In fact, even if you build on stable, we always recommend that you test your builds in CI with the nightly build, so that you can identify upcoming issues early and report them to us.
Otherwise, you may want to check your dependencies. When we
decided to remove the old borrow checker, we also analyzed which
crates would stop compiling. For anything that seemed to be widely
used, we made sure that there were newer versions of that crate
available that do compile (for the most part, this had all already
happened during the warning period). But if you have those older
versions in your
Cargo.lock file, and you are only using stable
builds, then you may find that your code no longer builds once 1.40.0
is released -- you will have to upgrade the dependency.
The most common crates that were affected are the following:
urlversion 1.7.0 -- you can upgrade to 1.7.2, though you'd be better off upgrading to 2.1.0
nalgebraversion 0.16.13 -- you can upgrade to 0.16.14, though you'd be better off upgrading to 0.19.0
You can find out which crates you rely upon using the cargo-tree command. If you find
that you do rely (say) on
url 1.7.0, you can upgrade to 1.7.2 by executing:
cargo update -p url --vers 1.7.2
Want to learn more?
If you'd like to learn more about the kinds of bugs that were fixed -- or if you are seeing errors in your code that you need to fix -- take a look at this excellent blog post by Felix Klock, which goes into great detail.