Stream: t-compiler

Topic: pre-meeting triage 2019-05-02 #54818


pnkfelix (May 02 2019 at 10:37, on Zulip):

I'll be doing pre-meeting triage in this topic today

pnkfelix (May 02 2019 at 10:42, on Zulip):

first up: there are 19 unprioritized nominated T-compiler issues

pnkfelix (May 02 2019 at 10:43, on Zulip):

i'll go through them bottom-up

pnkfelix (May 02 2019 at 10:43, on Zulip):

first is "Decouple nightly RLS from Clippy" #59761

pnkfelix (May 02 2019 at 10:44, on Zulip):

the nomination tag here was added back before this had a T-compiler tag, so I don't think this nomination is targeted at us

pnkfelix (May 02 2019 at 10:46, on Zulip):

reading this more carefully now, I am thinking that maybe it was a mistake that I tagged this with T-compiler two weeks ago.

pnkfelix (May 02 2019 at 10:47, on Zulip):

(apart from the detail that RLS things maybe should be tagged with T-compiler in general...)

pnkfelix (May 02 2019 at 10:47, on Zulip):

in any case i don't think it seems like a P-high issue, at least not for us

pnkfelix (May 02 2019 at 10:47, on Zulip):

I'll leave a comment saying I'd like a priority assigned and I'm wondering if we could tag this as P-medium.

pnkfelix (May 02 2019 at 10:49, on Zulip):

next: "Exponential compile-time and type_length_limit blowup when nesting closure wrappers" #54540

pnkfelix (May 02 2019 at 10:52, on Zulip):

hmm

pnkfelix (May 02 2019 at 10:53, on Zulip):

exponential time can be a pretty big frustration for users

pnkfelix (May 02 2019 at 10:53, on Zulip):

but if I understand this properly, you need to explicitly opt into the time blow up via the #![type_length_limit=...] attribute

pnkfelix (May 02 2019 at 10:55, on Zulip):

anyway @eddyb has nominated this for discussion. I personally am currently inclined to assign it P-medium priority, under the assumption that the time blow-up is not encountered without the user "asking for it" via the type_length_limit attribute.

pnkfelix (May 02 2019 at 11:01, on Zulip):

next: "reached the type-length limit while instantiating" #58952

pnkfelix (May 02 2019 at 11:02, on Zulip):

hmm I do wonder whether this is related to #54540

pnkfelix (May 02 2019 at 11:02, on Zulip):

I'll at least cc the latter

pnkfelix (May 02 2019 at 11:03, on Zulip):

but in this case we're looking at a stable-to-beta regression

pnkfelix (May 02 2019 at 11:03, on Zulip):

so I'll at least tag as P-high

pnkfelix (May 02 2019 at 11:07, on Zulip):

next: "mir-opt tests extremely slow." #58485

pnkfelix (May 02 2019 at 11:09, on Zulip):

it seems like @eddyb and @oli have been discussing this, e.g. in topic replacing mir-opt with UI

pnkfelix (May 02 2019 at 11:13, on Zulip):

next: "Rust panics at typecheck ICE stable 1.34.1 and nightly 1.35.0" #60283

pnkfelix (May 02 2019 at 11:13, on Zulip):

ICE, p-high

pnkfelix (May 02 2019 at 11:15, on Zulip):

next: "rls no longer builds after rust-lang/rust#60296" #60299

pnkfelix (May 02 2019 at 11:15, on Zulip):

sigh, #60296 is a rollup build

pnkfelix (May 02 2019 at 11:16, on Zulip):

sounds like RLS's dependence on Clippy is the hypothesized issue here, see also #59761

pnkfelix (May 02 2019 at 11:17, on Zulip):

as for prioritization... i don't know what priority to assign

pnkfelix (May 02 2019 at 11:19, on Zulip):

leaving unprioritized and nominated.

pnkfelix (May 02 2019 at 11:20, on Zulip):

next: "Stable rustc always panics on arm/musl" #60297

pnkfelix (May 02 2019 at 11:21, on Zulip):

what the heck...

pnkfelix (May 02 2019 at 11:23, on Zulip):

we may want to reach out to the infra team about this one, seems like something is deeply wrong somewhere here

pnkfelix (May 02 2019 at 11:25, on Zulip):

next: "llvm lint: "Undefined behavior: Call argument type mismatches callee parameter type" with mixing debug and release" #48310

pnkfelix (May 02 2019 at 11:45, on Zulip):

hmm.

pnkfelix (May 02 2019 at 11:46, on Zulip):

