Stream: t-compiler/meetings

Topic: [weekly meeting] 2020-06-04 #54818


Santiago Pastorino (Jun 03 2020 at 19:02, on Zulip):

Hi @T-compiler/meeting; the triage meeting will be starting in ~ 19 hours

Santiago Pastorino (Jun 03 2020 at 19:03, on Zulip):

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

Santiago Pastorino (Jun 03 2020 at 19:04, on Zulip):

During pre-triage we will be preparing the meeting agenda

Santiago Pastorino (Jun 03 2020 at 19:04, on Zulip):

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

Santiago Pastorino (Jun 03 2020 at 19:05, on Zulip):

@nikomatsakis and I should have something to share about @T-compiler/WG-meta

Santiago Pastorino (Jun 03 2020 at 19:05, on Zulip):

@oli do you have something you want to share about @WG-mir-opt?

oli (Jun 04 2020 at 07:21, on Zulip):

jop, I'll build sth for wg-mir-opt

oli (Jun 04 2020 at 07:46, on Zulip):

In case I miss the check in: https://hackmd.io/H49SQNHURUmVUimyOONgEA

Santiago Pastorino (Jun 04 2020 at 12:50, on Zulip):

@oli great, going to copy that to the agenda last section where we have the checkins

Santiago Pastorino (Jun 04 2020 at 12:51, on Zulip):

done

Santiago Pastorino (Jun 04 2020 at 13:36, on Zulip):

Hi @T-compiler/meeting, triage meeting will be starting in ~ 24 minutes

pnkfelix (Jun 04 2020 at 14:01, on Zulip):

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

pnkfelix (Jun 04 2020 at 14:02, on Zulip):

we will start off with 5 minutes for ...

pnkfelix (Jun 04 2020 at 14:02, on Zulip):

Announcements

pnkfelix (Jun 04 2020 at 14:02, on Zulip):
pnkfelix (Jun 04 2020 at 14:02, on Zulip):
pnkfelix (Jun 04 2020 at 14:03, on Zulip):
pnkfelix (Jun 04 2020 at 14:03, on Zulip):

Beta-nominations

No beta nominations this time for T-compiler, libs-impl and T-rustdoc.

Stable-nominations

No stable nominations this time for T-compiler, libs-impl and T-rustdoc.

pnkfelix (Jun 04 2020 at 14:03, on Zulip):

heh I jumped the gun there

pnkfelix (Jun 04 2020 at 14:03, on Zulip):

I'll wait to let other people add announcements before I proceed further

davidtwco (Jun 04 2020 at 14:03, on Zulip):

Quick question: What does seconding a meeting proposal entail?

pnkfelix (Jun 04 2020 at 14:04, on Zulip):

that bullet with "seconding" is about major change proposals

davidtwco (Jun 04 2020 at 14:04, on Zulip):

(and do full team members do that, or contributor members also)

pnkfelix (Jun 04 2020 at 14:04, on Zulip):

meeting proposals are just about the weekly steering (design) meetings, which we decide about whether we will or will not hold them during the planning meeting (which we have tomorrow, Friday)

nikomatsakis (Jun 04 2020 at 14:04, on Zulip):

I am trying to remember what language we settled on :) I think contributors can do so also

simulacrum (Jun 04 2020 at 14:05, on Zulip):

/me has seconded one proposal at least

nikomatsakis (Jun 04 2020 at 14:05, on Zulip):

I think the idea was "experts in the area"

davidtwco (Jun 04 2020 at 14:05, on Zulip):

I understand what the meeting proposals are for, just not what the expectations on someone who seconds a proposal are.

pnkfelix (Jun 04 2020 at 14:05, on Zulip):

@davidtwco but my point is that people do not second meeting proposals at all

nikomatsakis (Jun 04 2020 at 14:05, on Zulip):

I don't think we really even said anything about "formal rules" for who can do it beyond that, we figured the FCP etc would take care of it (and anything irreversible requires check-off from team anyway) (edit: corrected, see below)

pnkfelix (Jun 04 2020 at 14:06, on Zulip):

they second MCP's. But part of my issue is that maybe you are talking about MCP's but saying "meeting" here, @davidtwco ?

davidtwco (Jun 04 2020 at 14:06, on Zulip):

pnkfelix said:

they second MCP's. But part of my issue is that maybe you are talking about MCP's but saying "meeting" here, davidtwco ?

yeah, sorry - I mean MCP; :face_palm:

pnkfelix (Jun 04 2020 at 14:06, on Zulip):

ah okay

pnkfelix (Jun 04 2020 at 14:06, on Zulip):

the language of rfc#2904 should specify this

nikomatsakis (Jun 04 2020 at 14:07, on Zulip):

A second, a member of the compiler team or a contributor who approves of the idea, but is not the one originating the proposal.

nikomatsakis (Jun 04 2020 at 14:07, on Zulip):

that's what we wrote in the RFC

pnkfelix (Jun 04 2020 at 14:08, on Zulip):

yeah I think all it means is "I think this is a good idea" including approval of the design as specified

pnkfelix (Jun 04 2020 at 14:08, on Zulip):

