Stream: t-compiler

Topic: #54818 weekly meeting 2019-02-21


pnkfelix (Feb 21 2019 at 14:17, on Zulip):

hi @T-compiler/meeting we'll be having our weekly meeting here in about 43 minutes

pnkfelix (Feb 21 2019 at 14:17, on Zulip):

in the meantime I'm going to do pretriage in this channel.

pnkfelix (Feb 21 2019 at 14:18, on Zulip):

first up, P-high issues

pnkfelix (Feb 21 2019 at 14:18, on Zulip):

first "ICE related to lifetimes and traits" #58451

pnkfelix (Feb 21 2019 at 14:18, on Zulip):

niko has PR #58592 to resolve this.

pnkfelix (Feb 21 2019 at 14:19, on Zulip):

next: "Compiler panic with associated constant" #58435

pnkfelix (Feb 21 2019 at 14:19, on Zulip):

I tagged this as P-high last week but failed to assign it to anyone.

pnkfelix (Feb 21 2019 at 14:19, on Zulip):

(its been fixed in nightly)

pnkfelix (Feb 21 2019 at 14:20, on Zulip):

so the question is whether we can identify the PR that fixed it (some bisection has already been done)

pnkfelix (Feb 21 2019 at 14:20, on Zulip):

I'll assign it to myself

pnkfelix (Feb 21 2019 at 14:21, on Zulip):

(to try to identify whether a backportable commit exists.)

pnkfelix (Feb 21 2019 at 14:21, on Zulip):

next: ""Cannot create local mono-item" ICE building cortex-m code on nightly" #58323

pnkfelix (Feb 21 2019 at 14:22, on Zulip):

looks like @mw and @nagisa have done good work here; @nagisa has PR #58605 up that is supposed to resolve it.

pnkfelix (Feb 21 2019 at 14:22, on Zulip):

oh but @mw says that PR doesn't do the trick yet (@mw made that comment on the PR itself)

pnkfelix (Feb 21 2019 at 14:23, on Zulip):

okay well in any case it looks like this is progressing fine

pnkfelix (Feb 21 2019 at 14:23, on Zulip):

next: "Compiler panics with std::mem::size_of" #58158

pnkfelix (Feb 21 2019 at 14:25, on Zulip):

seems like this is a long standing bug with #[repr(packed)]

pnkfelix (Feb 21 2019 at 14:26, on Zulip):

assigning to self for now, but if someone else is familiar with the wfcheck code, I invite you to steal the bug from me (by assigning yourself, that is.)

pnkfelix (Feb 21 2019 at 14:32, on Zulip):

next: "beta 1.33 seems to break tarpaulin on multithreading" #58104

pnkfelix (Feb 21 2019 at 14:34, on Zulip):

@nagisa has bisected the problem down to a PR #56837 injection. @Ariel Ben-Yehuda commented saying they would have to look into it.

pnkfelix (Feb 21 2019 at 14:34, on Zulip):

@Ariel Ben-Yehuda do you expect to actually be able to do so?

pnkfelix (Feb 21 2019 at 14:34, on Zulip):

I'm going to speculatively assign to @Ariel Ben-Yehuda for now, but you should unassign yourself if you do not expect to be able to investigate.

pnkfelix (Feb 21 2019 at 14:37, on Zulip):

next: "Regression from stable to nightly: nested impl trait is not allowed" #57979

pnkfelix (Feb 21 2019 at 14:37, on Zulip):

I've put up a PR sketching out the (relatively trivial) warning cycle code we could employ here, at PR #58608.

pnkfelix (Feb 21 2019 at 14:38, on Zulip):

and I've nominated that PR for discussion, so that the team can collectively decide whether a warning cycle is warranted here or not. So we'll talk about that once the meeting starts. In any case, I think things are well underway here.

pnkfelix (Feb 21 2019 at 14:38, on Zulip):

next: "ICE on nightly when dereferencing boxed Iterator trait object" #57673

pnkfelix (Feb 21 2019 at 14:39, on Zulip):

I think both of the fixes related to this issue have now landed on the beta channel.

pnkfelix (Feb 21 2019 at 14:40, on Zulip):

they landed 2 days ago, while the current playpen beta dates from 2019-02-16

pnkfelix (Feb 21 2019 at 14:40, on Zulip):

so its too soon to formally test on the playpen itself

pnkfelix (Feb 21 2019 at 14:40, on Zulip):

having said that, I'm pretty sure this is all set now, and am going to close the bug

pnkfelix (Feb 21 2019 at 14:41, on Zulip):

next: "Regression in trait bounds that are redundant with associated type's HRTB" #57639

pnkfelix (Feb 21 2019 at 14:42, on Zulip):

this is tagged as fixed by niko's PR #58592

pnkfelix (Feb 21 2019 at 14:43, on Zulip):

