Stream: t-compiler

Topic: weekly meeting 2020-04-16 #54818


Santiago Pastorino (Apr 15 2020 at 17:54, on Zulip):

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

Santiago Pastorino (Apr 15 2020 at 17:56, on Zulip):

The @WG-prioritization will be doing pre-triage in #t-compiler/wg-prioritization > pre-meeting triage 2020-04-16 #54818

Santiago Pastorino (Apr 15 2020 at 17:57, on Zulip):

most of the prioritization work is being done async currently but this will be the sync part of the process

Santiago Pastorino (Apr 15 2020 at 17:57, on Zulip):

we will have @T-compiler/WG-meta and @WG-mir-opt checkins

Santiago Pastorino (Apr 15 2020 at 17:59, on Zulip):

there is an error in the logic of the checkins selection so some working groups had checkins recently, I think meta had one recently, anyway @nikomatsakis do you think we need to provide an update?

Santiago Pastorino (Apr 15 2020 at 17:59, on Zulip):

@oli can you provide the checkin tomorrow for @_WG-mir-opt?

oli (Apr 15 2020 at 17:59, on Zulip):

huh has that much time passed already

oli (Apr 15 2020 at 18:00, on Zulip):

I'll build a summary

pnkfelix (Apr 15 2020 at 18:01, on Zulip):

oli said:

huh has that much time passed already