it doesn't mean you are agreeing to take on review duties or implementation duties

davidtwco (Jun 04 2020 at 14:08, on Zulip):

alright, that makes sense, thanks! sorry for the slight derailing

pnkfelix (Jun 04 2020 at 14:08, on Zulip):

no that's fine, its important to get these things clarified

pnkfelix (Jun 04 2020 at 14:09, on Zulip):

okay so I think we can move on with the agenda then

pnkfelix (Jun 04 2020 at 14:10, on Zulip):

as already mentioned, there are no backport nominations (which is normal for a release week. :smiley: )

pnkfelix (Jun 04 2020 at 14:10, on Zulip):

PR's S-waiting-on-team

T-compiler S-waiting-on-team

pnkfelix (Jun 04 2020 at 14:10, on Zulip):
pnkfelix (Jun 04 2020 at 14:11, on Zulip):

(i just checked off my box)

nikomatsakis (Jun 04 2020 at 14:12, on Zulip):

(I would have said it is "in pre-fcp", but I also just checked my box)

pnkfelix (Jun 04 2020 at 14:12, on Zulip):

there's some discussion of security leakage of sensitive data

pnkfelix (Jun 04 2020 at 14:12, on Zulip):

but the change here would solely add such info to .d (depinfo) files, right?

pnkfelix (Jun 04 2020 at 14:13, on Zulip):

such things are not typically distributed beyond a developer's build machine, are they?

pnkfelix (Jun 04 2020 at 14:13, on Zulip):

anyway that was just something that struck me while I reviewed.

nikomatsakis (Jun 04 2020 at 14:13, on Zulip):

I don't think so

pnkfelix (Jun 04 2020 at 14:14, on Zulip):

it seems like a very strange attack vector, in any case

eddyb (Jun 04 2020 at 14:14, on Zulip):

yeah and it's only env vars accessed by env!, so they would show up in incremental caches too (well, no, we don't cache HIR yet. but likely MIR), and likely in the artifacts as well

pnkfelix (Jun 04 2020 at 14:14, on Zulip):

Yeah I suspect that was the point @Vadim Petrochenkov was making in their comment: that if there's leakage that way, its probably already present

pnkfelix (Jun 04 2020 at 14:14, on Zulip):

in ways that are far more problematic

pnkfelix (Jun 04 2020 at 14:15, on Zulip):

okay so what else is waiting on team

pnkfelix (Jun 04 2020 at 14:15, on Zulip):
eddyb (Jun 04 2020 at 14:16, on Zulip):

oh I didn't nominate it

eddyb (Jun 04 2020 at 14:16, on Zulip):

(I thought I did then forgot about it)

pnkfelix (Jun 04 2020 at 14:16, on Zulip):

I cut-and-pasted from the agenda

pnkfelix (Jun 04 2020 at 14:16, on Zulip):

but was that supposed to be "should take this patch" , instead of "shouldn't" ?

eddyb (Jun 04 2020 at 14:16, on Zulip):

no, I don't think we should land this

eddyb (Jun 04 2020 at 14:16, on Zulip):

but I was hoping for some discussion on the PR itself, instead of making an unilateral decision

pnkfelix (Jun 04 2020 at 14:17, on Zulip):

maybe I misunderstand what the goal of the PR is

pnkfelix (Jun 04 2020 at 14:17, on Zulip):

ah okay

pnkfelix (Jun 04 2020 at 14:17, on Zulip):

the person writing it is doing so because zero-length arrays are disallowed by SPIR-V

eddyb (Jun 04 2020 at 14:17, on Zulip):

it complicates codegen by removing a trick I added a long time ago

pnkfelix (Jun 04 2020 at 14:17, on Zulip):

so this would be a prerequisite to supporting SPIR-V. But @eddyb is saying that is not a good motivation

pnkfelix (Jun 04 2020 at 14:17, on Zulip):

what about it speeding up the compiler?

eddyb (Jun 04 2020 at 14:18, on Zulip):

do we have numbers showing it does?

oli (Jun 04 2020 at 14:18, on Zulip):

https://perf.rust-lang.org/compare.html?start=94fccccd2cdba42aed93ad7715e969ab6aad6301&end=d839ad4507180aa47a451a273cb3f1a1ba653c80

pnkfelix (Jun 04 2020 at 14:18, on Zulip):

@ecstatic-morse claimed it did in comment thread

pnkfelix (Jun 04 2020 at 14:18, on Zulip):

(slight win)

eddyb (Jun 04 2020 at 14:18, on Zulip):

huh did I miss it

nikomatsakis (Jun 04 2020 at 14:18, on Zulip):

basically @eddyb your argument is that this makes the code more complex and the goal (supporting SPIR-V) is too complex and will never be reached?

pnkfelix (Jun 04 2020 at 14:18, on Zulip):

here

Wesley Wiser (Jun 04 2020 at 14:18, on Zulip):

Well there's a few small wins and a moderate loss

eddyb (Jun 04 2020 at 14:18, on Zulip):

at a glance I don't even see the wins. maybe one

Wesley Wiser (Jun 04 2020 at 14:19, on Zulip):