(and that PR is already beta-nominated so I don't need to add that tag.)

pnkfelix (Feb 21 2019 at 14:43, on Zulip):

so that seems in order. Moving along.

pnkfelix (Feb 21 2019 at 14:43, on Zulip):

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

pnkfelix (Feb 21 2019 at 14:43, on Zulip):

I'm looking at this. I've narrowed it down to a small test case, and am now analyzing the compiler's behavior on that test case.

pnkfelix (Feb 21 2019 at 14:44, on Zulip):

I think the bug is under control. Though I'd be happy if someone else wants to take over looking at it.

pnkfelix (Feb 21 2019 at 14:45, on Zulip):

the remaining P-high bugs are all tagged as NLL, so I won't go through them here.

pnkfelix (Feb 21 2019 at 14:45, on Zulip):

Okay!

pnkfelix (Feb 21 2019 at 14:45, on Zulip):

so that's the P-high bugs

pnkfelix (Feb 21 2019 at 14:46, on Zulip):

next, beta-nominations

pnkfelix (Feb 21 2019 at 14:46, on Zulip):

two of these are correctly tagged T-compiler. The others are correctly not tagged T-compiler.

pnkfelix (Feb 21 2019 at 14:47, on Zulip):

so first up: "Re-implement leak check in terms of universes" #58592

pnkfelix (Feb 21 2019 at 14:50, on Zulip):

Okay so, Pros and Cons ... Pro: This fixes a lot of issues.

pnkfelix (Feb 21 2019 at 14:51, on Zulip):

Pro: It is meant to give us more breathing room rather than prematurely commit to a new static semantics

pnkfelix (Feb 21 2019 at 14:51, on Zulip):

Con: It hasn't landed in master yet.

oli (Feb 21 2019 at 14:52, on Zulip):

it's very big for a backport

pnkfelix (Feb 21 2019 at 14:52, on Zulip):

yeah I debated about mentioning that

pnkfelix (Feb 21 2019 at 14:52, on Zulip):

I think much of it is just refactoring?

pnkfelix (Feb 21 2019 at 14:52, on Zulip):

e.g. alpha renaming

oli (Feb 21 2019 at 14:53, on Zulip):

will a backport right now go into the stable next week or into the stable in 6 weeks?

pnkfelix (Feb 21 2019 at 14:53, on Zulip):

based on the commit titles, I had assumed that this one was the most important commit to look at

lqd (Feb 21 2019 at 14:53, on Zulip):

isn't the alternative straight up reverting universes ?

pnkfelix (Feb 21 2019 at 14:53, on Zulip):

I was assuming that we were only talking about doing a backport to beta

pnkfelix (Feb 21 2019 at 14:53, on Zulip):

i.e. there aren't any stable-to-stable regressions here, right?

pnkfelix (Feb 21 2019 at 14:54, on Zulip):

isn't the alternative straight up reverting universes ?

that or living with bugs for a cycle

oli (Feb 21 2019 at 14:54, on Zulip):

no, I mean, the current beta becomes stable next week

Aaron Turon (Feb 21 2019 at 14:54, on Zulip):

the goal was to land on beta before it becomes stable

pnkfelix (Feb 21 2019 at 14:54, on Zulip):

right, my hope would be that if we beta-approve this, the backport would happen before the beta-to-stable rollover

pnkfelix (Feb 21 2019 at 14:55, on Zulip):

okay well the point is there is potential for contention here

oli (Feb 21 2019 at 14:55, on Zulip):

I mean, it's not much of a maintainance burden then. We could backport and then run crater on the beta and see if there's any fallout

pnkfelix (Feb 21 2019 at 14:55, on Zulip):

lets table further discussion of that issue until the meeting itself when everyone is here.

pnkfelix (Feb 21 2019 at 14:56, on Zulip):

the other beta-nominated issue for T-compiler is: "make generalization code create new variables in correct universe" #58056

pnkfelix (Feb 21 2019 at 14:57, on Zulip):

(as usual, I have put emojis on each of the messages for issues so that people can summarize their opinion by clicking the relevant emoji.)

pnkfelix (Feb 21 2019 at 14:58, on Zulip):

This one is also a little big. I don't know how to measure relative risk of either.

pnkfelix (Feb 21 2019 at 14:59, on Zulip):

the payoff (i.e. value proposition) of backporting PR #58056 seems lower than that of PR #58592

pnkfelix (Feb 21 2019 at 15:00, on Zulip):

that's all the beta-noms

pnkfelix (Feb 21 2019 at 15:00, on Zulip):

there aren't any T-compiler stable-nominations

pnkfelix (Feb 21 2019 at 15:00, on Zulip):

all the stable-to-beta regressions for T-compiler are already marked P-high (so we already touched on them)

pnkfelix (Feb 21 2019 at 15:01, on Zulip):

okay last pre-triage item: stable-to-nightly regressions

pnkfelix (Feb 21 2019 at 15:02, on Zulip):

I see three there that were filed in the last week that are not yet marked P-high.

pnkfelix (Feb 21 2019 at 15:02, on Zulip):

I'm going to go ahead and mark them all P-high right now. (Sometimes I think I'm doing this in the wrong order.)

nikomatsakis (Feb 21 2019 at 15:03, on Zulip):

Hey all

nikomatsakis (Feb 21 2019 at 15:03, on Zulip):

We gonna start the meeting proper?

pnkfelix (Feb 21 2019 at 15:03, on Zulip):

namely: "Nightly compiler 'inconsistent resolution for an import' for crate" #58499 is P-high and assigned to @Vadim Petrochenkov

pnkfelix (Feb 21 2019 at 15:03, on Zulip):

yeah Okay let me just jot down these other two so I can close the door on pretriage

pnkfelix (Feb 21 2019 at 15:04, on Zulip):

"fn generated by macro exported from crate loses global #![allow(non_snake_case)]" #58502 will be P-high once I tag it. it currently has no one assigned.

pnkfelix (Feb 21 2019 at 15:05, on Zulip):

"ICE on 1.34.0-nightly 865cb7010 2019-02-10" #58610 is similar: P-high, no one assigned yet.

pnkfelix (Feb 21 2019 at 15:05, on Zulip):

okay so that's all the pretriage then.

pnkfelix (Feb 21 2019 at 15:05, on Zulip):

so I think the main things we should cover post pretriage are the two beta-nominations.

pnkfelix (Feb 21 2019 at 15:06, on Zulip):

https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.2354818.20weekly.20meeting.202019-02-21/near/159072832

pnkfelix (Feb 21 2019 at 15:06, on Zulip):

and

pnkfelix (Feb 21 2019 at 15:06, on Zulip):

https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.2354818.20weekly.20meeting.202019-02-21/near/159073616

nikomatsakis (Feb 21 2019 at 15:06, on Zulip):

I figured we could also discuss them as part of the "trait WG sync"

nikomatsakis (Feb 21 2019 at 15:06, on Zulip):

