This is the topic where I will be doing pre-triage prior to the weekly T-compiler meeting which will commence in about three hours, in another topic on this stream
(ah sadly Zulip's url system does not provide redirections in response to edited topics. I wonder if that has been proposed as a feature request.)
so, first up, p-high T-compiler issues
oh. You know what, I'm going to start being smart
(since this is pre-triage, I will take advantage of freedom to reorder process to be smarter)
namely, I'm going to start reviewing the nominated before the P-high ones, since the process of going through the former leads to them being tagged as the latter
(had to pause for a bit to update the description on #54818 to reflect this new process)
so there are six T-compiler I-nominated unprioritized issues
rls no longer builds after rust-lang/rust#58321" #58765; sounds P-high to me. Tagging as such.
next: "Wrong optimization of Some(Rc<RefCell<...>>) in thread_local! (STATUS_ILLEGAL_INSTRUCTION)" #58684
also sounds P-high to me. Also would be nice to 1. narrow the test case and/or 2. bisect which rustc injected, assuming it was relatively recent injection (though it does reproduce on stable 1.32)
next: "Type inference fails even though all types are known" #58517
holy cow bisection showed this was injected way way back between 1.12 and 1.13 :mantelpiece_clock:
I'm going to triage #58517 as P-medium for now (since this is not e.g. a soundness issue and one can work around it by e.g. introducing a ) but leave the I-nominated label so that people get the chance to object at the meeting.
It definitely seems goofy to me, though
next: "Implement "pipelined" rustc compilation (compiler side)" #58465
one can see discussion of this on the corresponding cargo issue
@pnkfelix sorry for cutting in. as for the
rlshttps://github.com/rust-lang/rust/issues/58765, I PR'ed just now https://github.com/rust-lang/rls/pull/1384
no problem about cutting in; I wouldn't log this here if I didn't want that.
I don't know how high a priority we want to put on #58465. So I'm not going to assign any priority; instead I'm going to leave it nominated in the hopes that we discuss it today or soon thereafter.
(and then the team can collectively answer the question of what P-label to apply)
next: "Rustc should use a variable other than RUST_LOG for env_logger." #57985
I personally don't think this is a high priority item, but I do think its worth discussing, and maybe would be a good mentorship bug?
I'm going to mark #57985 as P-medium, but keep the nomination label and tag as E-needs-mentor.
next: " Function pointer docs may need updating" #46989
@Aaron Turon has started looking into this
the fallout that came out of universes (where said fallout has seen been undone by the re-introduction of a leak-check) implies to me that this is P-high.
okay that's all the nominated issues that were specifically tagged with T-compiler
next, I'll quietly do a pre-pass over all the unprioritized nominated issues (for any team). But I'll only announce the ones, if any, strike me as needing a T-compiler label but do not yet have one.
I don't see any that strike me as needing T-compiler's attention.
So, now that that is done, lets go through the actual P-high issue list
I already mentioned "NLL migrate mode erroneously downgrades error with nested closures, yielding use-after-free" #58776 at the outset, no need to revisit here.
rls no longer builds after rust-lang/rust#58321" #58765. as @csmoe mentioned, this now has a PR to fix it. I'm going to remove the nomination label.
next: "Wrong optimization of Some(Rc<RefCell<...>>) in thread_local! (STATUS_ILLEGAL_INSTRUCTION)" #58684
assigning to self for initial investigation.
and removing nomination label
next: "TyLayout::field_type ICE on 1.34.0-nightly 865cb7010 2019-02-10" #58610
lets update that title to be a little more specific. (done)
this needs a standalone test
I'll wait until the meeting to see if we can get someone to volunteer. (and I'll post a request for such a volunteer now.)
@pnkfelix I wanna take care of the test. but what is standalone test?
By standalone I mean a snippet of code we can feed into rustc that exposes the bug
ideally its something small that you can include the source code in the description, and a link to the playpen with the same code.
anyway I can assign #58610 to you then, @csmoe , for facotring out the test?
It doesn't seem to be worth a point release to me.
since, if I understand correctly, all instances of this bug are emitting a warning
and its hopefully a scary warning :spooky:
But we will discuss all the beta-nominations at the meeting itself
One of my hopes/plans is to not attempt to handle beta-nominations during pre-triage, at least not in terms of trying to initiate any sort of action on them during the pre-triage process.
though I guess mentioning them in this channel would at least alert people to their existence? I don't know.
great, thanks @csmoe
Beta nominated should always mean real beta, stable nominated should be used for point releases.
right, I assume @lqd was asking because there may have been a kind of race condition, at least in the different parties' mental models of where the trains were/are
(where if something is beta-nominated and then the beta-to-stable promotion happens, we need to ask whether it should then be stable-nominated too)
but maybe that was too much mind-reading on my part
next P-high issue: "rustc 1.32.0 produces faulty wasm code" #58548
this has been reported as a bug to LLVM upstream, which has merged a fix
and @Nikita Popov assigned themselves to handle it.
so this looks under control
next P-high issue: "fn generated by macro exported from crate loses global #![allow(non_snake_case)]" #58502
reading over this bug, I don't even know what the "right" behavior should be here.
Do we have a WG-lint or some other team dedicated to what lints are "suppposed" to do?
I guess I'll leave this nominated for discussion at the meeting itself.
next P-high issue: "Nightly compiler 'inconsistent resolution for an import' for crate" #58499
I'm still assuming that @Vadim Petrochenkov is going to address this in some manner.
but you know what, I'm supposed to be getting my feet wet with resolution anyway, so I'm going to add myself to the assignee list here.
next P-high issue: "Compiler panic with associated constant" #58435
kee-rap I have not yet followed through on this.
but it's been broken on stable (and beta) for some amount of time so its not hugely bad that I missed the trains shifting
anyway I'll try to follow up soon
next P-high issue: ""Cannot create local mono-item" ICE building cortex-m code on nightly" #58323
this is assigned and has a PR so I think its in good hands
next: "ICE with std::mem::size_of with
repr(packed) plus associated type" #58158
I failed to follow-up on this one too.
(I've been having too much fun looking at other ICEs) :snowflake:
next P-high issue: "beta 1.33 seems to break tarpaulin on multithreading" #58104
hmm dialogue on ticket indicates there is likely to be nothing actionable on our side here.
I'm going to tag as I-nominated, with a comment sayingI want to discuss it at upcoming T-compiler meeting but also indicate that I am inclined to close as unactionable.
next P-high issue: "Regression from stable to nightly: nested impl trait is not allowed" #57979
okay, for once we have an issue I self-assigned that I actually did something about
but I did not manage to get PR #58608 landed in time for the nightly-to-beta cut earlier this week. And it doesn't make sense to me to land PR #58608 unless it also ends up back ported to the beta: that is, I don't see the point of having a hard break for 6 weeks followed by a warning period of unspecified length.
(see my comment here which essentially says the same thing.)
so, yeah. We'll discuss this issue more when we talk about beta-nominations.
next P-high issue: "Nightly rustc crashes with "unexpected region in query response"" #57464
This, #57464, is the other bug I have been working on. I have a WIP generalization of a previously posted PR (#58649) that should fix this more completely. Hopefully that PR will be up soon (i'm trying to reduce it a little before I post it to make it easier to backport.)
next P-high issue: "[NLL] Bad higher ranked subtype error" #57374. This is NLL specific. @lqd has been working on it. (The regression has also been temporarily un-regressed via the reintroduction of the leak-check, as noted on the ticket itself.)
anyway this seems under control. But I'm also tempted to downgrade to P-medium...
(I guess the error really is/was attrociously bad before. Okay I'll leave it at P-high under the assumption that it is still that bad.)
next P-high bug: "Borrow checker incorrectly accepts code when calling function with complex lifetime bounds through a fn pointer" #57170
next P-high issue: "[NLL] prohibit "two-phase borrows" with existing borrows?" #56254
progress has been ongoing here with the NLL team, thank in no small part to @Matthew Jasper 's tireless efforts
we have a crater run being applied to @Matthew Jasper 's PR #58739
where it is currently number four in the queue... so yeah, we may not see result for that for a while.
anyway, its in good hands.
next: " user type annotations are captured post normalization" #54940
I marked this P-high yesterday and nominated it for discussion. According to @nikomatsakis progress on #54940 is blocked on lazy-normalization, so I was hoping to get an outline (maybe today?) from the @WG-compiler-traits team about what the game plan and/or schedule is for lazy-normalization.
next P-high: "[nll] change how MIR represents places" #52708
work here is ongoing; see the place 2.0 topic.
next P-high: "Function pointer docs may need updating" #46989. I already discussed this up above when I was going through the nominations. I assume @Aaron Turon is still planning to take point on it.
next P-high: "two-phase-borrows need a specification" #46901; I have no progress to report here.
final P-high: "match arm bindings have weird lifetimes" #46525
I revised the priority from P-medium to P-high on this last week
because I want to double-check the assumption we have posted about it
(and also, it is entirely possible that some of @Matthew Jasper 's changes to codegen have silently handled this.)
but apart from changing priority, I have not yet done anything here.
okay, that's all the P-high issues.
for beta-nominations, I'm going to let us handle those (along with the remaining I-nominations) at the meeting itself.
but I will take a moment now to at least add T-compiler tags when needed
Added T-compiler to "Don't promote function calls to nonpromotable things" #58784
Added T-compiler to "Make migrate mode work at item level granularity" #58788
no stable nominations, thank goodness
the first four of these were opened in the last week and do not have P-label nor I-nominated, so we haven't seen them yet here.
(I probably should have done a prepass over them in the beginning, up above)
first s2b regression: "Rustc panic when building bobbin-sdk" #58767
marking P-high. has PR (#58784). Leaving assigned to @oli
next s2b regression: "panic with "Layout mismatch when copying!"" #58742
triage: P-high. Speculatively assigning to @oli
next s2b regression: "compiler error: lifetimes in associated types leading to a compiler error." #58694
went from hard-error to ICE on code that has a visible feature-gate error.
triage: P-medium, and assigning to self.
next s2b regression: "ICE on rustc 1.34.0-nightly (633d75ac1 2019-02-21):
index out of bounds" #58634
this is also handled by PR #58784. @oli previously assigned themselves.
so I'll just triage it as P-high
that's all the stable-to-beta regressions
All of the stable-to-nightly regressions appear to be triaged. that is, we visited them earlier in this topic, either because the are P-high or were I-nominated or are also stable-to-beta regressions.
There is one issue waiting for our team; it is also marked I-nominated.
with that, I declare pre-triage over. Now I need to go afk to run my aforementioned errand
(and also, it is entirely possible that some of Matthew Jasper 's changes to codegen have silently handled this.)
They didn't, but they make this easier to fix in the future. Once AST borrow check is completely gone this won't be that hard, although it's possible to fix without that.