I don't find the perf compelling enough to be a consideration for landing this (personally).

eddyb (Jun 04 2020 at 14:19, on Zulip):

SPIR-V doesn't seem plausible to me but I only have second-hand experience

eddyb (Jun 04 2020 at 14:19, on Zulip):

from someone building a MIR -> SPIR-V backend

pnkfelix (Jun 04 2020 at 14:19, on Zulip):

yeah okay I tend to agree that the performance wins shown here don't seem significant enough to justify overall complication

eddyb (Jun 04 2020 at 14:19, on Zulip):

it requires more bookkeeping on our side to generate, so it's not a simple win even if LLVM handles it better

davidtwco (Jun 04 2020 at 14:19, on Zulip):

I've worked with SPIR-V at $dayjob; there are compilers for subsets of C++/C to SPIR-V for targetting GPUs; it's probably plausible for a subset of Rust also.

nikomatsakis (Jun 04 2020 at 14:20, on Zulip):

that would be my take too -- I don't get why it's not possible for some subset of Rust

pnkfelix (Jun 04 2020 at 14:20, on Zulip):

@eddyb would you prefer that we put this through an rfcbot poll with disposition to close, so that people get chance to chime in outside of this meeting?

eddyb (Jun 04 2020 at 14:20, on Zulip):

yeah I expected discussion on the PR, which is why I didn't nominate it

oli (Jun 04 2020 at 14:20, on Zulip):

but that sounds like a different discussion. We can figure out SPIR-V independently of this and revisit when there's an overall plan

nikomatsakis (Jun 04 2020 at 14:20, on Zulip):

but I am willing to believe that we should try to sketch out what kind of actual SPIR-V support we want before just complicating the codebase

nikomatsakis (Jun 04 2020 at 14:21, on Zulip):

what @oli said, basically

eddyb (Jun 04 2020 at 14:21, on Zulip):

idk what @MaikKlein does these days, they are the author of that MIR -> SPIR-V backend I was mentioning, I was hoping they would chime in

pnkfelix (Jun 04 2020 at 14:21, on Zulip):

okay then. Lets treat it that way then.

Wesley Wiser (Jun 04 2020 at 14:21, on Zulip):

Perhaps we should ask for a MCP regarding the overall plan for SPIR-V support?

Wesley Wiser (Jun 04 2020 at 14:21, on Zulip):

As it would be a new target essentially

pnkfelix (Jun 04 2020 at 14:21, on Zulip):

I think we can unilaterally close with an explanation that we'd need a broader discussion (or at least MCP) of how we would go about supporting SPIR-V

nikomatsakis (Jun 04 2020 at 14:21, on Zulip):

seems like it might be beyond an MCP -- but that's a good start

pnkfelix (Jun 04 2020 at 14:21, on Zulip):

yeah it may be MCP or it may be RFC

nikomatsakis (Jun 04 2020 at 14:21, on Zulip):

I guess it all depends on our goals...

eddyb (Jun 04 2020 at 14:22, on Zulip):

frankly they should just fix ZSTs in LLVM, seems easier if they want to play around with the unlikely MIR -> LLVM -> SPIR-V route

nikomatsakis (Jun 04 2020 at 14:22, on Zulip):

(I was wondering about that too :)

pnkfelix (Jun 04 2020 at 14:22, on Zulip):

I don't know who "they" is here

eddyb (Jun 04 2020 at 14:22, on Zulip):

the author of the PR

eddyb (Jun 04 2020 at 14:22, on Zulip):

the ideal situation is LLVM wouldn't have struct types, they're only a very weird way to describe offsets

pnkfelix (Jun 04 2020 at 14:22, on Zulip):

but I can understand someone preferring to focus on a change on the rustc side

eddyb (Jun 04 2020 at 14:22, on Zulip):

I doubt the LLVM change would be as big

pnkfelix (Jun 04 2020 at 14:22, on Zulip):

anyway

davidtwco (Jun 04 2020 at 14:23, on Zulip):

There's no upstream SPIR-V backend for LLVM either, there's a LLVM-to-SPIRV converter by Khronos and there's a work-in-progress backend by folks at ARM, as I understand it.

pnkfelix (Jun 04 2020 at 14:23, on Zulip):

we can move along I think

eddyb (Jun 04 2020 at 14:23, on Zulip):

@davidtwco oh that makes this even more dubious

pnkfelix (Jun 04 2020 at 14:23, on Zulip):

and perhaps open a zulip topic for this, or discuss it on PR itself.

eddyb (Jun 04 2020 at 14:23, on Zulip):

I assumed they were talking about an official SPIR-V backend

pnkfelix (Jun 04 2020 at 14:23, on Zulip):
davidtwco (Jun 04 2020 at 14:23, on Zulip):

(things might have changed since I last looked)

pnkfelix (Jun 04 2020 at 14:24, on Zulip):

