Stream: t-compiler

Topic: weekly meeting 2019-07-04 #54818


pnkfelix (Jul 04 2019 at 12:15, on Zulip):

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

pnkfelix (Jul 04 2019 at 12:16, on Zulip):

I will be doing pre-triage in a parallel topic

pnkfelix (Jul 04 2019 at 12:17, on Zulip):

I'm not sure where we are with the WG check-ins. (Gotta make a regular task for myself of updating the check-in calendar with entries for both past and present.

Esteban Küber (Jul 04 2019 at 12:18, on Zulip):

(I won't be there today, feel free to assign things to me bas necessary)

pnkfelix (Jul 04 2019 at 12:18, on Zulip):

okay thanks @Esteban Küber !

pnkfelix (Jul 04 2019 at 12:18, on Zulip):

I know that @nikomatsakis is likely to be absent due to the USA holiday

pnkfelix (Jul 04 2019 at 12:18, on Zulip):

but maybe @davidtwco or @Santiago Pastorino would like to give an update on what's happened since we last heard from @T-compiler/WG-meta ?

davidtwco (Jul 04 2019 at 12:19, on Zulip):

I could write something up.

pnkfelix (Jul 04 2019 at 12:19, on Zulip):

also, it might be good to hear from @blitzerr about what's happened with @WG-rfc-2229 ?

pnkfelix (Jul 04 2019 at 12:20, on Zulip):

Okay great @davidtwco , that would be really great. Especially the idea of maybe having something pre-written, as sometimes these WG checkins unfortunately get delayed until very late in the meeting. (Though I hope given our state w.r.t the imminent release that we will not have that problem today.)

pnkfelix (Jul 04 2019 at 14:04, on Zulip):

Hi @T-compiler/meeting , meeting is starting now

pnkfelix (Jul 04 2019 at 14:04, on Zulip):

lets dedicate 4 or 5 minutes to annoucements.

pnkfelix (Jul 04 2019 at 14:05, on Zulip):

I'll start: 1.36.0 is out!

pnkfelix (Jul 04 2019 at 14:09, on Zulip):

no other announcements? Okay

pnkfelix (Jul 04 2019 at 14:09, on Zulip):

I did a better job of pre-triage today

pnkfelix (Jul 04 2019 at 14:10, on Zulip):

but I still failed to do a traversal of the 44 open P-high T-compiler issues

pnkfelix (Jul 04 2019 at 14:10, on Zulip):

of which now 4 are currently unassigned. (But all the ones filed this year are assigned.)

pnkfelix (Jul 04 2019 at 14:11, on Zulip):

oh, all except one

pnkfelix (Jul 04 2019 at 14:11, on Zulip):

(which I nominated in hopes of getting someone here to take it on, during this meeting)

pnkfelix (Jul 04 2019 at 14:11, on Zulip):

so, lets go through the nominated issues then

pnkfelix (Jul 04 2019 at 14:12, on Zulip):

there are 6 nominated T-compiler issues

pnkfelix (Jul 04 2019 at 14:12, on Zulip):

(there's a lot more if you include the closed ones; I should perhaps consider clearing out those tags at some point, for clarity about nominations...)

pnkfelix (Jul 04 2019 at 14:13, on Zulip):

lets go newest first

pnkfelix (Jul 04 2019 at 14:13, on Zulip):

nominated: "ICE: rustc crashes in a chroot sandbox" #62353

pnkfelix (Jul 04 2019 at 14:13, on Zulip):

I nominated this because even though I do not think it is a high priority task (someone feel free to correct me about that), I do think it would be an interesting one, and perhaps one that could be done by a beginner.

pnkfelix (Jul 04 2019 at 14:13, on Zulip):

:question: Is anyone interested in trying to mentor someone else on this?

pnkfelix (Jul 04 2019 at 14:14, on Zulip):

(or take care of it outright?)

nagisa (Jul 04 2019 at 14:14, on Zulip):

Not really clear what is happening here to me.

nagisa (Jul 04 2019 at 14:14, on Zulip):

other than that this is some weird OS configuration.

pnkfelix (Jul 04 2019 at 14:14, on Zulip):

are chroot environments supposed to be able to provide /proc/self/exe ?

pnkfelix (Jul 04 2019 at 14:15, on Zulip):

it is weird, I suppose, that it only comes up for this particular crate

pnkfelix (Jul 04 2019 at 14:15, on Zulip):

even just finding someone who is capable of replicating the bug locally would be a step forward, honestly.

nagisa (Jul 04 2019 at 14:15, on Zulip):

They are not required to always provide it – you can choose whether you mount procfs or not, and also where you mount it.

nagisa (Jul 04 2019 at 14:16, on Zulip):

but the reporter says they have mounted it

pnkfelix (Jul 04 2019 at 14:16, on Zulip):

@nagisa I know you don't have much free time, but given that this P-medium, would you be able to take point on this?

nagisa (Jul 04 2019 at 14:16, on Zulip):

which then means that their procfs behaves in an unexpected way

nagisa (Jul 04 2019 at 14:16, on Zulip):

@pnkfelix I’ll prioritize other things

pnkfelix (Jul 04 2019 at 14:16, on Zulip):

okay that's an honest answer. :smiley:

pnkfelix (Jul 04 2019 at 14:16, on Zulip):

does anyone here use CentOS ?

nagisa (Jul 04 2019 at 14:16, on Zulip):

which probably means I’ll never get back to this, but I can ask the reporter some directed questions which may help to figure out the issue.

pnkfelix (Jul 04 2019 at 14:17, on Zulip):

okay, that's really all I'm asking for at this point.

pnkfelix (Jul 04 2019 at 14:17, on Zulip):

so I'll assign to @nagisa

eddyb (Jul 04 2019 at 14:18, on Zulip):

I just realized NixOS builds Rust stuff in chroots and I haven't heard anything from them

pnkfelix (Jul 04 2019 at 14:18, on Zulip):

@nagisa also, do you have any thoughts on my Q about whether we should allow the rustc user some way to avoid ever calling env::current_exe ?

eddyb (Jul 04 2019 at 14:18, on Zulip):

(could it be a really old Linux kernel? I'd ask them for an uname -a I guess)

pnkfelix (Jul 04 2019 at 14:18, on Zulip):

Like, that's just a convenience we're providing, right? Or is it something where it would be really bad/hard to live withut it?

nagisa (Jul 04 2019 at 14:19, on Zulip):

Maybe? I bet what this code is doing is trying to figure out the sysroot

pnkfelix (Jul 04 2019 at 14:19, on Zulip):

yes that is what it is doing

nagisa (Jul 04 2019 at 14:19, on Zulip):

I know that at least gcc/clang do provide a way to specify a different sysroot

pnkfelix (Jul 04 2019 at 14:19, on Zulip):

(I put a comment on the issue pointing to the bit of the code where its happening)

simulacrum (Jul 04 2019 at 14:19, on Zulip):

I believe you can always directly pass it via --sysroot path

simulacrum (Jul 04 2019 at 14:19, on Zulip):

(IIRC, rustbuild does this)

pnkfelix (Jul 04 2019 at 14:19, on Zulip):

@simulacrum I see, and then that should avoid ever calling env::current_exe ?

pnkfelix (Jul 04 2019 at 14:20, on Zulip):

@simulacrum does cargo support --sysroot ?

simulacrum (Jul 04 2019 at 14:20, on Zulip):

Cargo does not, you'd maybe be able to alias rustc=rustc --sysroot foo though

nagisa (Jul 04 2019 at 14:20, on Zulip):

cargo supports all of the rustc flags via cargo rustc ;)

pnkfelix (Jul 04 2019 at 14:20, on Zulip):

okay

eddyb (Jul 04 2019 at 14:20, on Zulip):

I'd set RUSTFLAGS

simulacrum (Jul 04 2019 at 14:20, on Zulip):

imo this is p-low

pnkfelix (Jul 04 2019 at 14:20, on Zulip):

Well I think we've gotten enough neurons firing about this

pnkfelix (Jul 04 2019 at 14:20, on Zulip):

@simulacrum true maybe we could reprioirtize to P-low

simulacrum (Jul 04 2019 at 14:21, on Zulip):

like, --sysroot should work (though maybe in a not great way), but this isn't really a tier-1 config

pnkfelix (Jul 04 2019 at 14:21, on Zulip):

but the fact that a user is runnign into it in the wild, vs it being some artificial bug that we constructed after looking at the code base, makes me think its P-medium, unless --sysroot definitely works

pnkfelix (Jul 04 2019 at 14:21, on Zulip):

so yeah, lets maybe check with the user about whether --sysroot fixes their problem. If it does, we reclassify to P-low. Sound good?

pnkfelix (Jul 04 2019 at 14:22, on Zulip):

next nominated T-compiler: "Incorrect span / broken rustfix: help: use dyn: dyn #[dom_struct]" #61963

pnkfelix (Jul 04 2019 at 14:22, on Zulip):

oh I shoul have cleared that flag

pnkfelix (Jul 04 2019 at 14:22, on Zulip):

(sorry all, that should be part of pre-triage!)

pnkfelix (Jul 04 2019 at 14:23, on Zulip):

(though @davidtwco , do try to leave a comment on the issue #61963 if you've made any headway on it. Or let us kinow if you need it reassigned.)

davidtwco (Jul 04 2019 at 14:23, on Zulip):

I've not had as much time as I'd like to look at it, but I still intend to.

pnkfelix (Jul 04 2019 at 14:23, on Zulip):

next nominated T-compiler: "Stable rustc always panics on arm/musl" #60297

pnkfelix (Jul 04 2019 at 14:24, on Zulip):

I nominated this because I want to find out if we have someone here readily able to test stuff on arm/musl

pnkfelix (Jul 04 2019 at 14:24, on Zulip):

I believe it to be our only P-high T-compiler bug from this year that is currently unassigned.

pnkfelix (Jul 04 2019 at 14:25, on Zulip):

If you have access to arm/musl but are not confident about your bug investigation capabilties, feel free to instant-message me about this bug #60297 and we'll work something out.

Vadim Petrochenkov (Jul 04 2019 at 14:25, on Zulip):

makes me think its P-medium

We never got to the meeting on the issue categorization, but I still don't understand what's the purpose of P-medium and any prioritization beside P-high.
Either P-medium or P-low, the issue is not going to be fixed anyway, unless it happens accidentally during some other work, or entirely randomly if it hits some enthusiastic person.

pnkfelix (Jul 04 2019 at 14:26, on Zulip):

makes me think its P-medium

We never got to the meeting on the issue categorization [...]

yep, that meeting got superceded, unfortunately. :sad:

pnkfelix (Jul 04 2019 at 14:27, on Zulip):

I agree that the differentiation between P-medium and P-low seems pretty silly given that we currently don't attempt to actively revisit either of them

pnkfelix (Jul 04 2019 at 14:27, on Zulip):

I would like for us to fix that at some point.

pnkfelix (Jul 04 2019 at 14:27, on Zulip):

But that is a topic best saved, I think, for the actual meeting on triage+maintenance ... though I do not know if that meeting will be held tomorrow or not

pnkfelix (Jul 04 2019 at 14:28, on Zulip):

(the meeting tomorrow is supposed to be a planning meeting for the coming month. but there are no proposals for such planning meeting. So who knows what we'll do, @nikomatsakis and I briefly disucssed the matter but came to no conclusions...)

pnkfelix (Jul 04 2019 at 14:28, on Zulip):

Actually

pnkfelix (Jul 04 2019 at 14:29, on Zulip):

:question: could I get a brief show of hands via emoji on this message for the statement: "I plan to attend the T-compiler design meeting, if any, taking place on Friday July 5th" ?

pnkfelix (Jul 04 2019 at 14:30, on Zulip):

:point_up:

pnkfelix (Jul 04 2019 at 14:31, on Zulip):

@nagisa , @eddyb , would you mind chiming in too?

eddyb (Jul 04 2019 at 14:31, on Zulip):

I'll... try

pnkfelix (Jul 04 2019 at 14:32, on Zulip):

I think :neutral: is good for that response

pnkfelix (Jul 04 2019 at 14:33, on Zulip):

Okay. More people can vote on it later if they like, and I'll relay it to @nikomatsakis (who is absent today due to USA holiday but I believe will be present tomorrow)

pnkfelix (Jul 04 2019 at 14:34, on Zulip):

:question: One more quick question for those present, same system of :thumbs_up: / :thumbs_down: / :neutral: : "I would appreciate it if we selected a new date/time for the Planning/Steering Meetings" ?

nagisa (Jul 04 2019 at 14:34, on Zulip):

I tend to miss meetings on fridays for some reason, usually because things happen on fridays, so :neutral:

eddyb (Jul 04 2019 at 14:34, on Zulip):

@nagisa yeah I have that problem too

pnkfelix (Jul 04 2019 at 14:35, on Zulip):

Yeah I suspected as much (thus the followup Q, as you can see)

pnkfelix (Jul 04 2019 at 14:35, on Zulip):

though maybe it would have been better phrased, e.g. as "I would be more likely to attend if it were rescheduled" ...

pnkfelix (Jul 04 2019 at 14:35, on Zulip):

Anyway

pnkfelix (Jul 04 2019 at 14:36, on Zulip):

I'll leave #60297 in its current state. Maybe someone will come to its aid next week

Vadim Petrochenkov (Jul 04 2019 at 14:37, on Zulip):

(I'm usually at work during the Thursday/Friday compiler meetings and usually don't have other meetings on those days, so I try to participate.)

pnkfelix (Jul 04 2019 at 14:37, on Zulip):

okay, I unnominated #59535 because it was assigned last week and I forgot to remove nomination then

pnkfelix (Jul 04 2019 at 14:37, on Zulip):

so next nomination T-compiler is: "The compiler should report publicly exported type names if possible" #21934

pnkfelix (Jul 04 2019 at 14:38, on Zulip):

I nominated this about two weeks ago because I was not sure it deserved P-high priority

pnkfelix (Jul 04 2019 at 14:38, on Zulip):

it is indeed a sizable footgun

pnkfelix (Jul 04 2019 at 14:38, on Zulip):

though I'm not clear how much of the foot-gun arises soley from re-exports within libstd, vs those from outside our control

pnkfelix (Jul 04 2019 at 14:39, on Zulip):

(its possible someone answered that question in the last two weeks and I have forgotten in my sleep-deprived state)

nagisa (Jul 04 2019 at 14:39, on Zulip):

I find this problem quite often outside of std too

pnkfelix (Jul 04 2019 at 14:40, on Zulip):

is it the sort of thing that we might consider devoting a design meeting to discuss potential solutions?

pnkfelix (Jul 04 2019 at 14:41, on Zulip):

because if I recall correctly, the main issue is that the only clearest way to fix it involves pretty major threading of state through much of compiler's name resolution system, right?

nagisa (Jul 04 2019 at 14:41, on Zulip):

Solution for this problem is non-trivial indeed, but the issue is not consequential enough for us to host a meeting – I think first and foremost we should find somebody who wants to work on this

pnkfelix (Jul 04 2019 at 14:42, on Zulip):

true, with no champion from within T-compiler developers, it will just languish

pnkfelix (Jul 04 2019 at 14:43, on Zulip):

should we delegate WG-diagnostics to come up with solution? Or is that unlikely to produce a result, or rather, likely to require effort from us anyway to mentor?

davidtwco (Jul 04 2019 at 14:43, on Zulip):

It's something I'd be interested in working on, I just don't think I have the expertise to work out a solution for it (I'm basing that entirely off of what I've read everyone else say about the problem).

pnkfelix (Jul 04 2019 at 14:44, on Zulip):

Its possible that @Esteban Küber would be willing to champion

pnkfelix (Jul 04 2019 at 14:44, on Zulip):

they've talked to me about wanting it fixed in the past

pnkfelix (Jul 04 2019 at 14:45, on Zulip):

Okay here's what I'm thinking: I'm going to assign this to @Esteban Küber to take point on either being the champion or finding someone else to be the champion.

pnkfelix (Jul 04 2019 at 14:45, on Zulip):

and I will likewise assign it to myself to follow-up (i.e. make sure it doesn't fall throguh cracks), like I do with other P-high issues that I assign to others.

Vadim Petrochenkov (Jul 04 2019 at 14:45, on Zulip):

Is anyone here going to have an intern by chance?
Because #21934 is exactly the kind of a task that can be offloaded to an intern - sizable, useful and unpleasant.

nagisa (Jul 04 2019 at 14:46, on Zulip):

give @eddyb money and I’m sure they will dig up 3 interns within a week.

eddyb (Jul 04 2019 at 14:47, on Zulip):

the problem is that last bit, it's really unpleasant

eddyb (Jul 04 2019 at 14:47, on Zulip):

and also the kind of thing we need to come up with a plan for, most importantly

pnkfelix (Jul 04 2019 at 14:47, on Zulip):

so let me bring up the next (and last) issue because I think it is in a similar boat: ""immutable field" errors are confusing when the handle is mutable, should describe why it is immutable" #18150

nagisa (Jul 04 2019 at 14:48, on Zulip):

Is it… hard? the current error seems readable to me

nagisa (Jul 04 2019 at 14:49, on Zulip):

error[E0594]: cannot assign to data in a & reference

nagisa (Jul 04 2019 at 14:49, on Zulip):

perhaps only s/in/behind/

eddyb (Jul 04 2019 at 14:49, on Zulip):

yeah this issue is ancient

Esteban Küber (Jul 04 2019 at 14:49, on Zulip):

Making it readable when the reason is not a & reference and instead mention why it is behind a reference is hard

pnkfelix (Jul 04 2019 at 14:50, on Zulip):

right

pnkfelix (Jul 04 2019 at 14:50, on Zulip):

I've actually been thinking a little about this

pnkfelix (Jul 04 2019 at 14:50, on Zulip):

namely in that we may want more plumbing when we insert auto-refs/derefs

Esteban Küber (Jul 04 2019 at 14:50, on Zulip):

My personal diagnostic e weighting is easy wording change medium needs to understand tyctxt or similar, hard needs to know multiple parts if the compiler

eddyb (Jul 04 2019 at 14:50, on Zulip):

oh noes :(

pnkfelix (Jul 04 2019 at 14:50, on Zulip):

Or derefs throgh Deref trait, to trace back to the reasons they were inserted

eddyb (Jul 04 2019 at 14:51, on Zulip):

@pnkfelix maybe we can rely on Spans?

pnkfelix (Jul 04 2019 at 14:51, on Zulip):

oh noes :(

was this in reaction to desiring more plumbing?

nagisa (Jul 04 2019 at 14:51, on Zulip):

I still feel this can be solved with a rewording.

eddyb (Jul 04 2019 at 14:51, on Zulip):

if the Deref::deref call has the same span as the borrow/deref, then it's autoderef

eddyb (Jul 04 2019 at 14:52, on Zulip):

but this might be expensive to compute :(

pnkfelix (Jul 04 2019 at 14:52, on Zulip):

okay well at this point I'm actually willing to take ownership of this ticket

pnkfelix (Jul 04 2019 at 14:53, on Zulip):

rather than devote more time to it in this or a future triage meeting

eddyb (Jul 04 2019 at 14:53, on Zulip):

I wish we had the bandwidth to figure out a more effective MIR representation, but that's neither here nor there

pnkfelix (Jul 04 2019 at 14:53, on Zulip):

(or rather, I'd prefer to have a more directed conversation about the solution space, rahter than continuing to thrash about trying to find a champion for it.)

pnkfelix (Jul 04 2019 at 14:53, on Zulip):

Do people think that this should remain P-high, though?

pnkfelix (Jul 04 2019 at 14:53, on Zulip):

which was part of the reason I nominated it?

eddyb (Jul 04 2019 at 14:54, on Zulip):

no, it has greatly improved since it was opened

pnkfelix (Jul 04 2019 at 14:54, on Zulip):

I agree with @eddyb that I think it is at most P-medium.

eddyb (Jul 04 2019 at 14:55, on Zulip):

I almost feel like the smart pointer case deserves its own separate issue, and the original issue was fixed

pnkfelix (Jul 04 2019 at 14:55, on Zulip):

@eddyb but note the P-high tag was added recently, in response to #52941

pnkfelix (Jul 04 2019 at 14:55, on Zulip):

I almost feel like the smart pointer case deserves its own separate issue, and the original issue was fixed

that is certainly possible

pnkfelix (Jul 04 2019 at 14:55, on Zulip):

okay well I think that's enough of the nominated issues. Or at least I'm happy with the progress we've made tehre.

eddyb (Jul 04 2019 at 14:55, on Zulip):

like, I'd close the old issue and reopen #52941 which is the modern problem

pnkfelix (Jul 04 2019 at 14:55, on Zulip):

@davidtwco , you around?

davidtwco (Jul 04 2019 at 14:56, on Zulip):

:wave:

pnkfelix (Jul 04 2019 at 14:56, on Zulip):

because this is a great time to get a checkin from @T-compiler/WG-meta

davidtwco (Jul 04 2019 at 14:56, on Zulip):

In the past few weeks, #t-compiler/wg-meta have just been checking-in on our outstanding issues and any open PRs (with conferences/moz-all-hands/etc there's not always everyone present in recent weeks). So there hasn't been a massive amount going on, we'll probably start to move forward on other things the working group wants to accomplish soon and check-in with working groups to see if they're having any problems, etc.

That said, one thing that has been making progress is the ongoing work by @Federico Carrone and @catalinasy to convert the rust-lang/compiler-team repository into a static website that is easier to navigate and find information on. It's more or less there and once the last few comments are resolved, it'll just be waiting for other members of #t-compiler/wg-meta to sign-off on it.

pnkfelix (Jul 04 2019 at 14:56, on Zulip):

like, I'd close the old issue and reopen #52941 which is the modern problem

(i'll do this)

pnkfelix (Jul 04 2019 at 15:00, on Zulip):

@davidtwco so is the intention that we would go to that website instead of the repo to read info (about, e.g., upcoming meetings, working group structures, etc)? But we'd go to the repo to make edits to the website contents?

davidtwco (Jul 04 2019 at 15:01, on Zulip):

Yeah. The repository will still just be markdown files, only in slightly different places, so editing things will still happen there but you'll read it from the website.

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

great, cool

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

Okay, well, we actually sort of followed our agenda this week and basically finished on time

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

amazing! :tada:

pnkfelix (Jul 04 2019 at 15:03, on Zulip):

Thanks to everyone in @T-compiler/meeting for attending! And just as a "reminder", there will probably be a steering meeting tomorrow, same time as this meeting

pnkfelix (Jul 04 2019 at 15:03, on Zulip):

I am not 100% sure it will happen based on the 1. above poll and 2. lack of clarity with respect to topic

pnkfelix (Jul 04 2019 at 15:04, on Zulip):

but I'll check with @nikomatsakis and try to send out an email later today

eddyb (Jul 04 2019 at 15:16, on Zulip):

@pnkfelix I started writing this so I finished it for the hell of it https://github.com/rust-lang/rust/issues/21934#issuecomment-508515813

eddyb (Jul 04 2019 at 15:16, on Zulip):

we can do a hacky version of this without that much effort

eddyb (Jul 04 2019 at 15:16, on Zulip):

and maybe then build on it?

pnkfelix (Jul 05 2019 at 08:04, on Zulip):

thanks @eddyb

Last update: Nov 20 2019 at 01:35UTC