I'll be doing some pre-triage for NLL in advance of tonight's weekly meeting
as usual i'm following the structure presented in our NLL triage paper
first, uncategorized issues
only one item: "NLL: turn off migration mode" #58781
(I added this as a subitem of "NLL: complete transition from migrate to full NLL" #57895)
needs to be tagged as a tracking issue I think. I'll do that now.
that takes it out of the "uncategorized issues" search. great.
next, unprioritized issues; these need a prioritization (i.e. a P-label, like
lets see. I'll try to attack these using the NLL-* labels as a guide for initial priorization.
There's only one NLL-sound issue here: "fix "bivariant wf" bug in the NLL subtyping code" #54105
I'm going to tag this as P-medium; until we actually see an instance of this bug (either by constructing one or in the wild), I don't want to keep revisiting it week after week.
(However, it is possible that the @WG-compiler-traits group would disagree with that prioritization of #54105 ?)
next, lets prioritize the
first: "DerefMut borrow method call is too long with Deref arguments" #57376
this is an issue with two-phased borrows
I'm going to tag this as P-medium, same as "Tracking issue for generalized two-phase borrows" #49434
next: "ICE when returning generic abitrary self type in defining function for existential associated type" #57700
based on skimming the comments, this issue is believed to be the same as issue #53598
I suspect the dependence on
#![feature(existential _type)] should not be used as a justification for assigning a low priority.
I've been having some amount of luck lately by changing
span_bug! calls into
tcx.sess.delay_span_bug to get rid of ICE's in cases where the compiler would issue a proper error if it hadn't encountered the ICE (which, I think, this issue falls into)
I'll tag it as P-high and assign it to myself for initial investigation.
okay that's all the NLL-complete issues
there are six unprioritized
NLL-diagnostics issues, and two
I don't think I'm in a position right now to fairly evaluate priority of diagnostic issues, so I'll table those (again)
but lets see if we can tie off the NLL-performant ones
first: " [nll] hash borrows in scope for better performance" #53159
During triage two weeks ago I stated I didn't know what priority to assign here, and niko said they were inclined to just close the issue.
(its possible the idea is actionable/relevant, but I'm not sure that warrants keeping an issue open.)
let me see if there's a comment in the code about it.
the issue number does not occur in the source code. Its probably not worth even adding a comment about it.
I'll just close.
second (and last) NLL performant issue: "NLL compile-time performance regression" #58178
The relevant benchmark has been added, or at least rustc-perf#343 has landed.
ah but the perf web site says that its data is
last updated on March 4th?
which may well have predated the PR landing
anyway it sounds like we likely still have a problem here.
I'm going to tag this as P-high
before I look over the P-high issues, I'll just note: "user type annotations are captured post normalization" #54940 is still tagged as I-nominated.
So my Q for @nikomatsakis : can you or someone else provide a short statement (not necessarily today) as to the plan for lazy normalization?
oh. There's only one unassigned P-high issue, namely, the one I just tagged as P-high: "NLL compile-time performance regression" #58178
I'll nominate that for discussion at meeting tonight, to see if anyone wants to pick up where @Matthew Jasper has left off in terms of investigating the performance.
and that's all of the pre-triage. See you all at the meeting tonight!
@pnkfelix I'd like to take care of #58178 regression, but it's really late(1:00am) now in my timezone, so cannot attend later, would you mind pinging me at the beginning of the discussion of this issue in the upcoming meeting? (for me to quick-check what was going on tomorrow morning).
But if you find another candidate of this in the meeting, that's fine.
it would be cool if we could also talk tonight about the WG's permissions on the repo :)
@csmoe I'll just go ahead and assign #58178 to you