Though I'm happy to do them first

pnkfelix (Feb 21 2019 at 15:06, on Zulip):

Okay that's fine with me

pnkfelix (Feb 21 2019 at 15:06, on Zulip):

lets delay talking about them in that case

nikomatsakis (Feb 21 2019 at 15:07, on Zulip):

At the moment, that's the biggest thing happening in the Trait WG =)

pnkfelix (Feb 21 2019 at 15:07, on Zulip):

there are two issues tagged with waiting-on-team for T-compiler

pnkfelix (Feb 21 2019 at 15:07, on Zulip):

but those two issues are also tagged I-nominated

pnkfelix (Feb 21 2019 at 15:07, on Zulip):

so maybe we can collectively quickly scan over the I-nominated issues

pnkfelix (Feb 21 2019 at 15:07, on Zulip):

(there are 12 of them)

nikomatsakis (Feb 21 2019 at 15:07, on Zulip):

Oh, that reminds me -- we've still not done a good job of working out how these "triage sync" meetings will work, right? But cc @WG-compiler-traits -- sorry for late notice -- but I expect we'll be doing our initial "Traits WG sync" during this meeting =)

pnkfelix (Feb 21 2019 at 15:07, on Zulip):

T-compiler I-nominated

pnkfelix (Feb 21 2019 at 15:08, on Zulip):

Oh, that reminds me -- we've still not done a good job of working out how these "triage sync" meetings will work, right?

My hope is to cut off triage stuff within the first 30min

pnkfelix (Feb 21 2019 at 15:08, on Zulip):

and then remaining time can be spent on WG checkin

nikomatsakis (Feb 21 2019 at 15:09, on Zulip):

Yeah mainly I meant that I had hoped to make some good announcements ahead of time about which groups etc etc but w'ell get that running more smoothly over time

pnkfelix (Feb 21 2019 at 15:09, on Zulip):

but maybe that wasn't what you had hoped for when you agreed to make the beta-nominations part of the WG-checkin ?

nikomatsakis (Feb 21 2019 at 15:09, on Zulip):

That seems fine, but I do think it's urgent that we talk about them. So long as we ensure that we have time for it, seems good

pnkfelix (Feb 21 2019 at 15:09, on Zulip):

so there are the two stable-to-nightly regressions I mentioned above that are unassigned. Those are I-nominated

nikomatsakis (Feb 21 2019 at 15:09, on Zulip):

Link?

pnkfelix (Feb 21 2019 at 15:10, on Zulip):

"fn generated by macro exported from crate loses global #![allow(non_snake_case)]" #58502 will be P-high once I tag it. it currently has no one assigned.

pnkfelix (Feb 21 2019 at 15:10, on Zulip):

"ICE on 1.34.0-nightly 865cb7010 2019-02-10" #58610 is similar: P-high, no one assigned yet.

pnkfelix (Feb 21 2019 at 15:10, on Zulip):

I don't want to take the time right now to attempt to assign them "properly"

pnkfelix (Feb 21 2019 at 15:10, on Zulip):

so I'll just ask people to assign themselves if they feel like it.

pnkfelix (Feb 21 2019 at 15:11, on Zulip):

I'm going to leave the I-nominated tags on them though until someone(s) does take their assignments.

pnkfelix (Feb 21 2019 at 15:11, on Zulip):

next nomination is from me: "Warning period for detecting nested impl trait" #58608

pnkfelix (Feb 21 2019 at 15:12, on Zulip):

its a PR to make e.g. pub fn foobar(_: impl Quux<Assoc=impl Foo<impl Bar>>) { ... } a warning cycle rather than jumping to hard error

pnkfelix (Feb 21 2019 at 15:12, on Zulip):

I basically wanted to take everyone's tempature on whether we should do this or not

pnkfelix (Feb 21 2019 at 15:13, on Zulip):

I added corresponding "land the 'plane'" and "stop no don't" emojis.

centril (Feb 21 2019 at 15:13, on Zulip):

n.b. @Zoxc's comment

As I said on the PR, it's fine to do this as a C-future-compat thing, but we should have timelines and not just "sometime" for these things in general

nikomatsakis (Feb 21 2019 at 15:13, on Zulip):

Do we know of any "major" regressions in this case?

pnkfelix (Feb 21 2019 at 15:13, on Zulip):

