ralf/_posts/2019-02-12-all-hands-recap.md

   1 ---
   2 title: "All-Hands 2019 Recap"
   3 categories: rust
   4 reddit: /rust/comments/apreqi/ucgmiri_allhands_2019_recap/
   5 ---
   6
   7 Last week, I was in Berlin at the Rust All-Hands 2019.
   8 It was great!
   9 I will miss nerding out in discussions about type theory and having every question answered by just going to the person who's the expert in that area, and asking them.
  10 In this post, I am summarizing the progress we made in my main areas of interest and the discussions I was involved in---this is obviously just a small slice of all the things that happened.
  11
  12 <!-- MORE -->
  13
  14 ## Validity Invariants and `MaybeUninit`
  15
  16 We had a session to talk about [validity invariants](https://github.com/rust-rfcs/unsafe-code-guidelines/blob/master/active_discussion/validity.md) ([meeting notes here](https://paper.dropbox.com/doc/Topic-Validity-Invariants--AXWuzG6GFwiTyUDukuPV7vDmAg-Wpl6mhrqNBStyrCHwhpYI#:uid=357396828564014720965680&h2=NOTES)).
  17 No firm conclusions were reached, but we got input from people that haven't been part of the discussions inside the UCG (unsafe code guidelines) WG yet and that was very interesting.
  18 It seems that deciding about the [validity invariant for references](https://github.com/rust-rfcs/unsafe-code-guidelines/issues/77) and (to a lesser extend) the [validity invariant for unions](https://github.com/rust-rfcs/unsafe-code-guidelines/issues/73) will be a slow process---there are lots of different options, and some of the trade-offs come down to prioritizing one value over another (like prioritizing checkable UB over optimizations, or vice versa).
  19 Probably the closest to a conclusion we reached was that [uninitialized integers should probably not be UB](https://github.com/rust-rfcs/unsafe-code-guidelines/issues/71#issuecomment-460599057) until you perform any operation on them.
  20
  21 That said, it also got clear that the sooner we can stabilize (parts of) [`MaybeUninit`](https://github.com/rust-lang/rust/issues/53491), the better.
  22 And as @japaric pointed out, we do not have to wait until all of these questions get answered!
  23 We can stabilize a subset of the API, and leave (in particular) `get_ref` and `get_mut` out of that.
  24 I think the biggest blocker for that is to get [RFC 2582](https://github.com/rust-lang/rfcs/pull/2582) accepted (which is very close to beginning its FCP).
  25 Once that is done, I think I'll just beef up the documentation a bit and submit a stabilization PR.
  26
  27 What worries me a bit is that we did not get much feedback from people using the API.
  28 It seems like everyone is waiting for it to become stable, but of course then it will be too late to fix API mistakes that we made!
  29 Given the importance of the API for certain classes of unsafe code, I think it would be great to get some more feedback before we set things in stone.
  30
  31 To finish up the API, I went ahead and renamed the method that you call when a `MaybeUninit` is fully initialized to [`into_initialized`](https://doc.rust-lang.org/nightly/std/mem/union.MaybeUninit.html#method.into_initialized), which seems, uh, good enough?
  32 I also like `assume_initialized` but that does not sound like it would return anything.
  33 One thing I wonder about is whether some of these methods should be "downgraded" to functions, forcing callers to write `MaybeUninit::into_initialized` or so.
  34 If you have an opinion on this, please [join us in the tracking issue](https://github.com/rust-lang/rust/issues/53491)!
  35
  36 ## Uninitialized Memory
  37
  38 @stjepang, @Amanieu and me talked a bit about [uninitialized data in atomic operations](https://github.com/crossbeam-rs/crossbeam/issues/315), and how to make sense of the [C++ spec](https://en.cppreference.com/w/cpp/atomic/atomic/compare_exchange), in particular in the presence of mixed atomic and non-atomic accesses to the same object using [`atomic_ref`](https://en.cppreference.com/w/cpp/atomic/atomic_ref).
  39 We did not make any notable progress, other than the possibility of a sound `AtomicCell` *without* `get_mut`.
  40
  41 Another discussion was around using [`Read::read`](https://doc.rust-lang.org/nightly/std/io/trait.Read.html#tymethod.read) to initialize memory.
  42 The problem here is that with an *unknown* `Read` implementation, we cannot just pass in an uninitialized buffer.
  43 Uninitialized data is strictly different from any particular bit pattern, and using it in any non-trivial way is UB.
  44 Since there is no way to know what the unknown `Read::read` function does, we cannot pass such bad data to it.
  45 In [my terminology](({% post_url 2018-08-22-two-kinds-of-invariants%})), even though integers with uninitialized data are (likely) *valid*, uninitialized data violates the *safety invariant* of our integer types.
  46 To solve this, the proposal is to add a [`freeze` method](https://github.com/rust-lang/rust/pull/58363) that turns all uninitialized memory into arbitrary but fixed bits.
  47 Such frozen memory admits fewer optimizations (because it must observably have a consistent value when accessed multiple times), but it is also safe to use at any integer type (for the same reason).<br>
  48 The main reason I like this proposal is that it officially acknowledges the subtle but important distinction between "arbitrary bit pattern" and "uninitialized", and that should help a lot with teaching these concepts to unsafe code authors.
  49
  50 ## Stacked Borrows
  51
  52 Finally, there was some discussion about [Stacked Borrows](https://github.com/RalfJung/unsafe-code-guidelines/blob/stacked-borrows/wip/stacked-borrows.md) ([meeting notes here](https://paper.dropbox.com/doc/Topic-Stacked-borrows--AXUlwiiCbkUsrhfLWPy43~yiAg-2q57v4UM7cIkxCq9PQc22#:uid=304192866787878821395738&h2=NOTES)).
  53 The feedback was very positive, and (to my surprise) everybody agreed that the things I had to change in the standard library to make it conform with the model were appropriate bugfixes.
  54 @arielb1 and @matthewjesper helped a lot with detailed discussions about some of the [remaining issues](https://github.com/rust-rfcs/unsafe-code-guidelines/issues?q=is%3Aissue+is%3Aopen+label%3Atopic-stacked-borrows) in the model, as well as figuring out a plan to fix a problem [found by @Amanieu](https://github.com/solson/miri/issues/615).
  55 However, [two-phase borrows remain a problem](https://github.com/rust-lang/rust/issues/56254).
  56
  57 ## Miri now tests libcore and liballoc
  58
  59 I am particularly happy about the progress I made on [Miri](https://github.com/solson/miri/) during this week.
  60 With help from @eddyb and @alexcrichton, I got Miri to run the libcore and liballoc unit test suites.
  61 This has already helped to [uncover a bug](https://github.com/rust-lang/rust/pull/58200) and some [subtle undocumented invariants](https://github.com/rust-lang/rust/issues/58320) in the standard library, as well as [several](https://github.com/solson/miri/pull/625) bugs [in Miri](https://github.com/rust-lang/rust/pull/58324).
  62 I have [set things up](https://github.com/RalfJung/miri-test-libstd) such that Miri will run these tests every night, giving us higher confidence that the standard library is free of undefined behavior---or rather, that the parts of the standard library that are covered by unit tests are free of undefined behavior that Miri can detect.
  63 I've been partially working towards this goal for several months now, so it is really satisfying to see it all come together. :-)
  64
  65 Moreover, @Amanieu ran Miri on hashbrown, not discovering a bug in his crate but running into [several](https://github.com/solson/miri/issues/612) bugs [in Miri](https://github.com/solson/miri/issues/614) which I then fixed.
  66
  67 And last but not least, Miri can now [pass arguments to the interpreted program](https://github.com/solson/miri/pull/624), which is particularly useful when running test suites to run only the test one is currently debugging.
  68
  69 I think that's it!
  70 Lots of exciting progress as well as lots of grounds for further discussion.
  71 This won't get boring any time soon. :D