Help us get Non-lexical Lifetimes (NLL) over the finish line!


I’m forking off from the original Non-lexical lifetimes (NLL) working group tracking thread, since a lot of context has changed. The purpose of this particular thread is to call attention to places where you can come and get involved with the NLL effort.

Weekly meetings

We have our weekly meetings at 15:30 Boston time. They take place on Zulip in the #wg-nll stream. Here we go over the week and highlight areas of focus. Please join us if you can! But if not, I’ll be posting summaries here. You can also look here at the DropBox paper document where we keep our notes.

Level of background required and expectations

We are really trying to push hard on NLL to get it ready to ship ASAP, which means that “latency counts”. We always try to have some level of “mentoring instructions” in the bugs to help you get oriented, but often there isn’t time to make them very detailed – if however you think you have time to dedicate to fixing, please don’t let that stop you! Feel free to drop by Zulip and ask questions or just request more information.

(Pinging on the bug maybe works too, but it’s often hard to keep up with GitHub notifications, so Zulip is better.)


Tuesday June 26

Meeting minutes can be found in the “weekly meeting June 26” Zulip topic.

Here is a highlight of some of the issues where people would be welcome to jump in. In particular there are a number of performance hot spots that have dedicated issues with some mentoring instructions:

  • Performance hot spots (see also the full list of NLL-performant issues)
    • liveness results allocate too much (#51819)
    • dirty list for do_dataflow and liveness (#51813)
    • share buffer for liveness::simulate_block (#51818)
    • places_conflict seems slower than necessary (#51820)
    • remove duplicate inferred edges (#51821)

Other good areas of focus are the NLL-diagnostics issues.

We plan to try and do a crater run and will need help sorting through and categorizing the results.


We just had our next weekly meeting. You can find the notes in this section of the DropBox paper document, but I’ll extract out some of the highlights here:

Summary of the last week

First of all, let me just say: Go Team! We closed out most of the issues I opened last week and made some real progress on NLL performance (here is a graph showing clap-rs-check results over the last week). There are still a few PRs pending, as well.

Thanks to:

You all are great! :heart_eyes:

This week

This week we are turning our focus to ICEs and major diagnostic issues. If you’d like to participate, you can search through the Rust 2018 Preview 2 milestone for the full list of issues, but here is a selection that I called out for this week as “really good to get done”. They all have at least some mentoring instructions:

In addition, I expect to be opening some new issues during the week:

  • First, we have started a crater run, and when it comes back we are going to need help going through the results.
  • Second, we will be opening various issues relating to lifetime error diagnostics, but that is blocked on some foundational work landing in master.


My main interest in NLL is its effect on compile times. Things have improved a lot recently, but the current numbers are still making me nervous.

The compiler has gotten substantially faster recently. It would be very disheartening if those improvements were undone (or worse) by NLL’s landing. I am particularly concerned that the pressure to get NLL into the Rust 2018 Edition could mean that performance regressions might be considered acceptable that otherwise would not.