(it wouldn't land as-written. The PR would first be adjusted to add a proper future-compat lint.)

pnkfelix (Feb 21 2019 at 15:14, on Zulip):

Do we know of any "major" regressions in this case?

I don't know what "major" means. The fact that we have someone in the wild complaining about it jumping to error is what motivated me.

nikomatsakis (Feb 21 2019 at 15:14, on Zulip):

I agree with @centril that we need to do a better job triaging that stuff etc but I think it's an orthogonal issue (seems like a good thing for WG-meta to discuss)

centril (Feb 21 2019 at 15:14, on Zulip):

@nikomatsakis seems unlikely given flaky inference...?

nikomatsakis (Feb 21 2019 at 15:14, on Zulip):

I think what I mean is, have there been more complaints we know of?

nikomatsakis (Feb 21 2019 at 15:14, on Zulip):

Is it just a single crate?

pnkfelix (Feb 21 2019 at 15:14, on Zulip):

anyway, i don't think we even have to decide synchronously.

nikomatsakis (Feb 21 2019 at 15:15, on Zulip):

That said, I'm kind of fine either way. I think a warning period is probably the "right" thing to do. I'm mostly just trying to avoid undue effort.

pnkfelix (Feb 21 2019 at 15:15, on Zulip):

Is it just a single crate?

hmm, well, how long ago did the hard error land ...

nikomatsakis (Feb 21 2019 at 15:15, on Zulip):

I'll leave a few comments

pnkfelix (Feb 21 2019 at 15:16, on Zulip):

okay. next nomination is: "rustc 1.32.0 produces faulty wasm code" #58548

centril (Feb 21 2019 at 15:16, on Zulip):

(it's semi orthogonal... I think we should start with setting timelines now, not in the future)

pnkfelix (Feb 21 2019 at 15:16, on Zulip):

I probably need to pre-triage nominations from outside team ahead of meeting time; I'm not sure we need resolve this synchronously

pnkfelix (Feb 21 2019 at 15:17, on Zulip):

anyway it appears that its probably P-high. I'll tag it as such and move along.

pnkfelix (Feb 21 2019 at 15:18, on Zulip):

next: "Cosmetic improvements to comments" #58524

Vadim Petrochenkov (Feb 21 2019 at 15:18, on Zulip):

Yeah.
I'm sorry for nominating a "cosmetic changes" PR again, but I think something needs to be done with them.

Vadim Petrochenkov (Feb 21 2019 at 15:18, on Zulip):

My first goal is to close #58036 and #58524, and discourage similar PRs from appearing in the future.
Basically, I suggest treating them as we'd treat PRs manually formatting the codebase without having an analogue of https://github.com/rust-lang/rfcs/tree/master/style-guide.

Vadim Petrochenkov (Feb 21 2019 at 15:19, on Zulip):

Merging them would mean encouraging a bad practice and sending a wrong signal to the author.
I realize this is not too kind towards alexreg, since there's some sunk cost, but I still think that it's important enough to do.

Vadim Petrochenkov (Feb 21 2019 at 15:19, on Zulip):

On the other hand, if alexreg wants to maintain a style guide, then my second goal is to provide such opportunity via the proposed process.
The process would ensure that the style rules are documented somewhere, mostly automated and have consensus, thus resolving my concerns.

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

I think I agree with @Vadim Petrochenkov 's overall point here

pnkfelix (Feb 21 2019 at 15:20, on Zulip):

that its a bad idea to explicitly/implicitly encourage work along these lines without more structure in place

pnkfelix (Feb 21 2019 at 15:21, on Zulip):

its tough because obviously we don't want to discourage people who care about tasks like this.

pnkfelix (Feb 21 2019 at 15:21, on Zulip):

but I think the point remains that without a documented style, the whole thing is pretty subjective.

pnkfelix (Feb 21 2019 at 15:21, on Zulip):

should we perhaps plan to make a WG-rustc-coding-style?

nikomatsakis (Feb 21 2019 at 15:22, on Zulip):

I remain kind of nervous about this :)

pnkfelix (Feb 21 2019 at 15:22, on Zulip):

I remain kind of nervous about this :)

nervous about trying to codify style?

nikomatsakis (Feb 21 2019 at 15:22, on Zulip):

Yes.

nikomatsakis (Feb 21 2019 at 15:22, on Zulip):

I suppose that if we limited ourselves to automatable rules

nikomatsakis (Feb 21 2019 at 15:22, on Zulip):

I would feel a bit better

nikomatsakis (Feb 21 2019 at 15:22, on Zulip):

I may also be a curmudgeon :) I definitely like rustfmt and I See the analogy

mw (Feb 21 2019 at 15:23, on Zulip):

my gut feeling is to discourage any kind of "style improvements"

nikomatsakis (Feb 21 2019 at 15:23, on Zulip):

but overall I just don't want to (a) feel forced to follow rules I don't care for and (b) put more burden on others who are writing PRs to ffollow them

nikomatsakis (Feb 21 2019 at 15:23, on Zulip):

or perhaps another way to say it is, I'm more concerned with having more comments

davidtwco (Feb 21 2019 at 15:23, on Zulip):

Somewhat related and might interest some folks - I was watching a talk about Python core developers and they had some "good neighbour" guidelines that touched on this sort of topic - https://youtu.be/voXVTjwnn-U?t=1863 - e.g. "don't be a picture straightener"

nikomatsakis (Feb 21 2019 at 15:24, on Zulip):

That's interesting

Wesley Wiser (Feb 21 2019 at 15:24, on Zulip):

Taking PRs that only consist of "I ran rustfmt on file x.rs" seems ok to me. Anything beyond that seems too subjective to me

nikomatsakis (Feb 21 2019 at 15:24, on Zulip):

Well, so the point is, we could potentially develop a tool to apply said rules

nikomatsakis (Feb 21 2019 at 15:24, on Zulip):

And I guess I could get behind that

nikomatsakis (Feb 21 2019 at 15:24, on Zulip):

but it feels like a lot of energy that I would rather spend elsewhere

pnkfelix (Feb 21 2019 at 15:24, on Zulip):

So there are two points here: there's the big picture plan of what we would invest effort in (if anything). And there's the question about what to do with these specific PR's.

nikomatsakis (Feb 21 2019 at 15:24, on Zulip):

Last time we sort of agreed that we wouldn't forbid such PRs but also wouldn't encourage

centril (Feb 21 2019 at 15:25, on Zulip):

(I would just separate "style improvements" and splitting up functions and stuff since the latter is important work)

nikomatsakis (Feb 21 2019 at 15:25, on Zulip):

But I guess clearly there is dissatisfaction with this, which is the point...

oli (Feb 21 2019 at 15:26, on Zulip):

We also had limitations on what is allowed to go into them (aka anything that anyone has a complaint about will not be changed). I think a lot of the dissatisfaction is with that not having happened (or having happened not across the entire PRs)

Aaron Turon (Feb 21 2019 at 15:26, on Zulip):

But I guess clearly there is dissatisfaction with this, which is the point...

yeah this feels like a common pathology; we should try to either provide a clear path forward (e.g. working toward a policy), or make clear that we're not interested for the foreseeable future

Wesley Wiser (Feb 21 2019 at 15:26, on Zulip):

Instead of developing a separate tool or changing tidy, could we just ask that people get those changes upstreamed into rustfmt? Then we'd just have to run rustfmt on the code

