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.)
8 Likes
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.
5 Likes
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! 
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.
6 Likes
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.
8 Likes
Meeting summary: 2018.08.07 (dropbox paper link)
Hi everyone! Sorry for not posting a summary in a while. In between travels and other things, we kind of failed to keep up. But I’m back now!
Current status
First off, a big thank you to all the active and wonderful members of WG-compiler-nll thus far. We managed to meet all of our Edition Preview 2 goals and then some by the deadline, and I’m quite excited about that. I’d like to give a particular shout out to @davidtwco, @lqd, @matthewjasper, and @spastorino, all of whom have been tirelessly fixing bug after bug (just scroll down through previous weeks in the dropbox paper to see what I mean!)
I think the main focus for the Release Candidate is going to be correctness, with performance and diagnostics as a close second. We’ve already done one crater run, and we fixed almost everything we found (there are three issues left, see below). One of my big priorities is to do another crater run as well as to start having the compiler bootstrap using NLL.
In general, our performance results are looking pretty good, though more work is needed. We compared the performance for most crates and at this point we are looking at about 15% overhead or less for cargo check, basically across the board (note that cargo check just does type-checking and borrow-checking, so it accentuates any performance slowdown). As always, you can see the latest results on the NLL dashboard – note though that the versions of crates tested there tend to be older, and in particular they were chosen because they gave us trouble in the past (not to say we won’t optimize them!).
How can I help?
If you’d like to help out, the list of [NLL milestone issues is here](is:open is:issue milestone:“Rust 2018 RC” label:WG-compiler-nll). Here are a few issues I want to call attention to as being particularly high priority:
- Final regressions from previous perf run:
-
#53123 — regression with where &'a T: Sized in scope
-
#53121 — regression in outlives relationships in shred (hard-ish)
- Correctness:
-
#53171 — do another crater run and catalog results
-
#53172 — add #![feature(nll)] to the compiler crates, stdlib, etc
-
#44844 — help us migrate compile-fail tests to ui tests! UI tests are better compared for consistency etc.
- Performance:
-
#53159 — faster way to identify borrows in scope
-
#52460 — performance experiment: invert liveness computation
-
#53176 — optimize redundant borrows
9 Likes
What is the correct invocation these days to try NLL on a dependency graph with many crates? Does RUSTFLAGS="-Znll" cargo +nightly build enable what will ~soon be the default?
You can use RUSTFLAGS="-Zborrowck=mir -Ztwo-phase-borrows" cargo build
There is also RUSTFLAGS="-Zborrowck=migrate -Ztwo-phase-borrows" cargo build -- this version will give warnings for anything that NLL considers an error where the old checker did not consider it an error (because of bugs)
Thanks!
I was able to compile Servo with these flags after fixing three issues: updating the getopts and url crates to new versions, and changing one instance of vec[i] += something(vec[i]) to let x = vec[i]; vec[i] += something(x); in Servo itself: https://github.com/servo/servo/pull/21356
As far as I remember these have all been reported previously and deemed to be cases of unsound code that is incorrectly accepted by AST-based borrowck.
10 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.