(I'll assign #72541 to myself with intent to write a comment linking to and summarizing this meeting and then closing.)

eddyb (Jun 04 2020 at 14:25, on Zulip):

oh this is cool, although top-level flags aren't great. I guess -L and --extern being top-level is the problem precedent here

nikomatsakis (Jun 04 2020 at 14:25, on Zulip):

This is an external change so it requires team check-off

nikomatsakis (Jun 04 2020 at 14:25, on Zulip):

I'm in favor of solving this problem, at least..

pnkfelix (Jun 04 2020 at 14:25, on Zulip):

does it require more than an rfcbot checkoff here?

nikomatsakis (Jun 04 2020 at 14:25, on Zulip):

I think we should request a write-up

nikomatsakis (Jun 04 2020 at 14:25, on Zulip):

no, rfcbot checkoff suffices

eddyb (Jun 04 2020 at 14:25, on Zulip):

I don't see a comment mentioning requiring -Z unstable-options

nikomatsakis (Jun 04 2020 at 14:26, on Zulip):

that said

nikomatsakis (Jun 04 2020 at 14:26, on Zulip):

so this is sort of the grey area in my mind where an MCP would be useful, but we need more than a second

nikomatsakis (Jun 04 2020 at 14:26, on Zulip):

in particular, e.g. petrochenkov raised a number of design questions etc

nikomatsakis (Jun 04 2020 at 14:26, on Zulip):

I think we should document what the option does and some of those considerations

nikomatsakis (Jun 04 2020 at 14:26, on Zulip):

(and make sure to update the rustc user's guide etc)

nikomatsakis (Jun 04 2020 at 14:27, on Zulip):

it doesn't have to be an MCP necessarily but I think it's a useful mechanism to separate out the design discussion from the PR itself

nikomatsakis (Jun 04 2020 at 14:27, on Zulip):

I don't know that an RFC is required, it seems kind of like an internal cargo-rustc interface that wider users won't be that concerned about?

nikomatsakis (Jun 04 2020 at 14:28, on Zulip):

anyway I don't care too much as long as we end up with some notes on what we did and why and documentation :)

pnkfelix (Jun 04 2020 at 14:28, on Zulip):

yeah I'm struggling to decide what to suggest here

pnkfelix (Jun 04 2020 at 14:28, on Zulip):

i.e. will asking for an MCP help?

pnkfelix (Jun 04 2020 at 14:28, on Zulip):

or just saying "we expect some additional changes", which wouldn't even have to go into this PR necessarily?

pnkfelix (Jun 04 2020 at 14:29, on Zulip):

so maybe even just opening a tracking issue with follow-up tasks?

pnkfelix (Jun 04 2020 at 14:29, on Zulip):

and a zulip thread to try to focus discussion, maybe?

nikomatsakis (Jun 04 2020 at 14:29, on Zulip):

Personally I lean towards: keep our lives simple and say "yes make an MCP", and then we can rfcbot fcp merge on the MCP. In this way, an MCP is just our way of saying "a write-up of what we plan to do".

pnkfelix (Jun 04 2020 at 14:29, on Zulip):

will that loop in the cargo team?

pnkfelix (Jun 04 2020 at 14:29, on Zulip):

(or rather, can it loop in the cargo team?)

nikomatsakis (Jun 04 2020 at 14:30, on Zulip):

pnkfelix said:

so maybe even just opening a tracking issue with follow-up tasks?

I would expect a tracking issue , presuming it starts off as unstable

pnkfelix (Jun 04 2020 at 14:30, on Zulip):

okay

nikomatsakis (Jun 04 2020 at 14:30, on Zulip):

do we have a checklist for "so you want to add a new option"

nikomatsakis (Jun 04 2020 at 14:30, on Zulip):

I remember I started making one

nikomatsakis (Jun 04 2020 at 14:30, on Zulip):

not sure if I put it in forge

nikomatsakis (Jun 04 2020 at 14:30, on Zulip):

if not, let's write one and put it in forge so we can just point at that

pnkfelix (Jun 04 2020 at 14:31, on Zulip):

I guess we'll request an MCP. Can someone take point on this?

nikomatsakis (Jun 04 2020 at 14:31, on Zulip):

I'll do it

pnkfelix (Jun 04 2020 at 14:31, on Zulip):

okay. I'll assign to you

pnkfelix (Jun 04 2020 at 14:32, on Zulip):

No libs-impl S-waiting-on-team.

pnkfelix (Jun 04 2020 at 14:32, on Zulip):

Issues of Note

Short Summary

There is one less P-critical issues and 3 less P-high issues in comparison with last week.

pnkfelix (Jun 04 2020 at 14:32, on Zulip):

P-critical

pnkfelix (Jun 04 2020 at 14:32, on Zulip):
pnkfelix (Jun 04 2020 at 14:33, on Zulip):

I think it is indeed time to land PR #71896

Santiago Pastorino (Jun 04 2020 at 14:33, on Zulip):

about this one and the next P-critical if we merge the PR those are gone

Santiago Pastorino (Jun 04 2020 at 14:33, on Zulip):

@nikomatsakis should we merge now?

nikomatsakis (Jun 04 2020 at 14:34, on Zulip):

I believe so

pnkfelix (Jun 04 2020 at 14:34, on Zulip):
nikomatsakis (Jun 04 2020 at 14:34, on Zulip):

The only question in my mind is whether we should do any more outreach to affected crates

nikomatsakis (Jun 04 2020 at 14:34, on Zulip):

I think we should land the PR in any case and maybe we can ping the authors or prepare PRs, whichever

nikomatsakis (Jun 04 2020 at 14:34, on Zulip):

at least one crate author reached out anyhow

Santiago Pastorino (Jun 04 2020 at 14:35, on Zulip):

yeah :+1:

pnkfelix (Jun 04 2020 at 14:35, on Zulip):

okay then, moving on

Santiago Pastorino (Jun 04 2020 at 14:35, on Zulip):

in any case, we should keep on eye on the affected crates

pnkfelix (Jun 04 2020 at 14:35, on Zulip):
Santiago Pastorino (Jun 04 2020 at 14:35, on Zulip):

Santiago Pastorino said:

in any case, we should keep on eye on the affected crates

or provide a solution to them

pnkfelix (Jun 04 2020 at 14:36, on Zulip):

I didn't follow through on reverting PR #71840 yet

pnkfelix (Jun 04 2020 at 14:36, on Zulip):

@simulacrum , has the next beta been cut yet?

simulacrum (Jun 04 2020 at 14:36, on Zulip):

yes

simulacrum (Jun 04 2020 at 14:36, on Zulip):

all cuts have happened

pnkfelix (Jun 04 2020 at 14:36, on Zulip):

okay. So I'll need to make a backport of the revert

pnkfelix (Jun 04 2020 at 14:36, on Zulip):

that's fine, it was my fault for letting this slide too long

pnkfelix (Jun 04 2020 at 14:36, on Zulip):

moving on

pnkfelix (Jun 04 2020 at 14:37, on Zulip):
pnkfelix (Jun 04 2020 at 14:37, on Zulip):

this has a PR that will close it

lcnr (Jun 04 2020 at 14:37, on Zulip):

fixed by https://github.com/rust-lang/rust/pull/72897

pnkfelix (Jun 04 2020 at 14:37, on Zulip):

speaking of things that have PR's

pnkfelix (Jun 04 2020 at 14:37, on Zulip):

the @WG-prioritization was discussing whether we should add an explicit label like "has-pr"

pnkfelix (Jun 04 2020 at 14:38, on Zulip):

so that you'd see, e.g. in the github metadata in issue list pages, which issues have been explicitly noted as having a PR to fix them

nikomatsakis (Jun 04 2020 at 14:38, on Zulip):

I feel like GH shows this

nikomatsakis (Jun 04 2020 at 14:38, on Zulip):

but maybe it's a bit harder to see

pnkfelix (Jun 04 2020 at 14:39, on Zulip):

right now, you need to scroll through the comment thread to find the link to an associated PR, hopefully with the text "xxx linked a pull request that will close this issue 3 days ago "

Santiago Pastorino (Jun 04 2020 at 14:39, on Zulip):

I'm not sure if a like a lot the idea although I see that it fixes some use cases but what I will do for sure is add some meta data in our listings

pnkfelix (Jun 04 2020 at 14:39, on Zulip):

its in the comment thread, but is it in the metadata you see from other points, @nikomatsakis ?

nikomatsakis (Jun 04 2020 at 14:39, on Zulip):

when you click on the issue at least

pnkfelix (Jun 04 2020 at 14:39, on Zulip):

namely https://github.com/rust-lang/rust/issues/

nikomatsakis (Jun 04 2020 at 14:39, on Zulip):

there are some notes at the top I believe

pnkfelix (Jun 04 2020 at 14:39, on Zulip):

that's the place I want to see it

nikomatsakis (Jun 04 2020 at 14:39, on Zulip):

but maybe not in the issue listing before you click

pnkfelix (Jun 04 2020 at 14:40, on Zulip):

ah you are right, there is the "may be fixed by #nnnnnn"

pnkfelix (Jun 04 2020 at 14:40, on Zulip):

at the top. I think that's relatively new

pnkfelix (Jun 04 2020 at 14:40, on Zulip):

but its not in the issue list

pnkfelix (Jun 04 2020 at 14:40, on Zulip):

hmm

Wesley Wiser (Jun 04 2020 at 14:40, on Zulip):

What do you mean by "not in the issue list"?

nikomatsakis (Jun 04 2020 at 14:40, on Zulip):

image.png

Santiago Pastorino (Jun 04 2020 at 14:40, on Zulip):

Santiago Pastorino said:

I'm not sure if a like a lot the idea although I see that it fixes some use cases but what I will do for sure is add some meta data in our listings

by this I meant, going to add some text in out automation

pnkfelix (Jun 04 2020 at 14:40, on Zulip):

@Wesley Wiser here is an issue list: https://github.com/rust-lang/rust/issues/

Wesley Wiser (Jun 04 2020 at 14:40, on Zulip):

image.png

pnkfelix (Jun 04 2020 at 14:40, on Zulip):

it shows issues, and it includes tags

Santiago Pastorino (Jun 04 2020 at 14:41, on Zulip):

Wesley Wiser said:

image.png

that means that there's a PR that closes the issue?

pnkfelix (Jun 04 2020 at 14:41, on Zulip):

those are linked pull requests ... does that include mentions?

nikomatsakis (Jun 04 2020 at 14:41, on Zulip):

image.png

Wesley Wiser (Jun 04 2020 at 14:41, on Zulip):

It means there's a "linked" PR that may close the issue

nikomatsakis (Jun 04 2020 at 14:41, on Zulip):

@pnkfelix like that?

pnkfelix (Jun 04 2020 at 14:41, on Zulip):

or does it solely include the PR's that say "fix Foo" ?

pnkfelix (Jun 04 2020 at 14:41, on Zulip):

the phrasing "linked PR's" worries me a little

pnkfelix (Jun 04 2020 at 14:42, on Zulip):

in terms of whether it may overcount

Wesley Wiser (Jun 04 2020 at 14:42, on Zulip):

I believe it's just "fixes or closes #foo"

pnkfelix (Jun 04 2020 at 14:42, on Zulip):

but okay, its better than what It thought was there

nikomatsakis (Jun 04 2020 at 14:42, on Zulip):

oh I see Wesley Wiser beat me :)

pnkfelix (Jun 04 2020 at 14:42, on Zulip):

Okay then, I'll stop promoting a "has-pr" tag label then

Wesley Wiser (Jun 04 2020 at 14:43, on Zulip):

I'm not 100% sure but I can't find any counter examples in our issue list

pnkfelix (Jun 04 2020 at 14:43, on Zulip):

okay then

pnkfelix (Jun 04 2020 at 14:43, on Zulip):

lets move along

pnkfelix (Jun 04 2020 at 14:43, on Zulip):

Unassigned P-high regressions

There are no unassigned P-high regressions.

pnkfelix (Jun 04 2020 at 14:43, on Zulip):

Performance logs

Triage done by njn

Regressions

Improvements

Santiago Pastorino (Jun 04 2020 at 14:44, on Zulip):

image.png

Santiago Pastorino (Jun 04 2020 at 14:44, on Zulip):

counter example, #16514

pnkfelix (Jun 04 2020 at 14:45, on Zulip):

@WG-prioritization it might be good to link directly to the triage comments from this summary. E.g. in the Rollup PR, it would be good to link to nnethercote's comment here

Santiago Pastorino (Jun 04 2020 at 14:46, on Zulip):

not sure what you meant, the summary is just a copy and paste of what Nicholas Nethercote has done, but we can discuss this on #t-compiler/wg-prioritization, to avoid noise here I guess

pnkfelix (Jun 04 2020 at 14:46, on Zulip):

I'm just sayign that the summary as given

pnkfelix (Jun 04 2020 at 14:47, on Zulip):

its still hard to find the performance triage results

pnkfelix (Jun 04 2020 at 14:47, on Zulip):

like, it links to the identified PR's, and maybe that suffices since the triage comment will tend to be at the end of the PR

pnkfelix (Jun 04 2020 at 14:47, on Zulip):

but it wasn't obvious to me where I should be looking to find out what the supposed perf wins are

pnkfelix (Jun 04 2020 at 14:48, on Zulip):

anyway I don't think there's anything we need to discuss regarding performance for now

pnkfelix (Jun 04 2020 at 14:48, on Zulip):

okay, 12 minutes left and now getting to nominated issues ...

pnkfelix (Jun 04 2020 at 14:48, on Zulip):

Nominated Issues

T-compiler I-nominated

pnkfelix (Jun 04 2020 at 14:49, on Zulip):
pnkfelix (Jun 04 2020 at 14:49, on Zulip):

there's a zulip topic about this somewhere that @RalfJ was asking how to make progress here

oli (Jun 04 2020 at 14:50, on Zulip):

https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Tag.2Fniche.20terminology.20cleanup.20%28.2372497%29/near/199375861

pnkfelix (Jun 04 2020 at 14:51, on Zulip):

My attitude is that the proposed change seems like a good thing, and something I think the team already had agreed upon.

eddyb (Jun 04 2020 at 14:51, on Zulip):

I haven't seen that topic, but the gist of this is making "tag" be able to mean "niche" as well

eddyb (Jun 04 2020 at 14:51, on Zulip):

as opposed to only an integer containing the same values as the "discriminant"

pnkfelix (Jun 04 2020 at 14:52, on Zulip):

right, and the way you distinguish between niche and non-niche is by talking about the "tag encoding"

pnkfelix (Jun 04 2020 at 14:52, on Zulip):

right?

eddyb (Jun 04 2020 at 14:52, on Zulip):

yeah

pnkfelix (Jun 04 2020 at 14:52, on Zulip):

anyway this is everyone's chance to object

pnkfelix (Jun 04 2020 at 14:53, on Zulip):

If you do object, please speak up on the PR

Wesley Wiser (Jun 04 2020 at 14:53, on Zulip):

It seems this improves our terminology over the status quo even if it isn't 100% perfect so :+1: from me.

pnkfelix (Jun 04 2020 at 14:53, on Zulip):

next up

pnkfelix (Jun 04 2020 at 14:53, on Zulip):
pnkfelix (Jun 04 2020 at 14:53, on Zulip):

we already discussed this PR above

pnkfelix (Jun 04 2020 at 14:53, on Zulip):

and then

pnkfelix (Jun 04 2020 at 14:53, on Zulip):
pnkfelix (Jun 04 2020 at 14:53, on Zulip):

same here

pnkfelix (Jun 04 2020 at 14:54, on Zulip):
nikomatsakis (Jun 04 2020 at 14:55, on Zulip):

I left a comment at the end with my memory here

nikomatsakis (Jun 04 2020 at 14:56, on Zulip):

In particular, the current setup (iiuc) is that if you have a function like

fn foo<T>(t: T)

then the corresponding FnDef type is covariant w/r/t T

nikomatsakis (Jun 04 2020 at 14:56, on Zulip):

this is inferred from the signature

nikomatsakis (Jun 04 2020 at 14:56, on Zulip):

I think this was done because it reduced errors (and it .. kind of makes sense)

nikomatsakis (Jun 04 2020 at 14:56, on Zulip):

But I guess it's inducing a cycle ?

nikomatsakis (Jun 04 2020 at 14:57, on Zulip):

We could make them invariant but I think that's going to break some code, maybe? Maybe not.

eddyb (Jun 04 2020 at 14:57, on Zulip):

note that this is only when writing -> _, or -> Vec<_>, that sort of thing, with a literal _

nikomatsakis (Jun 04 2020 at 14:58, on Zulip):

the cycle, you mean?

eddyb (Jun 04 2020 at 14:58, on Zulip):

right. otherwise the assumption that fn_sig is "cycle-free" should hold

nikomatsakis (Jun 04 2020 at 14:58, on Zulip):

I wasn't even aware you could write that, tbh :)

eddyb (Jun 04 2020 at 14:58, on Zulip):

it always errors, telling you the inferred type

nikomatsakis (Jun 04 2020 at 14:58, on Zulip):

yeah ok

nikomatsakis (Jun 04 2020 at 14:58, on Zulip):

I can see why it'd be useful, I usually just do -> () for that ...

eddyb (Jun 04 2020 at 14:59, on Zulip):

it also lets callers use the inferred type

pnkfelix (Jun 04 2020 at 14:59, on Zulip):

I think this doesn't need team discussion

eddyb (Jun 04 2020 at 14:59, on Zulip):

anyway I don't know if I can spend time right now trying out the variance thing

pnkfelix (Jun 04 2020 at 14:59, on Zulip):

or at least

pnkfelix (Jun 04 2020 at 14:59, on Zulip):

it doesn't need team discussion yet

pnkfelix (Jun 04 2020 at 14:59, on Zulip):

until we have a concrete proposal we're trying o evaluate?

pnkfelix (Jun 04 2020 at 14:59, on Zulip):

but ah, if @eddyb does not have time to investigate

pnkfelix (Jun 04 2020 at 15:00, on Zulip):

then maybe we need to reassign?

nikomatsakis (Jun 04 2020 at 15:00, on Zulip):

well it doesn't seem like a very burning issue

eddyb (Jun 04 2020 at 15:00, on Zulip):

yeah I was gonna say this is very low priority

eddyb (Jun 04 2020 at 15:00, on Zulip):

someone hit this accidentally and they happened to ping me

pnkfelix (Jun 04 2020 at 15:00, on Zulip):

okay

eddyb (Jun 04 2020 at 15:00, on Zulip):

took us ages to even see the _

pnkfelix (Jun 04 2020 at 15:00, on Zulip):

libs-impl I-nominated

pnkfelix (Jun 04 2020 at 15:01, on Zulip):

do we know if this is a regression?

pnkfelix (Jun 04 2020 at 15:01, on Zulip):

(it certainly seems like a bug; just curious about whether it was injected recently or not)

nikomatsakis (Jun 04 2020 at 15:02, on Zulip):

it looks like there is a discussion on Feb 8 diagnosing the problem

pnkfelix (Jun 04 2020 at 15:02, on Zulip):

anyway we are out of time; I'm going to leave it nominated.

nikomatsakis (Jun 04 2020 at 15:02, on Zulip):

so if it's a regression it's pretty old

pnkfelix (Jun 04 2020 at 15:02, on Zulip):

true

Santiago Pastorino (Jun 04 2020 at 15:02, on Zulip):

we don't know if it's a regression but if it is , is stable to stable ... right what Niko have said

pnkfelix (Jun 04 2020 at 15:03, on Zulip):

WG checkins

pnkfelix (Jun 04 2020 at 15:03, on Zulip):

@T-compiler/WG-meta checkin by @nikomatsakis and @spastorino:

pnkfelix (Jun 04 2020 at 15:03, on Zulip):

oh that reminds me

pnkfelix (Jun 04 2020 at 15:03, on Zulip):

I'm creating a WG for incr-comp

pnkfelix (Jun 04 2020 at 15:04, on Zulip):

see compiler-team#299

nikomatsakis (Jun 04 2020 at 15:04, on Zulip):

One thing I want to note is that

pnkfelix (Jun 04 2020 at 15:04, on Zulip):

(and if you're interested in joining, send me a PM)

nikomatsakis (Jun 04 2020 at 15:04, on Zulip):

I would like to eventually have notify groups for all the targets, not just windows

nikomatsakis (Jun 04 2020 at 15:04, on Zulip):

if people have suggestions for a good ordering though let me know

nikomatsakis (Jun 04 2020 at 15:04, on Zulip):

I thought ARM was an obvious candidate

Santiago Pastorino (Jun 04 2020 at 15:05, on Zulip):

and we could even have for all the areas of the compiler too :)

pnkfelix (Jun 04 2020 at 15:05, on Zulip):

with the rename of ICE-breaker group to notify groups

nikomatsakis (Jun 04 2020 at 15:05, on Zulip):

yes, eventually

pnkfelix (Jun 04 2020 at 15:05, on Zulip):

has syntax for notifying them changed? I assume it has

nikomatsakis (Jun 04 2020 at 15:05, on Zulip):

not really, you still write @rustbot ping foo, but we should make @rustbot notify foo an alias...

Santiago Pastorino (Jun 04 2020 at 15:05, on Zulip):

we haven't land anything yet and I don't think we have cooked a PR for that

pnkfelix (Jun 04 2020 at 15:05, on Zulip):

hmm this is still here: https://rustc-dev-guide.rust-lang.org/ice-breaker/about.html

Santiago Pastorino (Jun 04 2020 at 15:05, on Zulip):

nikomatsakis said:

not really, you still write @rustbot ping foo, but we should make @rustbot notify foo an alias...

:+1:

pnkfelix (Jun 04 2020 at 15:05, on Zulip):

oh okay

nikomatsakis (Jun 04 2020 at 15:06, on Zulip):

somehow "ping group" sounded a little silly ;)

