Upcoming breakage starting in Rust 1.7, from RFCs 1214 and 136


#1

Greetings, and happy new year.

I bring you the gift of breakage.

Yes, that’s right. There’s Rust breakage on the way, and its
significant enough that we need to get the word out. Brace yourselves.

We’ve got two major soundness / type system fixes in the pipeline: the
first for RFC 1214, the second for RFC 136. These are in the class
of breaking changes considered necessary and allowable for
correctness, as originally described in RFC 1122.

We have been introducing this type of breakage in stages across
several release cycles, first by implementing a warning for code that
will be affected then, after a few releases, converting to an
error. The hope is that authors of affected crates will notice the
warning and publish new revisions prior to the stable release that
turns the errors on.

The first breaking change, and most impactful of the two, RFC
1214
, is to fix some complex soundness issues around what can be
written in an associated type (see the RFC for details). The changes
here were originally released in version 1.4 on October 29, with (most
of) the new error cases generating warnings about the impending
breakage.

Current nightlies have turned these warnings into errors, and we’ve
witnessed a large number of crates breaking because of
it
. This change is scheduled to hit stable on March 3, so
there is still some time to ameliorate the impact. Below is the list
of crates currently known to be broken because of this change. If you
are the author of one of these I encourage you to take a look.

  • bchannel-0.0.9
  • columnar-0.0.17
  • cbox-0.2.2
  • genetic-0.2.1
  • git-hive-protocol-0.2.3
  • grabbag-0.1.0
  • actors-0.1.0
  • atpp-1.6.6
  • ldap-0.0.4
  • containerof-0.2.1
  • cortex-0.1.5
  • pistoncore-event-0.4.0
  • pool-0.1.3
  • reactive-streams-0.0.1
  • rust-sqlite-0.2.0
  • RustyEmitter-2.1.0
  • stomp-0.11.0
  • twiddle-0.1.0
  • units-0.1.0
  • fmt-extra-0.0.2
  • xdr-0.1.0

The second breaking change fixes bugs in the
the analysis that prevents modules leaking private types, as specified
in RFC 136. The new errors generated by this fix will be warnings
in 1.7, released March 3. At some undetermined point in the future
these will become hard errors

This is the first major change of this kind we’ve pushed through, so
it should provide valuable lessons for the next time. We’re happy to
hear feedback about how the process is working for you.

Thanks for your understanding. I apologize for the inconvenience.


#2

As somebody about to embark on a journey learning rust (including offline materials) - do I need to be concerned?


#3

Nope. You can think of soundness fixes as accounting for edge cases: 99% of the code you write won’t be affected. (Actually, it’s probably more like 99.99%)