(also, we should probably decide what priority label to assign to #55976)

pnkfelix (May 02 2019 at 11:47, on Zulip):

but anyway

pnkfelix (May 02 2019 at 11:47, on Zulip):

the llvm lint issue sounds bad, but there is one theory put forward that it may be a bug in the LLVM lint itself? Not sure.

pnkfelix (May 02 2019 at 11:48, on Zulip):

the fact that we've gotten away with this for over a year makes me inclined to assign this P-medium, but that logic does not always hold up, especially when one is talking about subtle soundness issues in codegen and FFI interop ...

centril (May 02 2019 at 11:49, on Zulip):

@pnkfelix perhaps make filing the LLVM bug the P-high issue?

centril (May 02 2019 at 11:49, on Zulip):

and then decide based on what we hear from LLVM

pnkfelix (May 02 2019 at 12:23, on Zulip):

okay, did that

pnkfelix (May 02 2019 at 12:23, on Zulip):

next: "Compiler panic at Box<Any>" #60363

pnkfelix (May 02 2019 at 12:23, on Zulip):

ICE, P-high

pnkfelix (May 02 2019 at 12:26, on Zulip):

next: " Rust 1.34 generates significantly less debug information for libstd functions vs. Rust 1.33" #60020

pnkfelix (May 02 2019 at 12:28, on Zulip):

bisection has confirmed PR #57675 is to blame.

pnkfelix (May 02 2019 at 12:32, on Zulip):

I'll make this P-high for now, but I'm not 100% sure that is correct prioritization

pnkfelix (May 02 2019 at 12:36, on Zulip):

leaving nominated

pnkfelix (May 02 2019 at 12:37, on Zulip):

next: "Existential type ICE without feature specified" #60371

pnkfelix (May 02 2019 at 12:38, on Zulip):

ICE, P-high, removing nomination

pnkfelix (May 02 2019 at 12:39, on Zulip):

next: "ICE when running kcov with proptest as dev-dependency" #60372

pnkfelix (May 02 2019 at 12:45, on Zulip):

inclined to treat as duplicate of #58375. Wrote comment saying so.

pnkfelix (May 02 2019 at 12:45, on Zulip):

next: "ICE when building with --emit=mir" #60390

pnkfelix (May 02 2019 at 12:51, on Zulip):

wrote comment. Summary: its fixed in nightly, did P-medium.

pnkfelix (May 02 2019 at 12:52, on Zulip):

next: "x.py in incremental mode still rebuilds stage0-rustc if stage0-std changed." #54712

pnkfelix (May 02 2019 at 12:53, on Zulip):

bootstrap inefficiency would be nice to resolve, but is not P-high.

pnkfelix (May 02 2019 at 12:54, on Zulip):

(leaving nominated)

pnkfelix (May 02 2019 at 12:55, on Zulip):

next: "Implement converting an AST to a token tree" #43081

pnkfelix (May 02 2019 at 12:57, on Zulip):

.... this is a very old, also very big, topic...

pnkfelix (May 02 2019 at 12:57, on Zulip):

i'm going to leave unprioritized for now

pnkfelix (May 02 2019 at 12:57, on Zulip):

(and nominated)

pnkfelix (May 02 2019 at 12:58, on Zulip):

next: "ICE with unsized associated type" #60431

pnkfelix (May 02 2019 at 13:01, on Zulip):

ICE, P-high, removing nomination

pnkfelix (May 02 2019 at 13:02, on Zulip):

next: "Regression: Typemap type mismatch in 1.34.0+" #60375

pnkfelix (May 02 2019 at 13:03, on Zulip):

I do not yet see how this is a T-compiler issue

pnkfelix (May 02 2019 at 13:05, on Zulip):

the phrase "stores data ... through a typemap" makes me wonder if this is somehow depending on the print representation of types? But really, I'm just guessing.

pnkfelix (May 02 2019 at 13:07, on Zulip):

leaving unprioritized and nominated

centril (May 02 2019 at 13:07, on Zulip):

@pnkfelix I'm also confused by that issue; perhaps it's a TypeId issue?

centril (May 02 2019 at 13:08, on Zulip):

(I'm thinking of <https://github.com/reem/rust-typemap/blob/master/src/lib.rs#L29>)

pnkfelix (May 02 2019 at 13:08, on Zulip):

oh maybe

centril (May 02 2019 at 13:09, on Zulip):

(Perhaps just ask for a smaller repro)

pnkfelix (May 02 2019 at 13:09, on Zulip):

and meanwhile the crate this is filed against says this first in its readme: "Native Windows GUI is no longer maintained. The dev branch is where the lastest features are if you are in dire need of a Windows only GUI library"

pnkfelix (May 02 2019 at 13:10, on Zulip):

(no commits since Oct 2018)

pnkfelix (May 02 2019 at 13:11, on Zulip):

next: "ICE with existential_type feature" #60407

pnkfelix (May 02 2019 at 13:14, on Zulip):

ICE, P-high, removing nomination

pnkfelix (May 02 2019 at 13:14, on Zulip):

(but I'd like to assign both #60407 and #60371 to the same person...)

pnkfelix (May 02 2019 at 13:15, on Zulip):

next: "Cargo build ICE when run with closed STDIN" #60447

pnkfelix (May 02 2019 at 13:16, on Zulip):

this seems like a pretty niche scenario

pnkfelix (May 02 2019 at 13:17, on Zulip):

presumably anyone who runs into it could work around it by making a nonclosed input stream to hook in as the stdin for the spawned process

pnkfelix (May 02 2019 at 13:18, on Zulip):

I'm going to mark it as P-medium, but also leave it nominated for now to try to get visibility on it in the short term

pnkfelix (May 02 2019 at 13:20, on Zulip):

That's the unprioritized nominated T-compiler issues.

pnkfelix (May 02 2019 at 13:21, on Zulip):

there was one nominated issue for T-dev-tools that I just removed the nominated tag from: "rustc 1.34.0 panics when running "cargo clippy" and checking "combine" crate" #59909

pnkfelix (May 02 2019 at 13:22, on Zulip):

there are zero stable-to-beta regressions without a P-label (link)

pnkfelix (May 02 2019 at 13:22, on Zulip):

there are zero stable-to-nightly regressions without a P-label (link)

pnkfelix (May 02 2019 at 13:22, on Zulip):

okay, so

pnkfelix (May 02 2019 at 13:23, on Zulip):

next up is a run through of the P-high issues

pnkfelix (May 02 2019 at 13:23, on Zulip):

there are 32 open p-high t-compiler issues

pnkfelix (May 02 2019 at 13:24, on Zulip):

first: " two-phase-borrows need a specification" #46901

pnkfelix (May 02 2019 at 13:24, on Zulip):

I'm going to remove the P-high tag from this

pnkfelix (May 02 2019 at 13:24, on Zulip):

I do think it needs to be done

pnkfelix (May 02 2019 at 13:24, on Zulip):

but it just isn't sensible to keep coming back to it each week

pnkfelix (May 02 2019 at 13:25, on Zulip):

and it just doesn't have the level of urgency that P-high should convey

pnkfelix (May 02 2019 at 13:25, on Zulip):

next: "user type annotations are captured post normalization" #54940

pnkfelix (May 02 2019 at 13:26, on Zulip):

here too, I am not sure this should remain P-high. @nikomatsakis , any thought there ?

pnkfelix (May 02 2019 at 13:26, on Zulip):

it is a soundness issue

pnkfelix (May 02 2019 at 13:26, on Zulip):

but supposedly it is blocked on lazy normalization

pnkfelix (May 02 2019 at 13:26, on Zulip):

do we even have a tracking issue on lazy normalization?

pnkfelix (May 02 2019 at 13:27, on Zulip):

I'll ask in #wg-traits

varkor (May 02 2019 at 13:27, on Zulip):

I don't think there's a tracking issue, no

pnkfelix (May 02 2019 at 13:29, on Zulip):

okay I'll create one

pnkfelix (May 02 2019 at 13:32, on Zulip):

created "lazy normalization" #60471

pnkfelix (May 02 2019 at 13:32, on Zulip):

next: "Compiler panic when using a slice pattern" #59016

centril (May 02 2019 at 13:33, on Zulip):

@pnkfelix added some labels to the issue and whatnot

pnkfelix (May 02 2019 at 13:34, on Zulip):

oh look, issue #59016 has proposed fix in PR #59369 which is "related to lazy normalization"

pnkfelix (May 02 2019 at 13:34, on Zulip):

how apropos

pnkfelix (May 02 2019 at 13:36, on Zulip):

anyway progress on PR #59369 seems slow but steady; @nikomatsakis assigned themselves to it two days ago

pnkfelix (May 02 2019 at 13:36, on Zulip):

next: "Future-incompatible warnings should always print a warning, even if lints are allowed" #34596

centril (May 02 2019 at 13:37, on Zulip):

Already has a PR

pnkfelix (May 02 2019 at 13:37, on Zulip):

@centril proposed PR #59658 to resolve this. @nikomatsakis has pushed back.

pnkfelix (May 02 2019 at 13:38, on Zulip):

in short, its being addressed but it may take a while

pnkfelix (May 02 2019 at 13:38, on Zulip):

I'm inclined to downgrade to P-medium prioirty

pnkfelix (May 02 2019 at 13:38, on Zulip):

I know that we need to resolve the problem outlined in #34596

centril (May 02 2019 at 13:38, on Zulip):

I think it's a high prio problem, but it's being dealt with in the PR

centril (May 02 2019 at 13:38, on Zulip):

no need to retriage

pnkfelix (May 02 2019 at 13:38, on Zulip):

but again, I don't think it should be treated with sense of urgencyfor which I would like P-high to be reserved

pnkfelix (May 02 2019 at 13:39, on Zulip):

I think we have a problem, in that I want P-high to mean truly urgent matters that should be on the forefront of at least one person's mind

centril (May 02 2019 at 13:39, on Zulip):

I think it is an urgent problem but I don't mind P-medium

centril (May 02 2019 at 13:39, on Zulip):

so we don't have to discuss it every week

pnkfelix (May 02 2019 at 13:40, on Zulip):

(maybe that doesn't exactly match P-high's meaning as used in the past, but I don't see much utility in prioritization if we continue to allow the set of P-high issues to grow beyond our control...)

centril (May 02 2019 at 13:40, on Zulip):

@pnkfelix maybe P-superhigh is necessary? ;)

pnkfelix (May 02 2019 at 13:41, on Zulip):

i'll relabel it to P-medium and try to explain

pnkfelix (May 02 2019 at 13:41, on Zulip):

in any case

pnkfelix (May 02 2019 at 13:41, on Zulip):

I gave issue #34596 a P-high label when I wanted it to get attention

pnkfelix (May 02 2019 at 13:41, on Zulip):

and now, it has gotten attention. :smiley:

pnkfelix (May 02 2019 at 13:44, on Zulip):

next: Nightly rustc crashes with "unexpected region in query response" #57464

pnkfelix (May 02 2019 at 13:44, on Zulip):

I haven't made progress here, but it looks like @Matthew Jasper may have a resolution in PR #60449

pnkfelix (May 02 2019 at 13:45, on Zulip):

ah PR #60449 sounds like a nice refinement of PR #60332

pnkfelix (May 02 2019 at 13:46, on Zulip):

(at least based on the description; now that I look at the code, "refinement" may be the wrong word)

nikomatsakis (May 02 2019 at 13:51, on Zulip):

I'll make this P-high for now, but I'm not 100% sure that is correct prioritization

the main reason I think it is correct is that this is affecting Firefox in a major way

pnkfelix (May 02 2019 at 13:51, on Zulip):

i thought a workaround was proposed

pnkfelix (May 02 2019 at 13:51, on Zulip):

but I may have misinterpreted that

pnkfelix (May 02 2019 at 13:53, on Zulip):

okay I took a moment to review PR #60449

pnkfelix (May 02 2019 at 13:53, on Zulip):

so anyway, hopefully that will land and subsequently resolve issue #57464

nikomatsakis (May 02 2019 at 13:53, on Zulip):

ICE, P-high, removing nomination

I'm not sure this should be P-high, given that existential type feature in this position is not stable nor (imo) particularly close to stability -- we should probably have a better way to track that, though. And it should be added I guess to the tracking issue.

pnkfelix (May 02 2019 at 13:54, on Zulip):

yes I thought that myself

pnkfelix (May 02 2019 at 13:54, on Zulip):

that my automatic marking of P-high for ICE's does not necessarily apply

centril (May 02 2019 at 13:54, on Zulip):

@nikomatsakis well; I think we should work to make it close to stability

nikomatsakis (May 02 2019 at 13:54, on Zulip):

I disagree :)

pnkfelix (May 02 2019 at 13:54, on Zulip):

if the ICE is exposed solely by feature-gated code

nikomatsakis (May 02 2019 at 13:54, on Zulip):

sorry, I don't disagree

nikomatsakis (May 02 2019 at 13:55, on Zulip):

but I don't feel that means it has to be P-high

centril (May 02 2019 at 13:55, on Zulip):

Seems there's a larger discussion about what P-high is for? :P

pnkfelix (May 02 2019 at 13:55, on Zulip):

see earlier note about "urgency"

pnkfelix (May 02 2019 at 13:55, on Zulip):

yes I think so

nikomatsakis (May 02 2019 at 13:55, on Zulip):

I agree we should have a discussion about our tagging model

nikomatsakis (May 02 2019 at 13:55, on Zulip):

I think it's become too crude

nikomatsakis (May 02 2019 at 13:56, on Zulip):

but p-high means "we need to check in on this every meeting" and I don't feel this is true for that issue; at least not for the team at large

pnkfelix (May 02 2019 at 13:56, on Zulip):

I don't know if the word "crude" is quite right

pnkfelix (May 02 2019 at 13:56, on Zulip):

at least, I usually interpret that as meaning "we need finer grain distinction"

centril (May 02 2019 at 13:56, on Zulip):

that's what I assumed we want?

centril (May 02 2019 at 13:57, on Zulip):

@nikomatsakis I agree we don't need to check in on existential type every meeting

centril (May 02 2019 at 13:57, on Zulip):

but I do think it should be a implementation priority

pnkfelix (May 02 2019 at 13:57, on Zulip):

An obvious "fix" is to have me stop checking in on P-high every meeting

nikomatsakis (May 02 2019 at 13:57, on Zulip):

but we should definitely not lose track of the issue

pnkfelix (May 02 2019 at 13:57, on Zulip):

and add a tag, e.g. P-urgent

nikomatsakis (May 02 2019 at 13:57, on Zulip):

but I do think it should be a implementation priority

I don't know that I argee abut this either, but we can discuss :)

pnkfelix (May 02 2019 at 13:57, on Zulip):

for things that do warrant weekly (or even daily?) checkins

nikomatsakis (May 02 2019 at 13:58, on Zulip):

well

nikomatsakis (May 02 2019 at 13:58, on Zulip):

I'm more inclined to keep p-high's meaning stable

pnkfelix (May 02 2019 at 13:58, on Zulip):

note that I'm not necessarily saying I want to add P-urgent

nikomatsakis (May 02 2019 at 13:58, on Zulip):

and look at the other sorts of issues and think about how they should be tracked

centril (May 02 2019 at 13:58, on Zulip):

we do already have regression-from-stable-to-X labels tho

pnkfelix (May 02 2019 at 13:59, on Zulip):

I'm more inclined to keep p-high's meaning stable

... bugs witnessable by stable code?

nikomatsakis (May 02 2019 at 13:59, on Zulip):

but I do think it should be a implementation priority

mostly @centril I'm feeling overwhelmed by a feeling of "aaah there are a lot of regressions" :) I would like to see program on impl trait, to be clear, and I do think it's a good candidate for "one of those things we can cleanup and try to stabilize"

pnkfelix (May 02 2019 at 13:59, on Zulip):

(or rather, bugs that will be witnessable on the stable/beta channels if not addressed?)

nikomatsakis (May 02 2019 at 13:59, on Zulip):

... bugs witnessable by stable code?

"things that need to revisited every meeting"

nikomatsakis (May 02 2019 at 14:00, on Zulip):

but of corse we could drill in on what that means

pnkfelix (May 02 2019 at 14:00, on Zulip):

maybe we should have a way of saying that directly

pnkfelix (May 02 2019 at 14:00, on Zulip):

revisit-weekly

pnkfelix (May 02 2019 at 14:00, on Zulip):

revisit-daily

pnkfelix (May 02 2019 at 14:00, on Zulip):

as literal labels

nikomatsakis (May 02 2019 at 14:00, on Zulip):

yeah, perhaps that's better

pnkfelix (May 02 2019 at 14:00, on Zulip):

revisit-monthly even

centril (May 02 2019 at 14:00, on Zulip):

@nikomatsakis to be clear I agree with "aaah..." and I do want that program also :slight_smile:

pnkfelix (May 02 2019 at 14:01, on Zulip):

Okay I'm going to focus on the T-compiler/meeting topic now

centril (May 02 2019 at 14:01, on Zulip):

yes, sorry :P

nikomatsakis (May 02 2019 at 14:01, on Zulip):

the original idea of p-high, p-medium, and p-low was

nikomatsakis (May 02 2019 at 14:01, on Zulip):

anyway, yeah, :)

nikomatsakis (May 02 2019 at 14:01, on Zulip):

I never got through all the pre-triage!

nikomatsakis (May 02 2019 at 14:01, on Zulip):

the original idea of p-high, p-medium, and p-low was

to be clear, Idon't think this was a perfect categorization, and we've never really stuck to it as well as we should :)

centril (May 02 2019 at 14:02, on Zulip):

I would have liked I-unsound to be "STOP EVERYTHING ELSE" but the world ain't perfect :P

Last update: Nov 22 2019 at 05:45UTC