Zoxc (Feb 21 2019 at 15:26, on Zulip):

I don't want any PRs which applies rustfmt, unless we do it with the whole codebase, block on rustfmt on PRs and have a tool to migrate prs over

oli (Feb 21 2019 at 15:26, on Zulip):

@Zoxc that's not feasible, you'd never get a full PR merged

centril (Feb 21 2019 at 15:27, on Zulip):

@oli treeclose

nikomatsakis (Feb 21 2019 at 15:27, on Zulip):

Let's leave rustfmt out of this

nikomatsakis (Feb 21 2019 at 15:27, on Zulip):

It's a separate question

nikomatsakis (Feb 21 2019 at 15:28, on Zulip):

I guess the options on the table are:

0. Status quo -- perhaps inadvisable
1. Adopt @Vadim Petrochenkov's proposal with automation
2. Officially discourage "purely style" changes to comments

pnkfelix (Feb 21 2019 at 15:29, on Zulip):

I dont think we're prepared to actually make a final decision here and now

nikomatsakis (Feb 21 2019 at 15:29, on Zulip):

To @centril's point, code refactoring feels distinct. I also think that "naming" PRs -- e.g., trying to adopt a single name for some concept that has multiple names -- is a valuable activity. But we're talking more about drive-by grammatical edits (that are not connected to other changes)

pnkfelix (Feb 21 2019 at 15:29, on Zulip):

e.g. I'd want to see more buy-in before we did "1. Adopt @Vadim Petrochenkov's proposal with automation"

nikomatsakis (Feb 21 2019 at 15:29, on Zulip):

I also was going to point out that this meeting doesn't feel like the proper place to make a decision

mw (Feb 21 2019 at 15:29, on Zulip):

I'm for 2. I've never run into a real problem caused by weirdly spelled/formulated comments

nikomatsakis (Feb 21 2019 at 15:30, on Zulip):

(I am also for 2, personally, I think that a whole style process feels like more effort than is warranted)

pnkfelix (Feb 21 2019 at 15:30, on Zulip):

What is the best way we could try to get consensus around this question?

oli (Feb 21 2019 at 15:30, on Zulip):

issue with FCP?

Wesley Wiser (Feb 21 2019 at 15:30, on Zulip):

Should we just take a non-binding strawpoll here? (To see if there's consensus)

nikomatsakis (Feb 21 2019 at 15:30, on Zulip):

I was going to propose issue with FCP. We could also discuss at a steering meeting in more depth but I don't see a lot of dissensus.

davidtwco (Feb 21 2019 at 15:31, on Zulip):

I also was going to point out that this meeting doesn't feel like the proper place to make a decision

I included a "best practices for contributing" section on wg-meta's unresolved questions with the intention that this sort of question could be resolved there (with the intent of documenting those practices for contributors). Unsure if people feel that is the correct place for this sort of discussion, not asserting that it is, it was just an idea that I had.

pnkfelix (Feb 21 2019 at 15:31, on Zulip):

Okay yes, lets first take quick strawpoll here

centril (Feb 21 2019 at 15:31, on Zulip):

(not my team, but 2. / 1. seems reasonable... except for 2. when it relates to the standard library doc-comments because that's not T-compiler stuff anyways...)

nikomatsakis (Feb 21 2019 at 15:31, on Zulip):

I was going to propose issue with FCP. We could also discuss at a steering meeting in more depth but I don't see a lot of dissensus.

to be clear, if you do disagree, feel free to speak up! :)

pnkfelix (Feb 21 2019 at 15:32, on Zulip):

I added emoji for each of the three options to https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.2354818.20weekly.20meeting.202019-02-21/near/159076379

centril (Feb 21 2019 at 15:32, on Zulip):

(should I participate in the strawpoll...?)

pnkfelix (Feb 21 2019 at 15:32, on Zulip):

(thanks @davidtwco for being the first to implicitly point out that the number emoijis exist)

nikomatsakis (Feb 21 2019 at 15:32, on Zulip):

I'm amused that I numbered from 0 but you numbered from 1, @pnkfelix =)

davidtwco (Feb 21 2019 at 15:32, on Zulip):

I added emoji for each of the three options to https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.2354818.20weekly.20meeting.202019-02-21/near/159076379

Shouldn't zero be there instead of three?

pnkfelix (Feb 21 2019 at 15:32, on Zulip):

@centril feel free, its non-binding

Vadim Petrochenkov (Feb 21 2019 at 15:32, on Zulip):

Noo, off by one error

pnkfelix (Feb 21 2019 at 15:32, on Zulip):

oh shoot

pnkfelix (Feb 21 2019 at 15:33, on Zulip):

shoot shot shoot

pnkfelix (Feb 21 2019 at 15:33, on Zulip):

so now we have four votes for 3, which doesn't exist

nikomatsakis (Feb 21 2019 at 15:33, on Zulip):

I propose we skip the strawpoll and just open an issue with FCP

nikomatsakis (Feb 21 2019 at 15:33, on Zulip):

I want to talk about the beta nomination :)

pnkfelix (Feb 21 2019 at 15:33, on Zulip):

heh okay

nikomatsakis (Feb 21 2019 at 15:34, on Zulip):

(Who will open the issue?)

pnkfelix (Feb 21 2019 at 15:34, on Zulip):

yeah we'll table discussion of the remaining nominated issues. (I'll try to go through them separatsely to tease out the ones we need to discuss)

oli (Feb 21 2019 at 15:34, on Zulip):

I'll do it

pnkfelix (Feb 21 2019 at 15:34, on Zulip):

okay so lets move along to WG-checkin

pnkfelix (Feb 21 2019 at 15:34, on Zulip):

Lets do WG-traits first since I think its more pressing than WG-nll

nikomatsakis (Feb 21 2019 at 15:34, on Zulip):

So, I wrote up some notes here:

https://github.com/rust-lang/compiler-team/blob/master/working-groups/traits/NOTES.md#20190219

