As usual we have the NLL triage paper as a place for everyone to jot down their status
I would like to call everyone's attention to my last bullet item: want everyone here to weigh in on buckets in https://github.com/rust-lang/rust/issues/52663
namely, I tried to be pretty exhaustive in enumerating all the differences,
even differences that there is a pretty good argument that the difference is fine or at least acceptable for now
but anyway, I figure I could let other people weigh in on which differences seem to actually matter
(and of course, if anyone wants to have a go at fixing any of them, that's also an option.
So @nikomatsakis is on PTO this week
the big news (at least in my opinion) is that PR #52681 landed
and it included integration into the
2008 2018 edition. So, we're committed at this point. :)
it got integrated this late?
I like the 2008 edition.
it got integrated this late?
well, it was in the compiler
but it wasn't toggled on by the
2008 2018 flag
Felix still didn't realize :P
and it was mainly waiting on the migration mode (that same PR) that downgrades errors to warnings if AST-borrowck accepts the code
so, yes, you are right to be somewhat shocked that we're turning it on this late in the game
Felix, we are in 2018 :P
10 years late is a bit too much though
I already mentioned the diagnostic survey
but my real take away from that effort was: I think we are actually in a pretty good spot
We do need to triage that list of buckets, figure out which things to prioritize for the Release Candidate
but overall I was pretty happy with our diagnostics
How are we doing on performance?
(I honestly have no idea.)
@lqd probably has the best idea, I'm not too sure myself.
Well, const eval got slower, so we now look better. :rolling_on_the_floor_laughing:
Yeah I don't see any massive difference when I look at https://perf.rust-lang.org/nll-dashboard.html ; we're still really bad on html5ever and tuple-stress
We seem to be okay I think, up to date crate versions run faster than the versions on perf.rlo
and also people running the full compiler won't notice the impact as much as people running
cargo check, right?
And we have some wip work for html5ever, but will likely hit he dataflow/moveck slowness hitting tuple-stress next
Hey @Matthew Jasper since you have been looking at stuff with closure captures
felix you might have ideas on the tuple-stress profile in the "perf.rlo benchmarks" topic
We should make sure there's a way to keep track of who is doing any of the diagnostic buckets so that we don't duplicate any effort.
@Matthew Jasper could you take a look at the list in NLL lacks special case handling of closures and make sure all of those have appropriate issues?
(oh niko started looking at the crater results and there will be new bugs to be filed)
@David Wood yeah; assigning people in issues would be one step
@David Wood if something doesn't get an issue because its "too minor", then they could at least add themselves to the table?
or I guess you all don't have edit privleges for the table
Yeah, a column on the table is probably sufficient. I think anyone in the WG-compiler-nll group can edit the table.
@lqd okay. I'm not 100% sure I'll have time to look at it too closely because there are some non NLL compiler issues that I think I need to attack this week
@lqd but I'll try to remember to at least look at it
Cool, could be worthwhile eventually (ie the liveness + static fast path for html5ever won't be enough most likely)
I'm trying to figure out if there's anything else besides diagnostics and performance to talk about
ICE's of course
I think that we've got most of them now
okay. I just noticed #52792
(but I think other people on the compiler team who know more about the generator support code are going to be dealing with that.)
but the main thing is
that probably ICE's need to take highest priority now
now that we're turned on in the 2008 edition
all the ones we hit in the crater runs are fixed now I think
I think #52792 is independent of NLL
Oh there was one other thing I wanted to get people's temperature on
Back in May, PR #50593 turned off the location-dependent outlives relation
and that, as expected, broke #51526
the thing I've been wondering is ..
should we put back in the location-dependent outlives relation, under a debug-flag
(or other feature-gated opt-in)
oh right the thing Simon talked about yesterday
as a way to still test the more feature-full NLL
What ever happened with the type annotations issue?
without going all the way to Polonius
@David Wood I think that issue is still open
... I was treating it as a diagnostic issue
but now that you mention it, its not purely diagnostic, is it
this is issue #47184
so yeah, we do want to resolve that in time for the Release Candidate
and ... i don't think we have any solid plan for resolving it. Not currently.
I did have some code hacked up to try to support
let (a, b): (T, U); checking for #47184
but I don't remember where I put it. And it didn't quite work. And I didn't like it.
I should at least go see if I can find that branch again.
okay well our time is up
Thanks @everyone for attending
(Location dependent outlives could be nice under another flag :) \o