revisions

Author: steveklabnik

_posts/2018-03-01-Rust-1.24.1.md

@@ -23,29 +23,28 @@ appropriate page on our website, and check out the [detailed release notes for
 
 ## What's in 1.24.1 stable
 
-As you know, we tend not to release point releases. In this case, we had a few regressions in 1.24.0.
-Each of them individually was not a "hair on fire" moment, but there's two reasons we decided to
-produce a point release. First, collectively, they were big enough to consider as a whole. Second, we
-want our attitude towards regressions to be "if we're not sure, default to reverting." Given that
-it was not clear that we *shouldn't* release a point release, we decided to err on the side of
-caution.
+As you know, we tend not to release point releases. In this case, Several minor
+regressions were found in 1.24.0 which collectively merited a release.
 
 A quick summary of the changes: there are four.
 
-* Do not abort when unwinding through FFI
+* Do not abort when unwinding through FFI (this reverts behavior from 1.24.0)
 * Emit UTF-16 files for linker arguments on Windows
 * Make the error index generator work again
 * Cargo will warn on Windows 7 if an update is needed.
 
-In general, if you haven't run into any build issues, the "do not abort when unwinding through FFI"
-change is the only one you should care about. The others are also important, but if 1.24.0 has been
-working well for you, this is the only change that affects you. We plan on bringing this behavior back
-in 1.25 or 1.26, depending on how smoothly the new strategy goes.
+If your code is continuing to build, then the only issue that may affect you is
+the unwinding issue. We plan on bringing this behavior back in 1.25 or 1.26,
+depending on how smoothly the new strategy goes.
 
 With that, let's dig into the details!
 
 ### Do not abort when unwinding through FFI
 
+TL;DR: the behavior in 1.24.0 broke the `rlua` crate, and is being reverted. If
+you have since changed your code to take advantage of the behavior in 1.24.0,
+you'll need to revert it for now.
+
 Quoting [the 1.24 annoucement](https://blog.rust-lang.org/2018/02/15/Rust-1.24.html):
 
 > There’s one other change we’d like to talk about here: undefined behavior.
@@ -65,9 +64,11 @@ extern "C" fn panic_in_ffi() {
 >
 > In Rust 1.24, this code will now abort instead of producing undefined behavior.
 
-We have reverted this behavior, and 1.24.1 will reintroduce the undefined behavior.
-Fundamentally, this is a soundness fix, and we still plan on reintroducing the
-abort, but are going to be rolling it out a bit more slowly, and with a different
+As implemented, this functionality broke some users, notably, integration with
+the Lua language. We have reverted this behavior, and 1.24.1 will reintroduce
+the undefined behavior. Fundamentally, the aborting behavior we originally
+rolled out is a soundness fix, and we still plan on reintroducing it, but are
+going to be rolling it out a bit more slowly, and with a different
 implementation.
 
 It started with [a bug filed against the `rlua`
@@ -81,9 +82,9 @@ language](https://www.lua.org/).
 > production Rust users, and so handling this was a very high priority for the
 > Rust team.
 
-In short, `rlua` error handling just... broke. On Windows, and only on Windows,
-any attempt to handle errors from Lua would simply abort. This makes `rlua`
-unusable, as any error of any kind within Lua causes your program to die.
+On Windows, and only on Windows, any attempt to handle errors from Lua would
+simply abort. This makes `rlua` unusable, as any error of any kind within Lua
+causes your program to die.
 
 After digging in, the culpurit was found: `setjmp`/`longjmp`. These functions
 are provided by the C standard library as a means of handling errors. You
@@ -121,7 +122,7 @@ When we talked about `setjmp`/`longjmp` inititally, a key phrase here wasn't
 highlighted. Here it is:
 
 > After digging in, the culpurit was found: `setjmp`/`longjmp`. These functions
-> are *provided by the C standard library* as a means of handling errors. You
+> are *provided by the C standard library* as a means of handling errors.
 
 These functions aren't part of the C language, but part of the standard
 library. That means that platform authors implement these functions, and
@@ -156,9 +157,10 @@ Consider the code above, and imagine that `lua_newtable` here could call
 3. The initial `lua_pcall` catches the `longjmp` with the `setjmp` it called earlier.
 4. Everyone is happy.
 
-However, `lua_newtable` is an `extern fn` to Rust. So, with the chances in
-1.24.1, it sets up a panic handler that will cause an abort. In other words,
-the code sorta looks something like this psuedo code now:
+However, the implementation of `protect_lua_call` converts our closure to an
+`extern fn`, since that's what Lua needs. So, with the changes in 1.24.0, it
+sets up a panic handler that will cause an abort. In other words, the code
+sorta looks something like this pseudo code now:
 
 ```rust
 protect_lua_call(self.state, 0, 1, |state| {
@@ -179,14 +181,15 @@ everything works. However, on Windows, since both `setjmp`/`longjmp` and Rust
 panics use SEH, the `longjmp` gets "caught", and runs the new abort code!
 
 The [solution here](https://github.com/rust-lang/rust/pull/48572) is to
-generate the abort handler, but in a way that `longjmp` won't trigger. Eventually,
-it's likely we'll have to register our own personality functions and such, but
-this is good enough for now. It's not 100% clear if this will make it into Rust 1.25;
-if the landing is smooth, we may backport, otherwise, this functionality will
-be back in 1.26.
+generate the abort handler, but in a way that `longjmp` won't trigger it.  It's
+not 100% clear if this will make it into Rust 1.25; if the landing is smooth,
+we may backport, otherwise, this functionality will be back in 1.26.
 
 ### Emit UTF-16 files for linker arguments on Windows
 
+TL;DR: `rustc` stopped working for some Windows users. If it's been working for you,
+you were not affected by this bug.
+
 In constrast with the previous bug, which is very complex and tough to understand,
 this bug's impact is simple: if you have non-ASCII paths in the directory where
 you invoke `rustc`, in 1.24, it would incorrectly error with a message like
@@ -214,13 +217,20 @@ straightforward: produce a UTF-16 file with a BOM.
 
 ### Make the error index generator work again
 
+TL;DR: building Rust 1.24.0 with Rust 1.24.0 broke in some circumstances.
+If you weren't building Rust yourself, you were not affected by this bug.
+
 When packaging Rust for various Linux distros, it was found that [building
 1.24 with 1.24 fails](https://github.com/rust-lang/rust/issues/48308).
 This was caused by an incorrect path, causing certain metadata to not
 be generated properly.
 
 ### Cargo will warn on Windows 7 if an update is needed.
 
+TL;DR: Cargo couldn't fetch the index from crates.io if you were using an older
+Windows without having applied security fixes. If you are using a newer
+Windows, or a patched Windows, you are not affected by this bug.
+
 In February of 2017, [GitHub announced that they were dropping support for
 weak cryptographic
 standards](https://githubengineering.com/crypto-deprecation-notice/). One
@@ -248,9 +258,10 @@ that accessing GitHub would start to fail.
 `libgit2` [created a fix](https://github.com/libgit2/libgit2/pull/4550), using the `WinHTTP` API
 to request TLS 1.2. On master, we've [updated to fix this](https://github.com/rust-lang/cargo/pull/5091),
 but for 1.24.1 stable, we're [issuing a warning](https://github.com/rust-lang/cargo/pull/5069),
-suggesting that they upgrade their Windows version. There's a balance here: we could have backported
-the `libgit2` fixes, but that'd require updating a lot of code, which feels incorrect for a point
-release, especially since the issue does not affect patched systems.
+suggesting that they upgrade their Windows version. Although the `libgit2` fix
+could have been backported, we felt that the code change footprint was too
+large for the point release, especially since the issue does not affect patched
+systems.
 
 ## Contributors to 1.24.1