The TL;DR is as follows:

nikomatsakis (Feb 21 2019 at 15:35, on Zulip):

However, there is a particular burning question that arose.

nikomatsakis (Feb 21 2019 at 15:35, on Zulip):

So, probably I'm just going to dig into that, and if there is time we can return to some of the more meta questions

nikomatsakis (Feb 21 2019 at 15:35, on Zulip):

Specifically, I landed a change some time back to switch the way that the compiler handles higher-ranked subtyping and trait matching

nikomatsakis (Feb 21 2019 at 15:36, on Zulip):

For convenience, the new system is called "universes", the old system is called "leak check"

nikomatsakis (Feb 21 2019 at 15:36, on Zulip):

I don't think we have time to get into the precise details of how the two operate here

nikomatsakis (Feb 21 2019 at 15:37, on Zulip):

Switching to universes passes a crater run and so I landed the PR -- we immediately hit some diagnostic issues along with one bug. Unfortunately, amidst the prep for the Rust All Hands I didn't respond to those as promptly as I wish I had. But more recently another issue arose as well that revealed that the universes check was accepted more code than initially anticipaetd

pnkfelix (Feb 21 2019 at 15:38, on Zulip):

so this hints that crater is indeed an incomplete test source, right?

nikomatsakis (Feb 21 2019 at 15:38, on Zulip):

I wrote a comment with a lot of the details but I think I can roughly summarize it like this:

nikomatsakis (Feb 21 2019 at 15:38, on Zulip):

so this hints that crater is indeed an incomplete test source, right?

Well, that was always known, but yes. In this case, the problem is more "things being accepted"

pnkfelix (Feb 21 2019 at 15:38, on Zulip):

