Stream: t-compiler

Topic: weekly meeting 2019-12-19 #54818


pnkfelix (Dec 19 2019 at 13:16, on Zulip):

Hi @T-compiler/meeting ; the triage meeting will be starting in 1 hours 45 minutes

pnkfelix (Dec 19 2019 at 13:16, on Zulip):

I will be doing pre-triage in a parallel topic

pnkfelix (Dec 19 2019 at 13:17, on Zulip):

today we have WG checkin's scheduled for WG-nll and WG-parallel-rustc

pnkfelix (Dec 19 2019 at 13:18, on Zulip):

WG-NLL is in winding-down status. I doubt we need an update from them.

pnkfelix (Dec 19 2019 at 13:19, on Zulip):

@Zoxc , are you going to be available around the time of the end of the triage meeting to provide update info on WG-parallel-rustc?

pnkfelix (Dec 19 2019 at 13:21, on Zulip):

in any case, I resurrected a status update topic in the #t-compiler/wg-parallel-rustc stream that members of that WG can post updates in.

simulacrum (Dec 19 2019 at 13:26, on Zulip):

(I can help with an update/questions re:parallel-rustc)

Zoxc (Dec 19 2019 at 13:35, on Zulip):

@pnkfelix No

pnkfelix (Dec 19 2019 at 13:35, on Zulip):

okay no problem, thanks for letting us know @Zoxc !

pnkfelix (Dec 19 2019 at 13:35, on Zulip):

@simulacrum thanks that would be awesome

centril (Dec 19 2019 at 14:00, on Zulip):

WG-NLL is in winding-down status. I doubt we need an update from them.

regionck, the 2pb lint, and migrate mode still remains tho, and it feels like the plan for those are in limbo

eddyb (Dec 19 2019 at 14:02, on Zulip):

does Polonius have its own separate WG?

pnkfelix (Dec 19 2019 at 14:02, on Zulip):

does Polonius have its own separate WG?

yes

centril (Dec 19 2019 at 14:02, on Zulip):

#t-compiler/wg-polonius

pnkfelix (Dec 19 2019 at 14:02, on Zulip):

WG-NLL is in winding-down status. I doubt we need an update from them.

regionck, the 2pb lint, and migrate mode still remains tho, and it feels like the plan for those are in limbo

its true that work remains. I don't think there's been progress on these fronts.

centril (Dec 19 2019 at 14:02, on Zulip):

@pnkfelix I agree there hasn't -- but maybe we need to discuss how it's going to happen?

centril (Dec 19 2019 at 14:02, on Zulip):

doubt it will by itself ;)

centril (Dec 19 2019 at 14:03, on Zulip):

well... Niko and Matthew might finish parts of it off by themselves

pnkfelix (Dec 19 2019 at 14:06, on Zulip):

its probably something I should look into, but its not high priority compared to some other stuff on my plate at least.

pnkfelix (Dec 19 2019 at 15:02, on Zulip):

Hi @T-compiler/meeting! Add a :wave: emoji to show you're here :)

pnkfelix (Dec 19 2019 at 15:02, on Zulip):

today's agenda hackmd

pnkfelix (Dec 19 2019 at 15:02, on Zulip):

lets have five minutes for ...

pnkfelix (Dec 19 2019 at 15:02, on Zulip):

Announcements

pnkfelix (Dec 19 2019 at 15:02, on Zulip):

I've moved to the USA!

nikomatsakis (Dec 19 2019 at 15:02, on Zulip):

regionck, the 2pb lint, and migrate mode still remains tho, and it feels like the plan for those are in limbo

yes, I've been wondering how much to prioritize those and whether it deserves a wg of its own etc :)

pnkfelix (Dec 19 2019 at 15:03, on Zulip):

yes, I've been wondering how much to prioritize those and whether it deserves a wg of its own etc :)