(i think the schedule got distorted when a new WG was added a week or two ago, and we don't have a plan to fix the design bug in the scheduling software that causes that distortion.)

Santiago Pastorino (Apr 15 2020 at 18:02, on Zulip):

yeah, feel free to just skip this one

Santiago Pastorino (Apr 15 2020 at 18:03, on Zulip):

@WG-prioritization will be building the agenda

oli (Apr 15 2020 at 18:04, on Zulip):

ok, let's skip

Santiago Pastorino (Apr 16 2020 at 13:37, on Zulip):

@T-compiler/meeting triage meeting is starting in 23 minutes

pnkfelix (Apr 16 2020 at 14:01, on Zulip):

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

pnkfelix (Apr 16 2020 at 14:01, on Zulip):

We'll start off with five minutes for ...

pnkfelix (Apr 16 2020 at 14:01, on Zulip):

Announcements

eddyb (Apr 16 2020 at 14:01, on Zulip):
pnkfelix (Apr 16 2020 at 14:01, on Zulip):
eddyb (Apr 16 2020 at 14:02, on Zulip):

if you see any query count differences in a run that shouldn't affect query counts, please let us know

eddyb (Apr 16 2020 at 14:02, on Zulip):

the main source of them has been -C metadata differences between the two compilers, which we've alleviated, we believe

eddyb (Apr 16 2020 at 14:02, on Zulip):

(we = @simulacrum and I, I mean)

eddyb (Apr 16 2020 at 14:03, on Zulip):

and enjoy the (hopefully) more useful perf experience :grinning_face_with_smiling_eyes:

pnkfelix (Apr 16 2020 at 14:03, on Zulip):
nikomatsakis (Apr 16 2020 at 14:04, on Zulip):
pnkfelix (Apr 16 2020 at 14:04, on Zulip):

so that means we have less than a week left to try to get in any further stable-to-beta backports

pnkfelix (Apr 16 2020 at 14:04, on Zulip):
pnkfelix (Apr 16 2020 at 14:04, on Zulip):
simulacrum (Apr 16 2020 at 14:05, on Zulip):

(and new mcp proposals will file a major-change topic automatically)

nikomatsakis (Apr 16 2020 at 14:05, on Zulip):

Ah, cool, I'll update the RFC to mention that

simulacrum (Apr 16 2020 at 14:05, on Zulip):

in #t-compiler/major changes btw

simulacrum (Apr 16 2020 at 14:05, on Zulip):

interested parties, probably T-compiler, should subscribe to that stream probably

pnkfelix (Apr 16 2020 at 14:06, on Zulip):

okay, lets see: today's agenda is here

simulacrum (Apr 16 2020 at 14:06, on Zulip):

for others: if there's similar type of things where you want to get pinged on some label being added or similar, please let me know (PM or in #t-release/triagebot)

eddyb (Apr 16 2020 at 14:07, on Zulip):

@simulacrum sounds like this could fit well with the "experts" ideas

pnkfelix (Apr 16 2020 at 14:07, on Zulip):

lets move on to beta nominations

pnkfelix (Apr 16 2020 at 14:07, on Zulip):

beta-nom 1/1: "Do not reuse post LTO products when exports change" #71131

pnkfelix (Apr 16 2020 at 14:09, on Zulip):

oh

nikomatsakis (Apr 16 2020 at 14:09, on Zulip):

what's up with the perf results at the end?

pnkfelix (Apr 16 2020 at 14:09, on Zulip):

actually I have an opinion on this

pnkfelix (Apr 16 2020 at 14:09, on Zulip):

I started building a pair of compilers last night to investigate the perf issues

pnkfelix (Apr 16 2020 at 14:09, on Zulip):

but haven't had a chance to do the investigation yet

pnkfelix (Apr 16 2020 at 14:09, on Zulip):

The perf results "only" affect incremental compilation

pnkfelix (Apr 16 2020 at 14:10, on Zulip):

so the question is: Is it worth landing a bug fix like this that has some amount of performance regression?

pnkfelix (Apr 16 2020 at 14:10, on Zulip):

or are we better off waiting a bit longer

pnkfelix (Apr 16 2020 at 14:10, on Zulip):

so that I have time to investigate

eddyb (Apr 16 2020 at 14:10, on Zulip):

I think it only affects incremental compilation when certain kinds of code is added/removed

simulacrum (Apr 16 2020 at 14:10, on Zulip):

I'd say yes, the perf tests affected are fairly artificial anyway

simulacrum (Apr 16 2020 at 14:10, on Zulip):

and it seems to not affect everything

eddyb (Apr 16 2020 at 14:11, on Zulip):

note how the big regressions are primarily "println"

pnkfelix (Apr 16 2020 at 14:11, on Zulip):

eddyb said:

I think it only affects incremental compilation when certain kinds of code is added/removed

In at least one of the cases I was looking at, the only thing being added was a { }

simulacrum (Apr 16 2020 at 14:11, on Zulip):

(OTOH, beta promotion is next week to stable)

eddyb (Apr 16 2020 at 14:11, on Zulip):

@pnkfelix was that a 4% regression or a >50% regression?

pnkfelix (Apr 16 2020 at 14:11, on Zulip):

the { } thing may have been just noise; I do not know. Does perf do multiple runs, or just one?

simulacrum (Apr 16 2020 at 14:11, on Zulip):

depends on the benchmark

simulacrum (Apr 16 2020 at 14:11, on Zulip):

mostly 3

simulacrum (Apr 16 2020 at 14:11, on Zulip):

(and takes min)

pnkfelix (Apr 16 2020 at 14:12, on Zulip):

@eddyb it was "patched incremental: is valid cap letter"

pnkfelix (Apr 16 2020 at 14:12, on Zulip):

in regex-opt

pnkfelix (Apr 16 2020 at 14:12, on Zulip):

which reported a 328.4% regression

eddyb (Apr 16 2020 at 14:12, on Zulip):

that is worrying, invalidates my hypothesis

simulacrum (Apr 16 2020 at 14:12, on Zulip):

https://github.com/rust-lang/rustc-perf/blob/master/collector/benchmarks/regex/1-is-valid-cap-letter.patch for reference

pnkfelix (Apr 16 2020 at 14:12, on Zulip):

there's a possibility that the code I put in it itself expensive

simulacrum (Apr 16 2020 at 14:13, on Zulip):

https://perf.rust-lang.org/detailed-query.html?commit=c8085c9fa29609558b4745fc37c7a14c335e0ec3&base_commit=edc02580e4e80476ac1ded2cc1008eaf8b8400e6&benchmark=regex-opt&run_name=patched%20incremental:%20is%20valid%20cap%20letter looks like it's almost certainly adding new llvm modules

pnkfelix (Apr 16 2020 at 14:13, on Zulip):

namely, it does a set-equivalence test on two vectors by building hashsets, with some fast-paths for e.g. empty vecs or vecs with exact same contents

pnkfelix (Apr 16 2020 at 14:13, on Zulip):

its possible that the order of the elements in the vecs is happening to show up in a way here that makes the second fast path not applicable

eddyb (Apr 16 2020 at 14:13, on Zulip):

@simulacrum could it be the noise we just removed? should we just re-run try+perf?

simulacrum (Apr 16 2020 at 14:14, on Zulip):

hm, I think no, but perhaps

pnkfelix (Apr 16 2020 at 14:14, on Zulip):

@simulacrum wait, how is { } adding new llvm modules?

simulacrum (Apr 16 2020 at 14:14, on Zulip):

@pnkfelix no idea

pnkfelix (Apr 16 2020 at 14:14, on Zulip):

okay well we are getting in the weeds I guess

simulacrum (Apr 16 2020 at 14:14, on Zulip):

that's just my assessment of 'what happened' based on the perf diff

nikomatsakis (Apr 16 2020 at 14:14, on Zulip):

it's possible we're now doing LTO when we weren't before, or something like that..?

nikomatsakis (Apr 16 2020 at 14:14, on Zulip):

anyway, I agree we should move on

pnkfelix (Apr 16 2020 at 14:14, on Zulip):

so the question comes back to: Should we land this, since it does fix a bug?

nikomatsakis (Apr 16 2020 at 14:14, on Zulip):

though it's hard to tell what the outcome of this discussion is

pnkfelix (Apr 16 2020 at 14:14, on Zulip):

and just hope the perf issue gets addressed eventually, even if not in this release?

pnkfelix (Apr 16 2020 at 14:15, on Zulip):

(by that I mean: Should we land and backport to beta)

simulacrum (Apr 16 2020 at 14:15, on Zulip):

hm, so these bugs are somewhat frequent I think in practice, and usually fixable with a cargo clean

simulacrum (Apr 16 2020 at 14:15, on Zulip):

do we have an idea of how prevalent?

pnkfelix (Apr 16 2020 at 14:15, on Zulip):

I personally would be okay if the outcome here is "no, do not backport this"

pnkfelix (Apr 16 2020 at 14:15, on Zulip):

even though I hate when these bugs come up

simulacrum (Apr 16 2020 at 14:15, on Zulip):

worth nothing that if we land now, it'll be in the beta quite quickly, so a perf fix may want to be backported

pnkfelix (Apr 16 2020 at 14:15, on Zulip):

@simulacrum indeed, I might even wait a week to land it in that case...

pnkfelix (Apr 16 2020 at 14:15, on Zulip):

(to nightly, that is)

eddyb (Apr 16 2020 at 14:16, on Zulip):

(started a second perf attempt just to see if it matches the first one)

simulacrum (Apr 16 2020 at 14:16, on Zulip):

I think we should at least understand what is going wrong before backporting

pnkfelix (Apr 16 2020 at 14:16, on Zulip):

thanks @eddyb

Wesley Wiser (Apr 16 2020 at 14:16, on Zulip):

I think I would lean toward backporting because I think a perf regression is better than the bug. But additional investigation into the performance would be great.

pnkfelix (Apr 16 2020 at 14:16, on Zulip):

Anyone else in @Wesley Wiser 's camp here?

nikomatsakis (Apr 16 2020 at 14:16, on Zulip):

reading comments from the issue, I see that @Aaron Hill noted:

Extend the check added in #67020 to rebuild both the 'importer' and 'importee' when the import map changes. That is, if module 'A' starts/stops importing from module 'B', we rebuild both A and B. This is a broader change than 1), and should hopefully continue to work even if LLVM gets 'smarter'. However, it could cause us to unnecessarily re-run codegen for some modules, which could have a significant performance impact.

(emphasis mine)

eddyb (Apr 16 2020 at 14:16, on Zulip):

isn't the bug longstanding?

pnkfelix (Apr 16 2020 at 14:16, on Zulip):

The bug is pretty nasty

pnkfelix (Apr 16 2020 at 14:16, on Zulip):

when it arises...

nikomatsakis (Apr 16 2020 at 14:17, on Zulip):

is this exclusively affecting incremental?

simulacrum (Apr 16 2020 at 14:17, on Zulip):

yeah, seems to be just incr

nikomatsakis (Apr 16 2020 at 14:17, on Zulip):

i.e., the difference is that some incremental builds get slower (maybe quite a bit)

nikomatsakis (Apr 16 2020 at 14:17, on Zulip):

versus doing horrible things?

pnkfelix (Apr 16 2020 at 14:17, on Zulip):

Yes I believe all the perf regressions are just on incremental. As are the horrible things.

nikomatsakis (Apr 16 2020 at 14:17, on Zulip):

I think I'm with @Wesley Wiser too that I'd prefer the compiler takes longer but rebuilds everything that has to be rebuilt :P

pnkfelix (Apr 16 2020 at 14:17, on Zulip):

but link failures are pretty frustrating

Wesley Wiser (Apr 16 2020 at 14:17, on Zulip):

The linked issue makes it sound like the visible effect of the bug is new even if the underlying bug itself is old.

simulacrum (Apr 16 2020 at 14:17, on Zulip):

Yeah I'd be in favor of landing I think

simulacrum (Apr 16 2020 at 14:17, on Zulip):

er, backporting

nikomatsakis (Apr 16 2020 at 14:17, on Zulip):

but I do think it's worth investigating to be able to say concretely what is going wrong

pnkfelix (Apr 16 2020 at 14:18, on Zulip):

I will definitely investigate the performance issue

simulacrum (Apr 16 2020 at 14:18, on Zulip):

presuming @pnkfelix can investigate and confirm that this is "unfortunate but expected"

nikomatsakis (Apr 16 2020 at 14:18, on Zulip):

(not necessarily before landing)

pnkfelix (Apr 16 2020 at 14:18, on Zulip):

it fits well with other work I'm doing

simulacrum (Apr 16 2020 at 14:18, on Zulip):

I'd also like it in nightly asap if it's going to hit stable next week, fwiw

pnkfelix (Apr 16 2020 at 14:18, on Zulip):

okay its basically already been r+'ed, I think, since I added the changes that @nagisa asked for.

pnkfelix (Apr 16 2020 at 14:19, on Zulip):

lets move along then

pnkfelix (Apr 16 2020 at 14:19, on Zulip):

no stable nominations this week

pnkfelix (Apr 16 2020 at 14:19, on Zulip):

PR's S-waiting-on-team

pnkfelix (Apr 16 2020 at 14:19, on Zulip):

T-compiler S-waiting-on-team

pnkfelix (Apr 16 2020 at 14:19, on Zulip):
pnkfelix (Apr 16 2020 at 14:20, on Zulip):
pnkfelix (Apr 16 2020 at 14:20, on Zulip):

(the above are just reminders to check boxes if you haven't already. I need to do so.)

pnkfelix (Apr 16 2020 at 14:20, on Zulip):
pnkfelix (Apr 16 2020 at 14:21, on Zulip):

(hmm, shouldn't thinks with a finished FCP be no longer marked S-waiting-on-team? I guess its just a matter of figuring out if it needs further review?)

pnkfelix (Apr 16 2020 at 14:22, on Zulip):

pnkfelix said:

(the above are just reminders to check boxes if you haven't already. I need to do so.)

oops, I misunderstood the text in the agenda.

pnkfelix (Apr 16 2020 at 14:22, on Zulip):

there weren't any boxes to check even

pnkfelix (Apr 16 2020 at 14:23, on Zulip):
nikomatsakis (Apr 16 2020 at 14:24, on Zulip):

It looks like alex reviewed before

pnkfelix (Apr 16 2020 at 14:24, on Zulip):

(which to me looks like another case where the S-waiting-on-team label is not quite appropriate? Unless I suppose its the team's job to identify a reviewer ...)

nikomatsakis (Apr 16 2020 at 14:25, on Zulip):

should we see if @Alex Crichton wants to review again?

nikomatsakis (Apr 16 2020 at 14:25, on Zulip):

can ping them

pnkfelix (Apr 16 2020 at 14:25, on Zulip):

they looked at it recently

pnkfelix (Apr 16 2020 at 14:25, on Zulip):

commented like yesterday

nikomatsakis (Apr 16 2020 at 14:25, on Zulip):

right

nikomatsakis (Apr 16 2020 at 14:26, on Zulip):

it's not a big change

Santiago Pastorino (Apr 16 2020 at 14:26, on Zulip):

with "needs a reviewer" we meant, nobody is assigned to it

nikomatsakis (Apr 16 2020 at 14:26, on Zulip):

oh, well, I take that back

pnkfelix (Apr 16 2020 at 14:27, on Zulip):

yeah I don't think we should mark this as owned by @Alex Crichton , given that they've stepped back from the project to some degree

pnkfelix (Apr 16 2020 at 14:27, on Zulip):

I'll take it, and either review it or delegate

pnkfelix (Apr 16 2020 at 14:27, on Zulip):

okay lets move along

pnkfelix (Apr 16 2020 at 14:28, on Zulip):

Issues of Note

pnkfelix (Apr 16 2020 at 14:28, on Zulip):
pnkfelix (Apr 16 2020 at 14:28, on Zulip):

P-critical: static FOO:Foo=FOO; doesn't cause cycle error for zero-sized-type with no public constructor. #71078

nikomatsakis (Apr 16 2020 at 14:28, on Zulip):

Looks like @oli is investigating

pnkfelix (Apr 16 2020 at 14:29, on Zulip):

to be clear, this is not a fresh regression, AFAICT

pnkfelix (Apr 16 2020 at 14:29, on Zulip):

injected back in July of last year

pnkfelix (Apr 16 2020 at 14:30, on Zulip):

so this comes back to the question of what does P-critical mean

pnkfelix (Apr 16 2020 at 14:31, on Zulip):

This particular bug is certainly not a release blocker

pnkfelix (Apr 16 2020 at 14:31, on Zulip):

since it was injected so long ago

pnkfelix (Apr 16 2020 at 14:31, on Zulip):

So the the obvious question to me is: Do we wish to revisit this bug every week?

Wesley Wiser (Apr 16 2020 at 14:31, on Zulip):

There was discussion of that around https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/I-prioritize.20.2371078.20.60static.20FOO.3AFoo.3DFOO.3B.60.20doesn't.20cause.20cycl/near/193912866

Santiago Pastorino (Apr 16 2020 at 14:31, on Zulip):

we gave the definition of potentially release blocker, like something that should probably be reviewed often but may or may not block the release

pnkfelix (Apr 16 2020 at 14:32, on Zulip):

the comments do contain a "weaponized" variant

Wesley Wiser (Apr 16 2020 at 14:33, on Zulip):

(Feedback about this decision from #t-compiler/wg-prioritization is certainly welcome :slight_smile: )

nikomatsakis (Apr 16 2020 at 14:33, on Zulip):

the reasoning in that thread makes sense to me

pnkfelix (Apr 16 2020 at 14:33, on Zulip):

anyway as stated

pnkfelix (Apr 16 2020 at 14:33, on Zulip):

@oli is looking at it

pnkfelix (Apr 16 2020 at 14:33, on Zulip):

So I guess we'll keep our eye on it

pnkfelix (Apr 16 2020 at 14:34, on Zulip):

here is a summary of all the issues of note (as posted in agenda as well):

Santiago Pastorino (Apr 16 2020 at 14:34, on Zulip):

note that there are unassigned regressions

Santiago Pastorino (Apr 16 2020 at 14:34, on Zulip):

in particular 2 P-high stable to nightly

pnkfelix (Apr 16 2020 at 14:35, on Zulip):

so yeah, lets at least list the unassigned P-high regressions

pnkfelix (Apr 16 2020 at 14:36, on Zulip):

the first one we've discussed before: Compile regression "cannot infer an appropriate lifetime for lifetime parameter" #70917

nikomatsakis (Apr 16 2020 at 14:36, on Zulip):

It seems like Compile regression "cannot infer an appropriate lifetime for lifetime parameter" #70917 may want to be P-critical

nikomatsakis (Apr 16 2020 at 14:36, on Zulip):

At least the last few comments from @eddyb and I were trending in that direction

pnkfelix (Apr 16 2020 at 14:36, on Zulip):

lets up priority on that, yeah

pnkfelix (Apr 16 2020 at 14:37, on Zulip):

we definitely want to address this in time for the release next week

nikomatsakis (Apr 16 2020 at 14:37, on Zulip):

@eddyb do you think that you can prep a PR?

nikomatsakis (Apr 16 2020 at 14:37, on Zulip):

I could also do it

eddyb (Apr 16 2020 at 14:37, on Zulip):

to revert the behavior?

nikomatsakis (Apr 16 2020 at 14:37, on Zulip):

For lifetimes, right

eddyb (Apr 16 2020 at 14:37, on Zulip):

yeah I'll look into it. not even sure which "outlives"-named thing in the compiler caused it :P

pnkfelix (Apr 16 2020 at 14:38, on Zulip):

to be clear, we are thinking we may want to land this, but in a more gradual way, e.g. with a future-incompat cycle?

pnkfelix (Apr 16 2020 at 14:38, on Zulip):

Or wait, the comments say we may want to allow it

eddyb (Apr 16 2020 at 14:38, on Zulip):

or not at all, we might want to go the other direction and ignore types too

nikomatsakis (Apr 16 2020 at 14:38, on Zulip):

I think maybe, though you could rationalize it

pnkfelix (Apr 16 2020 at 14:38, on Zulip):

gotcha, okay

pnkfelix (Apr 16 2020 at 14:38, on Zulip):

Okay well in any case

Santiago Pastorino (Apr 16 2020 at 14:38, on Zulip):

the other unassigned is "file not found for module" #70314

pnkfelix (Apr 16 2020 at 14:39, on Zulip):

can I assign #70917 to @eddyb ?

pnkfelix (Apr 16 2020 at 14:39, on Zulip):

or should I give it to @nikomatsakis ?

nikomatsakis (Apr 16 2020 at 14:39, on Zulip):

Santiago Pastorino said:

the other one is "file not found for module" #70314

ah yeah, so we got that narrowed down, but we would need someone to investigate

pnkfelix (Apr 16 2020 at 14:39, on Zulip):

okay @eddyb already said they'd look at it

eddyb (Apr 16 2020 at 14:39, on Zulip):

yeah give it to me

eddyb (Apr 16 2020 at 14:39, on Zulip):

@nikomatsakis hmm maybe @Vadim Petrochenkov? if they have time for it

nikomatsakis (Apr 16 2020 at 14:40, on Zulip):

Worth pinging them.

nikomatsakis (Apr 16 2020 at 14:40, on Zulip):

It's kind of an interesting area of the code that I'd like to understand better

nikomatsakis (Apr 16 2020 at 14:40, on Zulip):

wish I had time, but I think I probably don't

pnkfelix (Apr 16 2020 at 14:41, on Zulip):

As noted, there were a bunch of other issues in the summary

pnkfelix (Apr 16 2020 at 14:41, on Zulip):

but we've covered the unassigned P-high (or above) regressions, and that's really all we have time for.

pnkfelix (Apr 16 2020 at 14:42, on Zulip):

So lets move on to nominated issues

pnkfelix (Apr 16 2020 at 14:42, on Zulip):

T-compiler I-nominated

pnkfelix (Apr 16 2020 at 14:42, on Zulip):
pnkfelix (Apr 16 2020 at 14:43, on Zulip):

(so just check your boxes and we can close it once enough are checked.)

pnkfelix (Apr 16 2020 at 14:43, on Zulip):
nikomatsakis (Apr 16 2020 at 14:43, on Zulip):

seems pretty clear that Op is not favored

pnkfelix (Apr 16 2020 at 14:44, on Zulip):

(yeah maybe I should just bypass the FCP on #70928 at this point. it doesn't seem like anyone is going to fight in favor of it at this point...?)

pnkfelix (Apr 16 2020 at 14:44, on Zulip):

(I'll think about that.)

nikomatsakis (Apr 16 2020 at 14:44, on Zulip):

that's a lang FCP, ping @Taylor Cramer @scottmcm and @boats on #70453

pnkfelix (Apr 16 2020 at 14:44, on Zulip):

/me once against shakes his fist at the labelling system

pnkfelix (Apr 16 2020 at 14:45, on Zulip):

do other teams get annoyed by this? Would we have buy in to delete I-nominated and replace it with separate nomination labels for each team?

Santiago Pastorino (Apr 16 2020 at 14:45, on Zulip):

there's Centril added T-compiler I-nominated at the very end, so I was guessing some kind of intervention by the compiler team was expected?

nikomatsakis (Apr 16 2020 at 14:45, on Zulip):

I'm not sure what

nikomatsakis (Apr 16 2020 at 14:46, on Zulip):

I think centril removed T-compiler to start FCP then added it back, not sure where the nominated came from, maybe from the fcp itself

Santiago Pastorino (Apr 16 2020 at 14:46, on Zulip):

me neither, anyway, at least if it serves the purpose of just notifying some people ... :/

eddyb (Apr 16 2020 at 14:46, on Zulip):

@pnkfelix I agree Op is suboptimal, but I'm curious in what venue we might bikeshed alternatives

Wesley Wiser (Apr 16 2020 at 14:46, on Zulip):

Nominated 21 days ago https://github.com/rust-lang/rust/issues/70453#event-3170661280

pnkfelix (Apr 16 2020 at 14:46, on Zulip):

@eddyb hmm. I wish I could say the answer to that is obvious

eddyb (Apr 16 2020 at 14:46, on Zulip):

heh

pnkfelix (Apr 16 2020 at 14:47, on Zulip):

obviously I think Zulip is the answer

eddyb (Apr 16 2020 at 14:47, on Zulip):

I'm fine if there isn't an answer but It'd be sad to leave it hanging for another two years

pnkfelix (Apr 16 2020 at 14:47, on Zulip):

but I know that is not the ideal platform for some

eddyb (Apr 16 2020 at 14:47, on Zulip):

(since I'll surely forget in a second the moment this is closed)

pnkfelix (Apr 16 2020 at 14:47, on Zulip):
pnkfelix (Apr 16 2020 at 14:48, on Zulip):

holy cow that totally needs an MCP, no?

eddyb (Apr 16 2020 at 14:48, on Zulip):

it's a very experimental thing IIUC but that was my guess

nikomatsakis (Apr 16 2020 at 14:48, on Zulip):

I didn't think that was meant to land

nikomatsakis (Apr 16 2020 at 14:48, on Zulip):

but if it is then yes :)

nikomatsakis (Apr 16 2020 at 14:49, on Zulip):

It's certainly an interesting data point in the "unify the parser" space

pnkfelix (Apr 16 2020 at 14:49, on Zulip):

okay so does that mean we close the PR and tell them to make an MCP? Or leave the PR open and tell them it needs to go through MCP process before it can be reviewed?

eddyb (Apr 16 2020 at 14:49, on Zulip):

we now have 3 handwritten parsers and 1 parseable grammar, right?

eddyb (Apr 16 2020 at 14:50, on Zulip):

(although wg-grammar has stalled on account on me not having the time to work on the grammar framework...)

nikomatsakis (Apr 16 2020 at 14:50, on Zulip):

pnkfelix said:

okay so does that mean we close the PR and tell them to make an MCP? Or leave the PR open and tell them it needs to go through MCP process before it can be reviewed?

the RFC says you can close

pnkfelix (Apr 16 2020 at 14:50, on Zulip):

okay

Wesley Wiser (Apr 16 2020 at 14:50, on Zulip):

Maybe we should just ask the author what their intent for this was? If this is just a cool proof of concept, we can close. Otherwise they should file a MCP.

pnkfelix (Apr 16 2020 at 14:50, on Zulip):

I'll take care of that after the meeting.

nikomatsakis (Apr 16 2020 at 14:50, on Zulip):

@matklad left some useful comments at the end

pnkfelix (Apr 16 2020 at 14:51, on Zulip):

(it sounds like we can close it either way, and let the author take the next steps. but I want to make sure I get the language right in my comment, because I do not want to discourage the author from taking further steps...)

pnkfelix (Apr 16 2020 at 14:51, on Zulip):

If anyone present at this meeting thinks they would be interested and have time to review such a PR, definitely reach out (either on the PR itself, or ping me)

pnkfelix (Apr 16 2020 at 14:51, on Zulip):

(or just say so here)

pnkfelix (Apr 16 2020 at 14:52, on Zulip):

Okay so now its WG check in time

pnkfelix (Apr 16 2020 at 14:52, on Zulip):

the checkin schedule is, as last week, a bit disrupted

pnkfelix (Apr 16 2020 at 14:52, on Zulip):

in that we are revisiting teams sooner than expected

pnkfelix (Apr 16 2020 at 14:52, on Zulip):

@nikomatsakis do you have anything to report from WG-meta?

nikomatsakis (Apr 16 2020 at 14:53, on Zulip):

Yeah

nikomatsakis (Apr 16 2020 at 14:53, on Zulip):

Update:

2020-04-16

Wesley Wiser (Apr 16 2020 at 14:54, on Zulip):

nikomatsakis said:

I love that! Really good idea!

pnkfelix (Apr 16 2020 at 14:55, on Zulip):

would these go on the forge? or on the compiler-team website?

nikomatsakis (Apr 16 2020 at 14:55, on Zulip):

probably forge

nikomatsakis (Apr 16 2020 at 14:55, on Zulip):

and linked from elsewhere

nikomatsakis (Apr 16 2020 at 14:55, on Zulip):

but I'm entirely sure, I'd like to scope it out to the project as a whole eventually

pnkfelix (Apr 16 2020 at 14:55, on Zulip):

I'm in part wondering (once again) what diagramming facilities we currently have available

simulacrum (Apr 16 2020 at 14:55, on Zulip):

I think @eddyb's suggestion to maybe e.g. auto link PRs touching some area of the compiler to a zulip stream could be interesting

pnkfelix (Apr 16 2020 at 14:55, on Zulip):

and whether we can improve upon them

nikomatsakis (Apr 16 2020 at 14:56, on Zulip):

pnkfelix said:

I'm in part wondering (once again) what diagramming facilities we currently have available

I recently found that there is tooling to integrate mermaid into mdbook

eddyb (Apr 16 2020 at 14:56, on Zulip):

@simulacrum it would certainly remove random surprises where I find a change I would've wanted to review, days/weeks/months later, for a completely unrelated reason :P

nikomatsakis (Apr 16 2020 at 14:56, on Zulip):

I was going to try and integrate it into the chalk book to support docs like this view of how chalk works

pnkfelix (Apr 16 2020 at 14:56, on Zulip):

/me is upset that there is no :mermaid: emoji

eddyb (Apr 16 2020 at 14:57, on Zulip):

🧜‍♀️

pnkfelix (Apr 16 2020 at 14:57, on Zulip):

yeah cannot put that as a reaction though.

nikomatsakis (Apr 16 2020 at 14:57, on Zulip):

we could add to forge, too, is the point :)

nikomatsakis (Apr 16 2020 at 14:58, on Zulip):

and I would like to port the comiler-team website to mdbook

nikomatsakis (Apr 16 2020 at 14:58, on Zulip):

mdbook all the things

pnkfelix (Apr 16 2020 at 14:58, on Zulip):

okay. sounds like something fun to look into

pnkfelix (Apr 16 2020 at 14:59, on Zulip):

As for WG-mir-opt, they are skipping checkin this week (because we heard from them recently)

pnkfelix (Apr 16 2020 at 15:00, on Zulip):

so that's all, folks! Now time for me to follow up on those post-meeting tasks I promised above. :)

pnkfelix (Apr 16 2020 at 15:01, on Zulip):

oh, right; Bye @T-compiler/meeting , you are all awesome. Stay safe, stay well.

pnkfelix (Apr 16 2020 at 15:22, on Zulip):

nikomatsakis said:

pnkfelix said:

okay so does that mean we close the PR and tell them to make an MCP? Or leave the PR open and tell them it needs to go through MCP process before it can be reviewed?

the RFC says you can close

Ah, the RFC says "The PR should be closed or marked as blocked." I'm more inclined at the moment to do the latter.

Last update: Jun 04 2020 at 18:45UTC