pnkfelix (Jun 04 2020 at 15:06, on Zulip):

so ... its not renaming the icebreaker part, but rather the "ping" changes to "notify" ?

pnkfelix (Jun 04 2020 at 15:06, on Zulip):

/me is confused

nikomatsakis (Jun 04 2020 at 15:06, on Zulip):

we didn't ladn the change to rustc-dev-guide yet I don't think

Santiago Pastorino (Jun 04 2020 at 15:06, on Zulip):

I think foo could have ICE Breaker something on the name, don't remember but still nobody uses the full name and aliases should work

pnkfelix (Jun 04 2020 at 15:06, on Zulip):

okay I guess I'll wait and see what happens

pnkfelix (Jun 04 2020 at 15:06, on Zulip):

@WG-mir-opt checkin by @oli:

Major things

Interesting snippets

pnkfelix (Jun 04 2020 at 15:07, on Zulip):

and with that, the meeting is over. Thanks to everyone in @T-compiler/meeting for attending! be well and stay safe everyone! :mask:

nikomatsakis (Jun 04 2020 at 15:07, on Zulip):

woah there's a lot in there

oli (Jun 04 2020 at 15:08, on Zulip):

yea... ppl have been busy XD

oli (Jun 04 2020 at 15:08, on Zulip):

and some more stuff is in the pipeline