(especially since it doesn't tend to have as many examples of broken code)

pnkfelix (Feb 21 2019 at 15:39, on Zulip):

yes exactly

nikomatsakis (Feb 21 2019 at 15:39, on Zulip):

Now, I debated about just reverting my PR, but since it landed some time ago, and there has been follow-on work since then, I was nervous about that being really challenging

nikomatsakis (Feb 21 2019 at 15:39, on Zulip):

Therefore, I implemented https://github.com/rust-lang/rust/pull/58592

nikomatsakis (Feb 21 2019 at 15:39, on Zulip):

which re-implements the older check in terms of the newer system

nikomatsakis (Feb 21 2019 at 15:39, on Zulip):

(in an arguably cleaner way)

nikomatsakis (Feb 21 2019 at 15:40, on Zulip):

in fact, I had originally intended to land something like this to start with anyway but I got aggressive (bad Niko)

nikomatsakis (Feb 21 2019 at 15:41, on Zulip):

Ordinarily I would not be psyched to backport a patch this large, but:

nikomatsakis (Feb 21 2019 at 15:41, on Zulip):

So I'm a bit unsure what to do and curious what others think :)

Aaron Turon (Feb 21 2019 at 15:41, on Zulip):

NB we have an active crater run on the PR

centril (Feb 21 2019 at 15:41, on Zulip):

@nikomatsakis In that case it seems especially prudent to do it... but are you confident in the soundness of the new leak check?

nikomatsakis (Feb 21 2019 at 15:41, on Zulip):

(Also, note that #58592 builds on a previous PR, which is a soundness fix, and which I also think is probably a good idea to backport)

pnkfelix (Feb 21 2019 at 15:42, on Zulip):

The impact of PR #58592, in principle, is just that we are now rejecting more code than we did with the universes PR alone. And we hope that the additional code we reject brings us closer to where we were immediately before the universes PR. Right?

nikomatsakis (Feb 21 2019 at 15:42, on Zulip):

Correct. I want to double check one test case, but in general I think it is equivalent to our older behavior.

nikomatsakis (Feb 21 2019 at 15:42, on Zulip):

I could also attempt to revert my original PR

pnkfelix (Feb 21 2019 at 15:42, on Zulip):

In particular, are there potential other side-effects from the change, like new type inference equations that might cause other changes to observable behavior?

nikomatsakis (Feb 21 2019 at 15:42, on Zulip):

At minimum I would also have to revert some follow-on PRs, e.g. that @lqd landed

Aaron Turon (Feb 21 2019 at 15:43, on Zulip):

I could also attempt to revert my original PR

that seems a lot more intensive, and it seems clear that we want the universes model ultimately

pnkfelix (Feb 21 2019 at 15:43, on Zulip):

are there potential other side-effects from the change, ...

(based on my cursory review, it seems like the answer is no; but I wanted to know if the answser is "its obviously no." or not.)

nikomatsakis (Feb 21 2019 at 15:43, on Zulip):

In particular, are there potential other side-effects from the change, like new type inference equations that might cause other changes to observable behavior?

Well, I can't say for sure. There is one specific test case that is passing without error that I didn't expect to pass without error, for example, and I need to dig into that.

Aaron Turon (Feb 21 2019 at 15:44, on Zulip):

I could also attempt to revert my original PR

that seems a lot more intensive, and it seems clear that we want the universes model ultimately

it's also worth noting that it doesn't seem feasible to do this in time for beta uplift

Aaron Turon (Feb 21 2019 at 15:44, on Zulip):

maybe a helpful way to look at this is: does anyone think it's OK for beta to go to stable as-is?

Aaron Turon (Feb 21 2019 at 15:45, on Zulip):

(with respect to what's covered by this and the soundness PR)

nikomatsakis (Feb 21 2019 at 15:45, on Zulip):

I do think it would be hard to do the revert for beta, and I also do think the universe code is just "better"

nikomatsakis (Feb 21 2019 at 15:45, on Zulip):

Can we clarify what those emojis are meant to represent :)

nikomatsakis (Feb 21 2019 at 15:46, on Zulip):

(@Esteban Küber ?)

Esteban Küber (Feb 21 2019 at 15:46, on Zulip):

Palm: not ok, plane landing ok to release current beta as stable

pnkfelix (Feb 21 2019 at 15:46, on Zulip):

/me is going to really gum up the works by adding :zero: and :one: to that comment as well

nikomatsakis (Feb 21 2019 at 15:46, on Zulip):

maybe a helpful way to look at this is: does anyone think it's OK for beta to go to stable as-is?

to spell out what @Aaron Turon is asking, does anyone think it's ok to land the new, more liberal "universe-based" check on stable

Esteban Küber (Feb 21 2019 at 15:46, on Zulip):

I lean towards the former

nikomatsakis (Feb 21 2019 at 15:47, on Zulip):

I guess I feel like the "overall" risk feels a bit lower by bringing back the leak check, though I do want to investigate that new test case

Aaron Turon (Feb 21 2019 at 15:47, on Zulip):

yeah -- we sort of just don't have a clearly "conservative" option here, there are risks in both directions

pnkfelix (Feb 21 2019 at 15:47, on Zulip):

the PR still hasn't landed in nightly

nikomatsakis (Feb 21 2019 at 15:47, on Zulip):

it's basically the same code either way, but the leak check adds some add'l ways for errors to occur -- however, it's not that it accepts strictly less code, as those errors can affect the way that the trait solver and coercion code works (it may realize some path is a dead-end, as a result)

nikomatsakis (Feb 21 2019 at 15:48, on Zulip):

(As an aside, I do think it's worth doing a procedural review here after the fact -- like, what went wrong)

pnkfelix (Feb 21 2019 at 15:48, on Zulip):

I'd feel somewhat better if we at least had time for the PR to bake in nightly before the backport, but time seems really tight.

nikomatsakis (Feb 21 2019 at 15:48, on Zulip):

This feels like a failure of process (and I feel a lot of responsibility for that)

pnkfelix (Feb 21 2019 at 15:48, on Zulip):

though I guess the right answer there is do the backport and then be ready to undo it if necessary?

nikomatsakis (Feb 21 2019 at 15:48, on Zulip):

When do we expect the crater run results?

Esteban Küber (Feb 21 2019 at 15:49, on Zulip):

Do we have an explicit process to stop the train if needed?

Aaron Turon (Feb 21 2019 at 15:49, on Zulip):

This feels like a failure of process (and I feel a lot of responsibility for that)

flying the whole team to Berlin is a great way to test process failure modes :joy: i certainly don't think you should blame yourself

nikomatsakis (Feb 21 2019 at 15:49, on Zulip):

Running (50%)

nikomatsakis (Feb 21 2019 at 15:49, on Zulip):

Do we have an explicit process to stop the train if needed?

no, we don't, but I was going to raise that as a possibility

nikomatsakis (Feb 21 2019 at 15:49, on Zulip):

to some extent this pressure is artificial

centril (Feb 21 2019 at 15:49, on Zulip):

@nikomatsakis @Aaron Turon but with https://github.com/rust-lang/rust/pull/58592 the risk to soundness is lower, yes?

nikomatsakis (Feb 21 2019 at 15:49, on Zulip):

obviously that would be a big deal

nikomatsakis (Feb 21 2019 at 15:50, on Zulip):

Running (50%)

this is what crater reports ;)

Aaron Turon (Feb 21 2019 at 15:50, on Zulip):

@nikomatsakis @Aaron Turon but with https://github.com/rust-lang/rust/pull/58592 the risk to soundness is lower, yes?

that's the theory/hope :)

nikomatsakis (Feb 21 2019 at 15:51, on Zulip):

@simulacrum wrote earlier:

FWIW you technically have until ~Sunday night to land whatever it is; I will note that the queue has been quite slow so we'll want to have it up at least 9-12 hours before we expect it to land

nikomatsakis (Feb 21 2019 at 15:51, on Zulip):

and then:

centril (Feb 21 2019 at 15:51, on Zulip):

@Aaron Turon OK; then :ship: imo ;)

Aaron Turon (Feb 21 2019 at 15:51, on Zulip):

can we expedite getting the PR landed on nightly?

nikomatsakis (Feb 21 2019 at 15:51, on Zulip):

(and if necessary there is technically some wiggle room on the release side -- we could slip by a day without affecting Thursday release)

Esteban Küber (Feb 21 2019 at 15:52, on Zulip):

obviously that would be a big deal

I feel that the potential fallout of a delayed release is much lower than an unsound release followed by point releases.

Aaron Turon (Feb 21 2019 at 15:52, on Zulip):

or are we waiting on crater before landing on nightly?

nikomatsakis (Feb 21 2019 at 15:52, on Zulip):

(link to comments)

Aaron Turon (Feb 21 2019 at 15:52, on Zulip):

(to me seems prudent to do both crater and nightly in parallel tbh)

nikomatsakis (Feb 21 2019 at 15:53, on Zulip):

I agree we don't have to block on crater to land on nightly

nikomatsakis (Feb 21 2019 at 15:53, on Zulip):

So, I think we can clearly say:

mw (Feb 21 2019 at 15:53, on Zulip):

would it be hard to just postpone the release if necessary?

nikomatsakis (Feb 21 2019 at 15:53, on Zulip):

Seems like "probably not" is the answer

nikomatsakis (Feb 21 2019 at 15:53, on Zulip):

Especially if it's not by a lot

nikomatsakis (Feb 21 2019 at 15:53, on Zulip):

It's worth answering the question of "What we are waiting for"

nikomatsakis (Feb 21 2019 at 15:53, on Zulip):

crater run? crater run of beta?

lqd (Feb 21 2019 at 15:53, on Zulip):

When do we expect the crater run results?

in 18 hours or so IIUC

nikomatsakis (Feb 21 2019 at 15:54, on Zulip):

Perhaps @Pietro Albini or other release folks may have thoughts, but I expect they would defer to our judgement to some extent in terms of what makes us feel comfortable.

centril (Feb 21 2019 at 15:54, on Zulip):

I don't think it's hard to postpone the release; afaik we (that is, @Pietro Albini) do those manually

pnkfelix (Feb 21 2019 at 15:55, on Zulip):

okay. I think it sounds like we have rough consensus now?

Aaron Turon (Feb 21 2019 at 15:55, on Zulip):

i think we should:

basically get as much info about the impact as we can, ASAP. if any of these reveal problems, then we can delay the release

centril (Feb 21 2019 at 15:55, on Zulip):

@nikomatsakis well; I cannot speak for the rest of the release team but I'm OK with @Aaron Turon's plan

nikomatsakis (Feb 21 2019 at 15:55, on Zulip):

Seems like we still have time to do those things if we act promptly

Esteban Küber (Feb 21 2019 at 15:56, on Zulip):

Worst case scenario it buys time to try to revert all the prs, however hard that would be now.

nikomatsakis (Feb 21 2019 at 15:56, on Zulip):

OK, I will focus on getting nightly landed and beta backport prepared.

pnkfelix (Feb 21 2019 at 15:57, on Zulip):

Okay. Luckily I don't think I need more than 3-4 minutes for the WG-nll checkin

pnkfelix (Feb 21 2019 at 15:57, on Zulip):

last NLL meeting notes

pnkfelix (Feb 21 2019 at 15:57, on Zulip):

(I haven't updated https://github.com/rust-lang/compiler-team/blob/master/working-groups/nll/NOTES.md with the results from last nights meeting yet)

pnkfelix (Feb 21 2019 at 15:58, on Zulip):

the main take-aways were: 1. we're going to try changing our weekly meeting so that triage is completely asynchronous

pnkfelix (Feb 21 2019 at 15:58, on Zulip):

and the weekly meeting itself will be intended to be a synchronous time for open discussion / office hous.

pnkfelix (Feb 21 2019 at 15:59, on Zulip):

(basically the previous meeting structure was oriented around triage because we were putting out a lot of fires in the effort to ship)

pnkfelix (Feb 21 2019 at 15:59, on Zulip):

the other thing is that we briefly discussed Place 2.0 work

pnkfelix (Feb 21 2019 at 15:59, on Zulip):

"[nll] change how MIR represents places" #52708

nikomatsakis (Feb 21 2019 at 16:00, on Zulip):

and the weekly meeting itself will be intended to be a synchronous time for open discussion / office hous.

nice, I was wanting to propose that we think about "team office hours"

pnkfelix (Feb 21 2019 at 16:00, on Zulip):

@Santiago Pastorino is going to continue working on it, perhaps paired up with @csmoe who wants to contribute to it again

pnkfelix (Feb 21 2019 at 16:01, on Zulip):

but I got the impression that they may not attempt to keep much of the previous work they did on it.

nikomatsakis (Feb 21 2019 at 16:01, on Zulip):

Is there a plan of attack?

nikomatsakis (Feb 21 2019 at 16:01, on Zulip):

This will be the 3rd attempt, it'd be nice if we are confident it will be the last

pnkfelix (Feb 21 2019 at 16:01, on Zulip):

I think the main idea is to try to identify an abstract API that the existing clients (or at least some of them) can be rewritten to use

nikomatsakis (Feb 21 2019 at 16:01, on Zulip):

I know @oli and @Santiago Pastorino spent some time talking about it etc

nikomatsakis (Feb 21 2019 at 16:02, on Zulip):

(If either of you have notes or links as to what that API looks like, I'd be curious to see it)

pnkfelix (Feb 21 2019 at 16:02, on Zulip):

there's on going discussion here: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/place.202.2E0

oli (Feb 21 2019 at 16:02, on Zulip):

yes we are discussing it in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/place.202.2E0/near/158971186 I can create a tracking issue so we have a centralized point of entry to the issue

pnkfelix (Feb 21 2019 at 16:02, on Zulip):

which links to this paper ((fixed link, sorry))

oli (Feb 21 2019 at 16:03, on Zulip):

also https://paper.dropbox.com/doc/vmbnFv8VkCEuL57QfWWMH

nikomatsakis (Feb 21 2019 at 16:03, on Zulip):

ok cool

oli (Feb 21 2019 at 16:03, on Zulip):

it's not very organized (sorry)

pnkfelix (Feb 21 2019 at 16:03, on Zulip):

but that's the hour and I need to go

nikomatsakis (Feb 21 2019 at 16:03, on Zulip):

I will try to check those out :) I haven't been able to follow

Santiago Pastorino (Feb 21 2019 at 16:03, on Zulip):

This will be the 3rd attempt, it'd be nice if we are confident it will be the last

I'm confident that we can do this :)

nikomatsakis (Feb 21 2019 at 16:03, on Zulip):

Yeah, I have to go hack on that PR :)

nikomatsakis (Feb 21 2019 at 16:03, on Zulip):

Glad to hear it!

pnkfelix (Feb 21 2019 at 16:03, on Zulip):

bye everyone!

nikomatsakis (Feb 21 2019 at 16:04, on Zulip):

Just to confirm, @oli and @Santiago Pastorino, the overall goal is still to change how places are represented in memory, but not "deeper changes" to MIR yet, right?

oli (Feb 21 2019 at 16:04, on Zulip):

yes

nikomatsakis (Feb 21 2019 at 16:04, on Zulip):

i.e., to shift from a tree to a slice or whatever, but not to remove the idea of places

nikomatsakis (Feb 21 2019 at 16:04, on Zulip):

cool

oli (Feb 21 2019 at 16:04, on Zulip):

the more extreme place changes are in the first linked document, but not planned before the tree -> slice change

Santiago Pastorino (Feb 21 2019 at 16:17, on Zulip):

:+1:

Last update: Nov 22 2019 at 06:00UTC