(I guess WG-nll could/should be repurposed for that? Or maybe better to get fresh start

nikomatsakis (Dec 19 2019 at 15:03, on Zulip):

Tomorrow is a design meeting, see #t-compiler > pre-design meeting 2019-12-19 for more details

simulacrum (Dec 19 2019 at 15:03, on Zulip):

We should have a release by end-of-meeting!

pnkfelix (Dec 19 2019 at 15:03, on Zulip):

yay concurrency!

davidtwco (Dec 19 2019 at 15:03, on Zulip):

/me looks forward to #[non_exhaustive] being stable!

nikomatsakis (Dec 19 2019 at 15:05, on Zulip):

(I guess WG-nll could/should be repurposed for that? Or maybe better to get fresh start

could be but I feel like it'd be useful to get a fresh start, and (more importantly) to nail down our exact goals + roadmap and prioritization. There is definitely overlap with #wg-traits as well; I kind of brain-dumped a lot of thoughts to @Matthew Jasper the other day in #wg-traits > regions and universes, as well. I was thinking of asking @Matthew Jasper whether they'd want to help in such an effort :)

Wesley Wiser (Dec 19 2019 at 15:05, on Zulip):

@mw Has been doing some really awesome work on measureme and we now have a PR up which will enable capturing query keys during profiling! https://github.com/rust-lang/rust/pull/67397

nikomatsakis (Dec 19 2019 at 15:05, on Zulip):

Oh, another (pre-) announcement:

Both @Matthew Jasper and @Wesley Wiser have been asked to join the compiler team as full members, and I'm happy to say they accepted. =) But we have to do the "grunt work" of making it official today.

pnkfelix (Dec 19 2019 at 15:06, on Zulip):

oh yeah, I promised someone I'd do that.

centril (Dec 19 2019 at 15:06, on Zulip):

Congratz!

centril (Dec 19 2019 at 15:06, on Zulip):

I'm working on a stabilization report for sub-slice patterns

pnkfelix (Dec 19 2019 at 15:08, on Zulip):

okay lets get into the meat of the meeting. (If anyone has more announcements, privmsg me and I'll allocate time at the end. Or, just post after the meetings "over". :wink:

pnkfelix (Dec 19 2019 at 15:08, on Zulip):

first up, beta nominations

pnkfelix (Dec 19 2019 at 15:08, on Zulip):

beta nom 1/2: "Don't suppress move errors for union fields" #67314

simulacrum (Dec 19 2019 at 15:09, on Zulip):

(these are for 1.41 release, in 6 weeks, to be clear)

pnkfelix (Dec 19 2019 at 15:09, on Zulip):

right. and there are no stable nominations when I last looked.

centril (Dec 19 2019 at 15:10, on Zulip):

So this fixes an ICE for a nightly-only feature but the ICE occurs without the gate?

nikomatsakis (Dec 19 2019 at 15:10, on Zulip):

beta nom 1/2: "Don't suppress move errors for union fields" #67314

this hasn't hit nightly yet...?

pnkfelix (Dec 19 2019 at 15:11, on Zulip):

Since we're talking about this landing for beta in six weeks

pnkfelix (Dec 19 2019 at 15:11, on Zulip):

lets let it wait until it hits nightly

pnkfelix (Dec 19 2019 at 15:11, on Zulip):

and then we'll discuss it then. sound good everyone?

centril (Dec 19 2019 at 15:11, on Zulip):

better to land this sooner, no?

centril (Dec 19 2019 at 15:11, on Zulip):

one more week of testing on beta

simulacrum (Dec 19 2019 at 15:12, on Zulip):

I'm not doing beta backports for a week at least given current queue

simulacrum (Dec 19 2019 at 15:12, on Zulip):

so don't worry :)

pnkfelix (Dec 19 2019 at 15:12, on Zulip):

okay so maybe this is all just bureaucracy for now?

simulacrum (Dec 19 2019 at 15:13, on Zulip):

or getting your work done ahead of time!

nikomatsakis (Dec 19 2019 at 15:13, on Zulip):

(that said, I think it's fine to approve)

pnkfelix (Dec 19 2019 at 15:13, on Zulip):

lets just wait

pnkfelix (Dec 19 2019 at 15:13, on Zulip):

for that one

centril (Dec 19 2019 at 15:14, on Zulip):

@nikomatsakis almost r+ed the PR just now, so I feel beta-approving now and letting @simulacrum do the backport whenever is good

pnkfelix (Dec 19 2019 at 15:14, on Zulip):

I just don't see the point in rushing to beta-approve

pnkfelix (Dec 19 2019 at 15:14, on Zulip):

our policy is to try to eschew beta-approval for things that haven't landed in nightly

pnkfelix (Dec 19 2019 at 15:14, on Zulip):

I understand the argument of "one more week of beta testing"

nikomatsakis (Dec 19 2019 at 15:15, on Zulip):

I agree with the policy and am happy to wait

centril (Dec 19 2019 at 15:15, on Zulip):

alright

pnkfelix (Dec 19 2019 at 15:15, on Zulip):

but that has to be balanced against "don't waste beta-backporting time for something that hasn't been stressed on nightly yet"

centril (Dec 19 2019 at 15:15, on Zulip):

next PR?

pnkfelix (Dec 19 2019 at 15:15, on Zulip):

beta-nom 2/2: "Do not ICE on unnamed future" #67289

centril (Dec 19 2019 at 15:16, on Zulip):

Fixed ICE in diagnostics code, feels safe

pnkfelix (Dec 19 2019 at 15:16, on Zulip):

yep I like it

pnkfelix (Dec 19 2019 at 15:16, on Zulip):

beta-accepted

pnkfelix (Dec 19 2019 at 15:17, on Zulip):

okay. that's al the beta-noms, and we have no stable-noms.

pnkfelix (Dec 19 2019 at 15:18, on Zulip):

for S-waiting-on-team, I'd like to push towards a decision on "[experiment] Do not deduplicate diagnostics in -Z ui-testing mode" #67122

nikomatsakis (Dec 19 2019 at 15:19, on Zulip):

I asked this question that I still do't know the answer to, I guess maybe I can find it by digging into the travis output

One question on the PR, does this mean we have to add corresponding //~ ERROR annotations?

pnkfelix (Dec 19 2019 at 15:20, on Zulip):

is @Vadim Petrochenkov around ?

centril (Dec 19 2019 at 15:20, on Zulip):

One question on the PR, does this mean we have to add corresponding //~ ERROR annotations?

PR diff says no because there are no .rs changes in src/test/ui

nikomatsakis (Dec 19 2019 at 15:20, on Zulip):

on the other hand PR errors out

pnkfelix (Dec 19 2019 at 15:20, on Zulip):

but the PR also doesn't pass travis whatever CI we currently use

centril (Dec 19 2019 at 15:21, on Zulip):

aww

nikomatsakis (Dec 19 2019 at 15:21, on Zulip):

which is what I wanted to investigate...

nikomatsakis (Dec 19 2019 at 15:21, on Zulip):

looks to me like the answer is yes

centril (Dec 19 2019 at 15:21, on Zulip):

ah, even better then

pnkfelix (Dec 19 2019 at 15:21, on Zulip):

that's about 100 tests

nikomatsakis (Dec 19 2019 at 15:21, on Zulip):

see e.g. this line

pnkfelix (Dec 19 2019 at 15:21, on Zulip):

that's not as bad as I expected

centril (Dec 19 2019 at 15:22, on Zulip):

I personally feel this PR is great

pnkfelix (Dec 19 2019 at 15:22, on Zulip):

isn't it at least a little weird

pnkfelix (Dec 19 2019 at 15:22, on Zulip):

that something called "ui-testing mode"

pnkfelix (Dec 19 2019 at 15:22, on Zulip):

is not testing the actual UX ?

pnkfelix (Dec 19 2019 at 15:23, on Zulip):

this is more a complaint about names, not about the functionality itself.

centril (Dec 19 2019 at 15:23, on Zulip):

uhm well... ui/ is possibly a misnomer at this point

nikomatsakis (Dec 19 2019 at 15:23, on Zulip):

it is certainly true that I use the ui testing mode to help "preview" what users will experience

nikomatsakis (Dec 19 2019 at 15:23, on Zulip):

it is also true that we already diverge slightly

centril (Dec 19 2019 at 15:23, on Zulip):

today it's used for all sorts of correctness things unrelated to UX

nikomatsakis (Dec 19 2019 at 15:23, on Zulip):

I disagree it's a misnomer though

nikomatsakis (Dec 19 2019 at 15:23, on Zulip):

today it's used for all sorts of correctness things unrelated to UX

though I think this is true :)

nikomatsakis (Dec 19 2019 at 15:24, on Zulip):

it's just that it's also useful to incidentally test UX at the same time

pnkfelix (Dec 19 2019 at 15:24, on Zulip):

well it seems like ui/ is carrying a lot of tests that are no longer about focusing on UX

centril (Dec 19 2019 at 15:24, on Zulip):

Yea; this is mostly about defaults -- we can still enable the de-dup stuff for specific tests

pnkfelix (Dec 19 2019 at 15:24, on Zulip):

okay so I think we're all in agreement regarding names and just disagreeing about details

nikomatsakis (Dec 19 2019 at 15:24, on Zulip):

that said, I think the same argument might point out that it's useful to detect duplicates -- I've come to the conclusion that pinning down more of our behavior is often good, as long as it's not too much overhead to keep things up to date (e.g., --bless is super)

centril (Dec 19 2019 at 15:24, on Zulip):

@pnkfelix oh yeah; e.g. all the run-pass tests ^^

pnkfelix (Dec 19 2019 at 15:25, on Zulip):

So maybe let me try to make a more concrete step

nikomatsakis (Dec 19 2019 at 15:25, on Zulip):

I think having to add //~ ERROR twice is not too great -- but it's probably rare enough it's "ok"

nikomatsakis (Dec 19 2019 at 15:25, on Zulip):

I think the question in part is how much we think it's ok to rely on this "dedup" mechanism :)

pnkfelix (Dec 19 2019 at 15:25, on Zulip):

I propose we tell @Vadim Petrochenkov to move ahead with this PR. Does anyone present object to moving forward with this PR ?

nikomatsakis (Dec 19 2019 at 15:25, on Zulip):

anyway I think we can probably move forward, nobody seems opposed and some people are in favor

oli (Dec 19 2019 at 15:26, on Zulip):

I'm strongly in favour, we can fix things like duplicate //~ERROR later

pnkfelix (Dec 19 2019 at 15:26, on Zulip):

if someone reading this log later on does object: Post a comment in the PR!

mw (Dec 19 2019 at 15:26, on Zulip):

It would be great to open issues for the worst offenders

pnkfelix (Dec 19 2019 at 15:27, on Zulip):

okay, next on agenda

centril (Dec 19 2019 at 15:27, on Zulip):

I have no doubt that @Esteban K├╝ber will =P

pnkfelix (Dec 19 2019 at 15:27, on Zulip):

I didn't have time to go through the P-high's. this week again. but I'm done with travel for a few months, so I am planning to do a big travesal of them today+tomorrow.

mw (Dec 19 2019 at 15:27, on Zulip):

@centril I guess they'll go straight to opening PRs :)

pnkfelix (Dec 19 2019 at 15:28, on Zulip):

I'll just point out that we have 23 open unassigned P-high issues

centril (Dec 19 2019 at 15:28, on Zulip):

const_if_match ICE

(I have a feeling that despite being observable w/o feature gate, this shouldn't be P-high)

pnkfelix (Dec 19 2019 at 15:29, on Zulip):

ah well that's still nominated

oli (Dec 19 2019 at 15:29, on Zulip):

it's "just" a diagnostic

pnkfelix (Dec 19 2019 at 15:29, on Zulip):

so we can discuss when we get to it. :)

pnkfelix (Dec 19 2019 at 15:30, on Zulip):

there are nine nominations

pnkfelix (Dec 19 2019 at 15:30, on Zulip):

lets start older-first GC: "under latest MinGW, cannot link with C code using stdout" #47048

pnkfelix (Dec 19 2019 at 15:30, on Zulip):

there was discussion of #47048 in the pre-triage channel. @mati865 ^

pnkfelix (Dec 19 2019 at 15:31, on Zulip):

basically, T-infra via @simulacrum is asking T-compiler to make a decision

simulacrum (Dec 19 2019 at 15:31, on Zulip):

mostly just me! but I think T-infra would agree.

pnkfelix (Dec 19 2019 at 15:31, on Zulip):

about whether we should risk upgrading our mingw-w64 version

pnkfelix (Dec 19 2019 at 15:32, on Zulip):

there's some issue that @mati865 mentioned that would need to be addressed

mati865 (Dec 19 2019 at 15:33, on Zulip):

I'm trying to come up with a solution to use system libraries (if present) so the fix would be in librustc_codegen_ssa.

pnkfelix (Dec 19 2019 at 15:33, on Zulip):

but the point remains: How can/should we evaluate the risk here?

mati865 (Dec 19 2019 at 15:33, on Zulip):

But I do agree Rust should specify exact mingw version that has "the best support".

pnkfelix (Dec 19 2019 at 15:33, on Zulip):

(to be clear: the answer "blind faith" is an option here. Not the ideal one, but just want to put it out there.)

nikomatsakis (Dec 19 2019 at 15:34, on Zulip):

I'm not 100% sure on what's being proposed.

nikomatsakis (Dec 19 2019 at 15:34, on Zulip):

Basically just a one-time "jump" in the recommended version?

pnkfelix (Dec 19 2019 at 15:34, on Zulip):

@mati865 can you provide a summary?

mati865 (Dec 19 2019 at 15:34, on Zulip):

Sure

mati865 (Dec 19 2019 at 15:35, on Zulip):

Here how it is:
Currently linking objects from windows-gnu and C code works only when mingw-w64 installed by user matches one provided by Rust.

mati865 (Dec 19 2019 at 15:35, on Zulip):

It was updated long time ago and nowadays it barely works for anyone.

mati865 (Dec 19 2019 at 15:36, on Zulip):

IMO it's not possible to pick one mingw version that will work for everyone.

mati865 (Dec 19 2019 at 15:37, on Zulip):

I don't know how much details do you want about it, it can be long wall of text.

pnkfelix (Dec 19 2019 at 15:37, on Zulip):

well you also noted using the system libraries if present

pnkfelix (Dec 19 2019 at 15:38, on Zulip):

is that a pre-requisite (of an upgrade) ?

mati865 (Dec 19 2019 at 15:38, on Zulip):

In short I think Rust should use mingw-w64 libraries from the system (if they are installed) over the libs shipped in rust-mingw.

nikomatsakis (Dec 19 2019 at 15:38, on Zulip):

Is this something where an RFC would make sense?

nikomatsakis (Dec 19 2019 at 15:38, on Zulip):

In any case, to be honest, I think the plan that @mati865 is proposing sounds good --

pnkfelix (Dec 19 2019 at 15:38, on Zulip):

or is use of system-libraries just "the disciplined fix", while a version upgrade is an orthogonal "nice to have" ?

mati865 (Dec 19 2019 at 15:38, on Zulip):

Right now it always takes own libraries and uses system headers which are never compatible.

nikomatsakis (Dec 19 2019 at 15:39, on Zulip):

I'd definitely like to "enable" somebody to make progess on this issue, the only concern would be doing something that winds up burning a lot of users or something

pnkfelix (Dec 19 2019 at 15:39, on Zulip):

I don't know about an RFC. Though maybe that would potentially tell us about who cares about this target.

nikomatsakis (Dec 19 2019 at 15:39, on Zulip):

I guess I think in a perfect world this feels very "RFC able" to me, but we'd have to ensure we actually move fwd

nikomatsakis (Dec 19 2019 at 15:40, on Zulip):

i.e., I think we still need the guts to embrace the plan :) but the idea would be "if we don't hear a lot of objections, we do it"

pnkfelix (Dec 19 2019 at 15:40, on Zulip):

how soon do you think you might be able to put something together, @mati865 ? I'm curious how soon in the release cycle we might get to see something in nightly

mati865 (Dec 19 2019 at 15:40, on Zulip):

or is use of system-libraries just "the disciplined fix", while a version upgrade is an orthogonal "nice to have" ?

Using system libraries would solve the issue and allow upgrading mingw-w64 without breaking stuff.

nikomatsakis (Dec 19 2019 at 15:41, on Zulip):

iiuc we would basically be saying

nikomatsakis (Dec 19 2019 at 15:41, on Zulip):

"we will use the system libraries and we test against this version"

mati865 (Dec 19 2019 at 15:41, on Zulip):

There is my first iteration of WIP fix: d87b0043778b83063b7e431c63bb1cf47bcbdac9

nikomatsakis (Dec 19 2019 at 15:41, on Zulip):

"if you use another version it might not work"

nikomatsakis (Dec 19 2019 at 15:41, on Zulip):

is that correct?

nikomatsakis (Dec 19 2019 at 15:41, on Zulip):

(and we periodically bump along?)

mati865 (Dec 19 2019 at 15:41, on Zulip):

is that correct?

Yeah that's how it is right now.

mati865 (Dec 19 2019 at 15:42, on Zulip):

By using system libs any "not too" version should work.

mati865 (Dec 19 2019 at 15:43, on Zulip):

You probably will want to move to other nominated issues BTW.

centril (Dec 19 2019 at 15:43, on Zulip):

(17 min left)

nikomatsakis (Dec 19 2019 at 15:43, on Zulip):

Sounds like we should let @mati865 experiment and revisit?

nikomatsakis (Dec 19 2019 at 15:43, on Zulip):

But nobody has specific objections?

nikomatsakis (Dec 19 2019 at 15:44, on Zulip):

I won't press the RFC point but I think at least a good write-up of the situation would be very welcome (we could document it for example in the rustc book

pnkfelix (Dec 19 2019 at 15:44, on Zulip):

okay. I think it sounds like we can/should ask @mati865 to move forward with this

pnkfelix (Dec 19 2019 at 15:45, on Zulip):

so again, if anyone here objects, say so, or write a comment on the issue.

pnkfelix (Dec 19 2019 at 15:45, on Zulip):

I'm going to skip the nomination of #58633

pnkfelix (Dec 19 2019 at 15:46, on Zulip):

(its about unused_attributes and I think it needs discussion elsewhere first)

pnkfelix (Dec 19 2019 at 15:46, on Zulip):

((look in pre-triage topic for more info))

pnkfelix (Dec 19 2019 at 15:46, on Zulip):

likewise I'm skipping nomination of #63232 (licensing stuff)

pnkfelix (Dec 19 2019 at 15:47, on Zulip):

nomination: "Pin is unsound due to rogue Deref/DerefMut implementations" #66544

pnkfelix (Dec 19 2019 at 15:47, on Zulip):

is this still waiting on lang team stuff?

centril (Dec 19 2019 at 15:47, on Zulip):

think so

pnkfelix (Dec 19 2019 at 15:47, on Zulip):

okay lets skip it

nikomatsakis (Dec 19 2019 at 15:47, on Zulip):

(yes)

pnkfelix (Dec 19 2019 at 15:47, on Zulip):

try to make progress instead on things we might actually resolve

pnkfelix (Dec 19 2019 at 15:47, on Zulip):

i left this nominated "Const generic ICE: constant in type had an ignored error: TooGeneric" #66962

pnkfelix (Dec 19 2019 at 15:48, on Zulip):

but its P-medium. why did I leave it nominated. :question:

pnkfelix (Dec 19 2019 at 15:48, on Zulip):

skipping for now

pnkfelix (Dec 19 2019 at 15:49, on Zulip):

nominated: "Replace our fragile safety scheme around erroneous constants" #67191

pnkfelix (Dec 19 2019 at 15:49, on Zulip):

is this a lang team Q at this point too ?

pnkfelix (Dec 19 2019 at 15:49, on Zulip):

I think so. skipping.

centril (Dec 19 2019 at 15:50, on Zulip):

@oli can you attend t-lang mtg later?

pnkfelix (Dec 19 2019 at 15:50, on Zulip):

nominated: "Casting or adding type ascription to panic!() triggers unreachable_code" #67227

pnkfelix (Dec 19 2019 at 15:50, on Zulip):

this similarly is waiting on T-lang, I think

oli (Dec 19 2019 at 15:50, on Zulip):

@centril thursday evenings are p bad for me, I'll tell you around 18:00 if I can

pnkfelix (Dec 19 2019 at 15:50, on Zulip):

but I did want to point out that it might be relevant to ask how hard the hypothetical distinction is to implement

centril (Dec 19 2019 at 15:50, on Zulip):

aight

pnkfelix (Dec 19 2019 at 15:51, on Zulip):

nominated: "const_if_match ICE" #67405

oli (Dec 19 2019 at 15:51, on Zulip):

"just" an error turned ICE

oli (Dec 19 2019 at 15:51, on Zulip):

needs some debugging, but easy to fix I think

centril (Dec 19 2019 at 15:51, on Zulip):

So I was wondering if we should keep P-high-ing these

centril (Dec 19 2019 at 15:51, on Zulip):

and whether they should be nominated

pnkfelix (Dec 19 2019 at 15:52, on Zulip):

Lets talk about that meta topic

centril (Dec 19 2019 at 15:52, on Zulip):

(these = nightly-only features where the ICE can be triggered without the gate)

nikomatsakis (Dec 19 2019 at 15:52, on Zulip):

I think it maybe depends a bit on how easy it is to stumble across the feature

pnkfelix (Dec 19 2019 at 15:52, on Zulip):

in my opinion: in general, If you get a useful diagnostic before the ICE occurs

pnkfelix (Dec 19 2019 at 15:52, on Zulip):

then it need not be P-high

nikomatsakis (Dec 19 2019 at 15:52, on Zulip):

(as a general rule?)

pnkfelix (Dec 19 2019 at 15:52, on Zulip):

namely, if the diagnostic actually tells the user how to resolve the probem

nikomatsakis (Dec 19 2019 at 15:52, on Zulip):

(i.e., irrespective of whether it uses nightly features?)

pnkfelix (Dec 19 2019 at 15:52, on Zulip):

Yes

pnkfelix (Dec 19 2019 at 15:53, on Zulip):

that is at least the rule of thumb I have applied

centril (Dec 19 2019 at 15:53, on Zulip):

in my opinion: in general, If you get a useful diagnostic before the ICE occurs

that tends to be the case

pnkfelix (Dec 19 2019 at 15:53, on Zulip):

to decide between P-high vs P-medium for ICEs.

centril (Dec 19 2019 at 15:53, on Zulip):

alright; I'll use your (@pnkfelix) opinion then when triaging

pnkfelix (Dec 19 2019 at 15:53, on Zulip):

because an ICE without a useful diagnostic for the end user is a far more upsetting experience

centril (Dec 19 2019 at 15:53, on Zulip):

(namely this would be P-medium and not nominated)

nikomatsakis (Dec 19 2019 at 15:53, on Zulip):

I think that's a reasonable rule

pnkfelix (Dec 19 2019 at 15:53, on Zulip):

does this seem like a reasonable policy to everyone?

mw (Dec 19 2019 at 15:54, on Zulip):

I thought common ICEs are always P-High

pnkfelix (Dec 19 2019 at 15:54, on Zulip):

(i of course recommend double-checking that making use of the diagnostic feedback does indeed resolve the ICE)

pnkfelix (Dec 19 2019 at 15:54, on Zulip):

I thought common ICEs are always P-High

the problem is that we have too many P-high issues

pnkfelix (Dec 19 2019 at 15:55, on Zulip):

and we need to be realistic about managing them,

pnkfelix (Dec 19 2019 at 15:55, on Zulip):

and how to prioritize. I'd rather focus on fixing the ICE's that are actually causing real problems for end users

pnkfelix (Dec 19 2019 at 15:55, on Zulip):

(I can imagine that ICE's do cause problems for some users even when the diagnostics are issued.)

mw (Dec 19 2019 at 15:56, on Zulip):

yes, that's what I was thinking about

nikomatsakis (Dec 19 2019 at 15:56, on Zulip):

I am reminded that ICEs can cause problems for RLS users

pnkfelix (Dec 19 2019 at 15:56, on Zulip):

but it still seems lower priority that the cases of "there's no diagnostic output at all"

pnkfelix (Dec 19 2019 at 15:56, on Zulip):

right, RLS is what I was thinking of when I said "some users"

mw (Dec 19 2019 at 15:56, on Zulip):

the level of annoyance decides priority for me

mw (Dec 19 2019 at 15:57, on Zulip):

where the level of annoyance might be lowered by getting a useful diagnostic before the ICE

nikomatsakis (Dec 19 2019 at 15:57, on Zulip):

I still think the felix rule is reasonable

pnkfelix (Dec 19 2019 at 15:57, on Zulip):

I assume the reason that RLS cannot resolve this on their end is that it causes complete breakdown of e.g. save-analysis generation ?

nikomatsakis (Dec 19 2019 at 15:57, on Zulip):

we should maybe investigate how to improve RLS experience --

centril (Dec 19 2019 at 15:57, on Zulip):

For me it is "fix all issues affecting stable first, then things which are nearing stabilization, ..." (but I interpret this as not really affecting stable, sorta)

mw (Dec 19 2019 at 15:57, on Zulip):

I have no strong opinion really :)

pnkfelix (Dec 19 2019 at 15:58, on Zulip):

For me it is "fix all issues affecting stable first, then things which are nearing stabilization, ..." (but I interpret this as not really affecting stable, sorta)

yes, this is a finer grain distinction

pnkfelix (Dec 19 2019 at 15:58, on Zulip):

and perhaps an important one

pnkfelix (Dec 19 2019 at 15:58, on Zulip):

though sometimes things that affect stable are lower priority than things that affect only beta

pnkfelix (Dec 19 2019 at 15:59, on Zulip):

anyway I think we've resolved for #67405 that it should be downgraded to P-medium

centril (Dec 19 2019 at 15:59, on Zulip):

(yea, by "stable" I mean not-nightly)

pnkfelix (Dec 19 2019 at 15:59, on Zulip):

right ?

pnkfelix (Dec 19 2019 at 16:00, on Zulip):

okay

pnkfelix (Dec 19 2019 at 16:00, on Zulip):

we're basically out of time

pnkfelix (Dec 19 2019 at 16:00, on Zulip):

@simulacrum is there anything to report for WG-parallel-rustc ?

simulacrum (Dec 19 2019 at 16:01, on Zulip):

uh, my comments there are good

simulacrum (Dec 19 2019 at 16:01, on Zulip):

We're gathering feedback on a parallel compiler from folks on this internals thread. @Josh Triplett has done some profiling for us on a 72 core machine which may have revealed a deadlock and some scalability issues, which we'll be looking into.

Current overall plan I believe is to evaluate the performance and other reports from folks on the internals thread, and then likely move forward on shipping the parallel compiler early in the new year with the default thread count still capped at 4. The timeline depends on what issues are discovered in the next few weeks though.

nikomatsakis (Dec 19 2019 at 16:02, on Zulip):

Note that the reason the thread count is capped at 4 is

nikomatsakis (Dec 19 2019 at 16:02, on Zulip):

that we know there are scalability problems beyond that

nikomatsakis (Dec 19 2019 at 16:02, on Zulip):

at least in part linked to the jobserver / cargo integration

nikomatsakis (Dec 19 2019 at 16:03, on Zulip):

and we would still plan to address those

nikomatsakis (Dec 19 2019 at 16:03, on Zulip):

(in parallel, no pun intended)

centril (Dec 19 2019 at 16:03, on Zulip):

We have a release: https://blog.rust-lang.org/2019/12/19/Rust-1.40.0.html

pnkfelix (Dec 19 2019 at 16:05, on Zulip):

okay, great meeting you all! Thanks to everyone in @T-compiler/meeting for participating!

Last update: Jan 21 2020 at 09:15UTC