Stream: t-compiler

Topic: weekly meeting 2019-05-02 #54818


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

Just a heads up to @T-compiler/meeting : the meeting will start in about 3.5 hours

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

in the meantime, i'll be doing pre-triage in a parallel topic

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

:construction_worker: call for assistance: Does someone have an ARM (and maybe also MUSL?) host they could use to try to replicate " Stable rustc always panics on arm/musl" #60297

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

if so, please leave comment (and if possible, assign yourself to the ticket for the initial investigation)

Wesley Wiser (May 02 2019 at 12:59, on Zulip):

(I'll add that to the meeting minutes)

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

hi @T-compiler/meeting

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

once again

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

I did not get through all the pre-triage

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

but it did lead to some potentially interesting discussion

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

of our current triaging/labelling system

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

such as the intent of P-high

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

but I digress

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

first up: Are there any announcements?

nagisa (May 02 2019 at 14:03, on Zulip):

P-high is something that comes up fairly periodically, doesn’t it

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

P-high is something that comes up fairly periodically, doesn’t it

I don't know if this was meant to be a pun, in that I revisit the P-high's every week

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

or just a note that we are often debating the meaning of P-high

nagisa (May 02 2019 at 14:04, on Zulip):

Lets go with both :slight_smile:

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

but: Yes.

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

Here's my announcement

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

It occurs to me this might make a nice "non-technical meeting proposal"

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

there are currently 16 p-high unassigned t-compiler issues

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

puh-leasze everyone, take a quick look

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

and see if there's any that you might like to attack

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

I actually do think that handing them out at a meeting like this can make some sense in terms of trying to get an ad-hoc fair distribution of work

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

but once again I think there are too many other things to try to take care of first

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

oh well maybe I'm wrong about that; there are no beta- nor stable-nominations for backport

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

there are three stable-to-beta regressions

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

one, #59553, is already assigned to @nikomatsakis

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

I think we have a pending PR, prepared by @Esteban Küber, right?

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

sorry, a merged PR

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

https://github.com/rust-lang/rust/pull/60186

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

okay

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

so that just needs a backport?

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

but it wasn't nominated?

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

oh

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

it was merged to beta too?

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

that PR states "#59553 will need to be kept open to track the change back to rejecting this code a few versions down thee line.", but I think that is wrong

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

I created https://github.com/rust-lang/rust/issues/60210 for that purpose, in particular

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

I'd open a fresh issue for that

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

it was merged to beta too?

not sure, I will check

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

I'd open a fresh issue for that

yeah, I did already

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

(and the PR was modified to cite #60210)

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

okay. lets close #59553 and point to #60210 as the followup

Esteban Küber (May 02 2019 at 14:11, on Zulip):

The one I wanted to follow up on was a different one though

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

maybe I don't understand what you meant by that sentence, @Esteban Küber =)

Esteban Küber (May 02 2019 at 14:12, on Zulip):

https://github.com/rust-lang/rust/pull/60118

Esteban Küber (May 02 2019 at 14:12, on Zulip):

The backport needed to happen and read approved, the was the other pr wich need a bit of policy discussion

Esteban Küber (May 02 2019 at 14:13, on Zulip):

Around how much is to much for the sake of diagnostics

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

but this is not related to foo.0usize, right?

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

@Esteban Küber I know I'm a constant nag about the need to abstract into functions, but it would make me sleep better if we at least refactored these things into functions :slight_smile: So that we at least hide the burden of recovery and better diagnostics in dedicated functions.

Esteban Küber (May 02 2019 at 14:14, on Zulip):

No, Fit that we have the or accepting but warning on usize

Esteban Küber (May 02 2019 at 14:14, on Zulip):

And a tracking ticket

Esteban Küber (May 02 2019 at 14:14, on Zulip):

Nothing to do in the short term

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

OK. I would like to discuss #60118 but let's maybe stay focused on the P-high issues for the moment --

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

okay then

Esteban Küber (May 02 2019 at 14:15, on Zulip):

Dont disagree @centril , I have a pr I'm working on to separate parser in three

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

@pnkfelix I'm not sure how you want us to proceed here, I'm going through the list and seeing some issues that I have "thoughts" on, but not sure whether to dump them here or what :)

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

there are two unassigned p-high stable-to-beta regressions

Esteban Küber (May 02 2019 at 14:15, on Zulip):

Sure

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

My highest priorty right now

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

is to figure out whether we are even going to fix these

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

and if so, assign someone to them

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

it seems like some may have been discussed last week?

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

or

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

let me go in order

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

first: "cannot borrow as mutable because it is also borrowed as immutable (likely regression)" #60136

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

there are comments from seven days ago

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

which made me wonder if it was discussed

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

it was

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

but no one is assigend, and the comments just say workarounds

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

my take is that this is "expected breakage"

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

perhaps my comment didn't make that clear, though

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

Fix seems unlikely? The impls shouldn't be rolled back at this stage

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

if this is expected breakage

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

in particular, we added an impl of Fn or whatever for Box<F>; that led the call notation to behave differently.

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

then fine. we just close ticket then, yes?

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

Confirm. I can try to leave a comment if you like.

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

okay, the other issue

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

(I closed and commented on the first)

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

the second issue is "reached the type-length limit while instantiating" #58952

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

since this was nominated and tagged nine days ago

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

you all might have discussed it last week

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

but I don't think I recall seeing it mentioned in the chat log

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

we didn't see this last week; I just caught up on the discussion

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

(aside: it would be neat to have a crisp description of what type-length-limit does; if any of y'all would be willing to improve the reference here it would be great)

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

( @centril I could do that )

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

so there are facets to this

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

@nikomatsakis (what we have right now is https://doc.rust-lang.org/nightly/reference/attributes/limits.html#the-type_length_limit-attribute -- which doesn't seem that bad but if you can vet it that would be great)

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

this particular person's project stopped compiling

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

it was bisected down to PR #58730

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

This is a difficult area for us; it's running up against some internal thresholds in the compiler. It's possible we could refactor the compiler so that it works differently and doesn't wind up creating such big types.

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

But I can't say for sure.

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

right. the only sense it which I see this as a compiler issue

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

@nikomatsakis how actionable is that refactoring?

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

(time-wise)

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

is that it might be a request to make the compiler smarter about its handling of big types

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

I don't even know what refactoring it would be. I would say 'not very"

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

(but it may be that, digging into this, we would find we are doing something silly)

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

but I don't see us being able to address that in time for the beta rollover to stable, no?

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

yeah, I'm .. inclined to close myself.

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

well, we either close, or see if T-libs wants to revert PR #58730 ?

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

but I have to assume the benefits

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

in terms of performance

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

should lead one to conclude "no" on a revert

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

Yes, I suppose. I think this is not an area of breakage we explicitly called out in any of our documents, as an aside. (Also, @centril, I think it'd be interesting for the lang team to revisit these sorts of limits and see if we can create better solutions -- e.g., I think the recursion limit in particular is poorly done around macros)

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

okay

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

@nikomatsakis (sure; I think I lack the expertise tho so I'm happy to mostly listen and be a :duck:)

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

well this is enough for me to at least conclude that we're not going to be trying to fix either of these

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

so I won't attempt to assign someone to them

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

I'll just mention again that there are a lot of open unassigned P-high T-compiler bugs

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

I definitely think there is lower hanging fruit

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

I think this is not an area of breakage we explicitly called out in any of our documents, as an aside.

I haven't checked, but I think that's true. On the other hand, it seems quite hard to guarantee anything wrt. limits as a matter of a language spec -- seems very implementation specific

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

there are two PRs marked waiting-on-team for us

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

one is "add support for unchecked math" #59148

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

well

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

we weren't actually a tagged team

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

at the time it was marked waiting-on-team

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

centril has since then tagged us (as well as other teams) and nominated it

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

so we might get to it in the nominated issues

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

but in the meantime

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

if you all have an opinion on this PR (#59148)

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

feel free to chime in on the PR comments

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

the other one marked S-waiting-on-team is "Hide type errors likely caused by incorrect struct literal" #60118

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

(I primarily nominated for T-compiler as a matter of "do you want to use this for anything internal?")

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

@Vadim Petrochenkov had objected to PR #60118, saying it was too many hacks for one specific case

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

I guess we (or someone here) will need to decide if @Vadim Petrochenkov is correct (and just close this)

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

but it doesn't seem terribly urgent

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

so I'll just say for now taht I'm pointing it out to you all

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

but I want to move along

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

... (technically we are out of time for the triage portion of the meeting)

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

but I want to skim over the nominations

Esteban Küber (May 02 2019 at 14:32, on Zulip):

I just want to know wether to stop writing these kinds of hiding hacks

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

of which there are 18 issues

Esteban Küber (May 02 2019 at 14:32, on Zulip):

But let's move on :slight_smile:

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

during my pre-triage

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

a couple of these stood out to me

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

so I want to at least mention them here

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

first "Implement converting an AST to a token tree" #43081

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

a very old issue that needs prioritization

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

@eddyb nominated it for prioritization

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

Nominating for possible prioritization (sorry, the past few months have been pretty hectic).
cc @aturon @nikomatsakis wrt me focusing on a large-scale solution for this

eddyb (May 02 2019 at 14:33, on Zulip):

@nikomatsakis btw, regarding type-length-limit: the type is actually small because it's a DAG, but we're visiting it in a way that is exponential, and there is no good reason to do that IMO

eddyb (May 02 2019 at 14:34, on Zulip):

okay, so, regarding AST -> TokenTree

eddyb (May 02 2019 at 14:34, on Zulip):

or TokenStream rather

eddyb (May 02 2019 at 14:34, on Zulip):

we'll discuss it tomorrow in the compiler design meeting

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

okay then

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

I should be there at that meeting, I hope

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

if I'm not, please do try to attach a P-label

eddyb (May 02 2019 at 14:34, on Zulip):

I have a partial writeup at https://hackmd.io/zrZhb94HS6KxW3sguwXNqA

eddyb (May 02 2019 at 14:35, on Zulip):

I was pinging niko and aturon regarding my contract, to be clear

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

Another Nominated issue that stood out to me: "Exponential compile-time and type_length_limit blowup when nesting closure wrappers" #54540

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

I was pinging niko and aturon regarding my contract, to be clear

ah I see. That was not clear to me from the text.

eddyb (May 02 2019 at 14:35, on Zulip):

wait is that not the type-length-limit one?

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

there are two type-length limit issues

eddyb (May 02 2019 at 14:36, on Zulip):

okay this one I wrote a comment on

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

one was tagged as a beta-regression

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

which we discussed earlier

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

it arose due to some internal changes to something in Iterator Filter yada yada yada

eddyb (May 02 2019 at 14:36, on Zulip):

we have an N-node DAG that when visited naively results in 2^N nodes being observed

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

this second issue, #54540, seems to be more the case you are talking about, I think.

eddyb (May 02 2019 at 14:37, on Zulip):

right, sorry, that's what I thought was being discussed earlier

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

I personally am inclined to agree that there isn't a good reason to have exponential blow up when traversing a DAG

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

but, as I wrote in the most recent comment on #54540, also do not think this particular issue seems to be urgent ?

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

we have an N-node DAG that when visited naively results in 2^N nodes being observed

to be clear, are you proposing that we can change the way we walk or the way closure generics are setup (or both)

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

Do you think that is fair, @eddyb ?

eddyb (May 02 2019 at 14:38, on Zulip):

the whole limit is to prevent other parts of the compiler from dying from dealing with very complex types

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

I .. am trying to remember why I setup the closure generics this way, there were reasons, but maybe not good ones. It evolved quite a bit.

eddyb (May 02 2019 at 14:38, on Zulip):

fixing how we walk to compute type-length-limit is easier than adjusting closures

eddyb (May 02 2019 at 14:38, on Zulip):

so I'd do the former first

eddyb (May 02 2019 at 14:39, on Zulip):

(the latter I'm not even sure is possible)

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

( this may or may not help with the other issue, @pnkfelix )

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

seems plausible that it would

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

I suppose if it could help

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

so I'd do the former first

I'm much more open to that, to be sure :) I don't quite understand the problem yet tho

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

I suppose if it could help

there are almost certainly closures wrapping other closures

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

then that is a reason to prioritize investigating it

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

Okay. @eddyb , do you actually want (and have time) to look at this?

eddyb (May 02 2019 at 14:40, on Zulip):

I suppose, I had forgotten about it, but the fix should be quick

eddyb (May 02 2019 at 14:41, on Zulip):

the hard part is not regressing performance when .walk() used to be very fast

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

I'm willing to mark it P-high on the assumption that it may help with the associated regression

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

@eddyb are you just saying that we are kind of walking and re-walking the same types quite naively as we descnd?

eddyb (May 02 2019 at 14:41, on Zulip):

because we'd now need some sort of set/map

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

but I'm not eager to add to the set of P-high things that have no one assigned.

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

and hence we wind up with exponential because we're dumb

eddyb (May 02 2019 at 14:41, on Zulip):

yupp!

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

thus my hesitation.

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

ok, that does seem easy to fix

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

okay

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

we are running even lower on time

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

...

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

(Can we figure out if this fixes the regression?)

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

there are two more issues I really wanted to point out

eddyb (May 02 2019 at 14:42, on Zulip):

we can either compute a smaller number, or the number from today, but in either case we can do it in very little time

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

(can be maybe table discussion of #58952 )

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

(or move it to side topic, even better)

eddyb (May 02 2019 at 14:43, on Zulip):

so even if the user has to raise the limit, there would be no slowdown

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

so the next to last nomination I wante dto mentioned

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

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

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

what tier is this platform on this ticket?

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

ARM musl

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

the issue filer is using Rasp Pi Gen 1 running Void Linux

mw (May 02 2019 at 14:43, on Zulip):

that must be the lowest tier ever :)

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

but I'm hoping that is not necessary to actually replicate this

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

@pnkfelix https://rust-lang.github.io/rustup-components-history/

eddyb (May 02 2019 at 14:44, on Zulip):

so I do have some raspis...

Esteban Küber (May 02 2019 at 14:44, on Zulip):

@Pietro Albini pointed out on the ticket it is tier 2

eddyb (May 02 2019 at 14:44, on Zulip):

but booting them doesn't work anymore

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

ah sorry I didn't look for updates

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

okay

eddyb (May 02 2019 at 14:44, on Zulip):

so I'm not sure I can help

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

well, if someone wants to try to poke at that

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

it sounds like our system acts like it is dead in the water there

eddyb (May 02 2019 at 14:45, on Zulip):

(like, the screen doesn't turn on)

nagisa (May 02 2019 at 14:45, on Zulip):

but booting them doesn't work anymore

Ditto...

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

last issue I wanted to point out today

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

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

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

oh never mind

eddyb (May 02 2019 at 14:45, on Zulip):

however it should be easy to use qemu with even linux-userspace-only emulation

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

@mw assigned themselves

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

to #60020

mw (May 02 2019 at 14:45, on Zulip):

yeah, I'll have a look

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

so lets just move forward

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

to WG checkins

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

today is WG-rls2.0

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

@matklad ^

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

and WG-meta

matklad (May 02 2019 at 14:46, on Zulip):

:hi:

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

(@nikomatsakis ? @davidtwco ? @Santiago Pastorino ?)

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

lets hear from @matklad first

matklad (May 02 2019 at 14:46, on Zulip):

Sure!

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

and WG-meta

I can do that

matklad (May 02 2019 at 14:47, on Zulip):

Three big things are going on!

matklad (May 02 2019 at 14:47, on Zulip):

First, @Edwin Cheng is making great progress in handling macros by example

matklad (May 02 2019 at 14:47, on Zulip):

So, we expand more stuff!

matklad (May 02 2019 at 14:48, on Zulip):

@Florian Diebold prepared a PR which integrates chalk into rust-analyzer ( :confetti: ) https://github.com/rust-analyzer/rust-analyzer/pull/1216.

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

/me still needs to read more about that

matklad (May 02 2019 at 14:49, on Zulip):

And the third big thing is that @matklad is pushing on extracting rustc-lexer as a separate library.

This ... moves quite slowly, because this is rustc work, and building rustc is :snail:

Though today the first bit of lexer work passed the tests https://github.com/rust-lang/rust/pull/60261 :)

matklad (May 02 2019 at 14:50, on Zulip):

That's it for rls-2.0 I guess?

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

fantastic

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

thanks @matklad

matklad (May 02 2019 at 14:50, on Zulip):

oh

matklad (May 02 2019 at 14:51, on Zulip):

/me is also curios to hear about @pnkfelix 's progess on name resolution :)

matklad (May 02 2019 at 14:51, on Zulip):

but not in this meeting, obviously :)

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

i'll check in with you about that maybe next week

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

okay @nikomatsakis , how about WG-meta ?

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

OK, so, briefly:

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

I didn't really prep for this so some stuff isn't top of mind, but I know that

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

@Santiago Pastorino was creating a machine-readable "expert file"

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

I think one of the work items I would like to see is

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

moving the compiler-team repo to some sort of github pages thing,

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

so that we can make the display be a bit fancier,

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

e.g., to incorporate the expert file etc

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

One last thing that I've been wanting to try and get going is to have a way for people to advertise "help wanted" ideas -- i.e., this working group is looking for someone to help with docs, or whatever

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

I'm planning to start with basically an internals thread

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

and some tweets :)

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

sounds great

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

finally, my general feeling is that we're reaching the "end" of the "procedural changes" -- or, more to the point, I'd like to try and "let the system run" for a while before we attempt much new beyond those things

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

but I still think there's plenty of "tuning things" to do (e.g., improving the website etc)

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

(perhaps I should take this to wg-meta first...; one t-infra/t-compiler RFC idea I had was to consider how we should deal with rustfmt in the repo and wrt. bors)

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

that is a good idea -- would be a good design meeting topic, perhaps!

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

My hope is that the design meeting is a place we can use to have those discussions in a sync fashion if we want to

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

(fin)

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

okay. Obviously there were other nominated issues

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

we have three minutes left

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

so I'll just mention "x.py in incremental mode still rebuilds stage0-rustc if stage0-std changed." #54712

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

there's been recent discussion in it

oli (May 02 2019 at 14:58, on Zulip):

https://github.com/rust-lang/rust/pull/59288 up to 3% regression, but much simpler code. Are we ok with taking that hit without a concrete plan for getting perf back?

oli (May 02 2019 at 14:59, on Zulip):

It's basically lowering ifinto match

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

(average is ~1%, https://perf.rust-lang.org/compare.html?start=efe2f32a6b8217425f361ec7c206910c611c03ee&end=6a4b8678ecc14fe00b78b06eb7e9f272680bba37)

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

we once again

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

are measuring the overall compile time

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

for a compiler compiled with itself

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

right?

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

and thus I cannot really tell from perf whether this hurt our codegen

oli (May 02 2019 at 15:00, on Zulip):

yes, this is compilation speed we're losing, not codegen

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

or if it solely hurt our compile-time, while client object code remains fine

oli (May 02 2019 at 15:00, on Zulip):

the MIR is the same after trivial MIR optimizations

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

okay

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

@pnkfelix mir-opt will eliminate differences past early-opt (what Oli said)

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

(I also think it's important to do this so that we can make progress on let_chains cause otherwise it becomes pretty hacky to do this with hir::ExprKind::If)

nikomatsakis (May 02 2019 at 15:02, on Zulip):

Hmm.

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

I believe, @oli had the idea to special case mir-build for two match arms which may improve things for match c { true => expr, _ => expr } as well

nikomatsakis (May 02 2019 at 15:02, on Zulip):

Do we have more detailed profiles indicating where the 3% go?

nikomatsakis (May 02 2019 at 15:02, on Zulip):

(self-profile might be useful here)

nikomatsakis (May 02 2019 at 15:02, on Zulip):

like, is it MIR build?

oli (May 02 2019 at 15:03, on Zulip):

yea, it's mir building

oli (May 02 2019 at 15:03, on Zulip):

the mir_build query to be exakt

oli (May 02 2019 at 15:03, on Zulip):

I can put that info into the PR

nikomatsakis (May 02 2019 at 15:03, on Zulip):

I think my feeling is that we should land this PR, but I also think we should be more aggressively trying to reduce compilation time (which is a separate topic). Sort of similar to the 'tcx and memory usage point.

oli (May 02 2019 at 15:04, on Zulip):

yea, anything we do here will improve match on booleans, too, so it's a general solution we'd need

nikomatsakis (May 02 2019 at 15:04, on Zulip):

(Basically I'm worried we're not doing enough to do "small bore" improvements, and I don't quite know how to address it; I had thought about trying to make that a topic for a meeting too =)

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

I think I agree with @nikomatsakis . Our compilation speed issues are a problem, but if we let issues there hold us back from simplifying the code, we're going to have a real hard time

centril (May 02 2019 at 15:04, on Zulip):

@nikomatsakis Yeah that's very fair; I'm happy to help out with mir-opt if I can but right now it's out of my knowledge ^^

nikomatsakis (May 02 2019 at 15:04, on Zulip):

I've been semi-waiting until self-profile was functional, since I think a first step will be gathering data

centril (May 02 2019 at 15:04, on Zulip):

@nikomatsakis I did use self-profile for this one :D and it resulted in some docs improvements and possible future UX improvements

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

I have to go now, but thanks everyone for attending. Bye @T-compiler/meeting

Wesley Wiser (May 02 2019 at 15:05, on Zulip):

Perhaps we should split out a topic to see what is left to do to make self-profile functional?

nikomatsakis (May 02 2019 at 15:06, on Zulip):

Seems good

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

@Wesley Wiser the summarize changes and things around diffs I think should get us pretty close imo

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

Once I threw myself at summarize it was pretty helpful aside from the pain points I've already noted

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

And I'm a total noob at profiling so if it mostly works for me that's probably saying something :D

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

That's great to hear @centril! :)

Santiago Pastorino (May 02 2019 at 17:50, on Zulip):

sorry that I could not attend today, thanks @nikomatsakis for covering wg-meta stuff :heart:

Last update: Nov 22 2019 at 04:55UTC