eddyb (Jun 04 2020 at 15:09, on Zulip):

clearly the solution for mir-opt is for me to not be around :P

Wesley Wiser (Jun 04 2020 at 15:10, on Zulip):

That's definitely not true :slight_smile:

eddyb (Jun 04 2020 at 15:10, on Zulip):

what I mean is that I look away for a few weeks and this all happens, it's great :D

Wesley Wiser (Jun 04 2020 at 15:11, on Zulip):

Also, nudge nudge https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/VarDebugInfo.20using.20constants.20instead.20of.20locals/near/199613497

Wesley Wiser (Jun 04 2020 at 15:11, on Zulip):

Some brief feedback would be hugely appreciated!

mark-i-m (Jun 04 2020 at 16:30, on Zulip):

Question: why don't we do WG checkins at the beginning with the announcements? It seems like they don't take much time, but sometimes they get skipped by running out of time, like last week

Santiago Pastorino (Jun 04 2020 at 16:37, on Zulip):

@mark-i-m :+1:, I think it's a good idea

Santiago Pastorino (Jun 04 2020 at 16:38, on Zulip):

let's see what @pnkfelix prefers but if we prefer that kind of layout I can change the agenda template

pnkfelix (Jun 04 2020 at 18:27, on Zulip):

I guess my only misgiving is that I think the highest priority things should come first in the agenda

pnkfelix (Jun 04 2020 at 18:27, on Zulip):

(with the exception of "announcements", which are often not high priority at all, but more that it just makes sense to me to put those at the very beginning to get people excited about stuff that's happening.)

pnkfelix (Jun 04 2020 at 18:28, on Zulip):

but if we can be really good about limiting discussion of the WG checkin material to at most say 10 minutes then it should be fine to put it first I think... sort of analogous to announcements, its nice to have them there to get people excited about everything that's going on

mark-i-m (Jun 04 2020 at 18:48, on Zulip):

say 10 minutes

I would imagine it's much less than that... in fact, there's never really been more than 5 comments when I've done the WG-rustc-dev-guide checkin

Last update: Nov 25 2020 at 01:30UTC