Stream: t-compiler

Topic: weekly meeting 2020-04-09 #54818


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

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

Santiago Pastorino (Apr 08 2020 at 17:16, on Zulip):

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

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

We will have checkins from @WG-rustc-dev-guide and @WG-llvm

Santiago Pastorino (Apr 08 2020 at 17:18, on Zulip):

about Rustc Dev Guide, @mark-i-m do you want to provide the update or I can also do it :)

Santiago Pastorino (Apr 08 2020 at 17:19, on Zulip):

about LLVM, @nagisa do you want to share any information?

Santiago Pastorino (Apr 08 2020 at 17:47, on Zulip):

We've just create the meeting agenda, will be filling it during pre-triage

Wesley Wiser (Apr 08 2020 at 18:03, on Zulip):

I think something has gone wrong with the WG checkin rotation. We just had check ins from those WGs two weeks ago https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202020-03-26.20.2354818/near/191788452

mark-i-m (Apr 08 2020 at 19:04, on Zulip):

@Santiago Pastorino I can do it

Santiago Pastorino (Apr 08 2020 at 19:55, on Zulip):

Wesley Wiser said:

I think something has gone wrong with the WG checkin rotation. We just had check ins from those WGs two weeks ago https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/weekly.20meeting.202020-03-26.20.2354818/near/191788452

you're right

Santiago Pastorino (Apr 08 2020 at 19:55, on Zulip):

it sounded to me like that

Santiago Pastorino (Apr 08 2020 at 19:56, on Zulip):

prioritization wg was added to the list

Santiago Pastorino (Apr 08 2020 at 19:56, on Zulip):

that was the problem

pnkfelix (Apr 08 2020 at 19:57, on Zulip):

seems non-ideal

pnkfelix (Apr 08 2020 at 19:57, on Zulip):

that adding a new entry can cause that kind of change

Santiago Pastorino (Apr 08 2020 at 19:57, on Zulip):

that's why we didn't have the thing alphabetically sorted

pnkfelix (Apr 08 2020 at 19:57, on Zulip):

heh

Santiago Pastorino (Apr 08 2020 at 19:57, on Zulip):

I guess I can move the wg to the end

Santiago Pastorino (Apr 08 2020 at 19:57, on Zulip):

:P

mark-i-m (Apr 08 2020 at 20:32, on Zulip):

@Santiago Pastorino So should prepare a checkin?

Santiago Pastorino (Apr 08 2020 at 20:32, on Zulip):

we were discussing with @pnkfelix and let's keep it the way it is this time, the js logic for working groups has issues

Santiago Pastorino (Apr 08 2020 at 20:33, on Zulip):

it's not related with the order of the working groups, although the order can generate problems

Santiago Pastorino (Apr 08 2020 at 20:33, on Zulip):

it's related to how many pairs of wgs we have, once there's an extra pair the "order" changes and situations like this could arise

Santiago Pastorino (Apr 08 2020 at 20:33, on Zulip):

we've decided to open an issue about it

Santiago Pastorino (Apr 08 2020 at 20:34, on Zulip):

but meanwhile let's keep following whatever the schedule says

mark-i-m (Apr 08 2020 at 20:52, on Zulip):

Ok, I've updated the checkin doc

mark-i-m (Apr 08 2020 at 20:52, on Zulip):

(wg-rustc-dev-guide's doc, that is)

mark-i-m (Apr 08 2020 at 20:53, on Zulip):

We've been going at lightening speed recently!

Santiago Pastorino (Apr 08 2020 at 20:53, on Zulip):

yes!

pnkfelix (Apr 09 2020 at 13:30, on Zulip):

another reminder to @T-compiler/meeting that we'll be starting out weekly meeting in about 30 minutes. :smiley:

mark-i-m (Apr 09 2020 at 13:38, on Zulip):

/me frantically searching for the :t-compiler: emoji

eddyb (Apr 09 2020 at 13:59, on Zulip):

   :gear:
:gear::gear:

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

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

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

Thanks to @WG-prioritization , we have an established agenda

mark-i-m (Apr 09 2020 at 14:02, on Zulip):

There are actually custom emoji settings in the organization settings. Could someone with permissions please make that the :t-compiler: emoji?

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

So lets start off with five minutes for ...

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

Announcements

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

hmm that link is apparently dead

LeSeulArtichaut (Apr 09 2020 at 14:04, on Zulip):

You missed a /content/ directory I guess

eddyb (Apr 09 2020 at 14:04, on Zulip):
Santiago Pastorino (Apr 09 2020 at 14:04, on Zulip):

pnkfelix said:

https://forge.rust-lang.org/compiler/steering-meeting.html

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

@LeSeulArtichaut actually I think the content moved to forge

Santiago Pastorino (Apr 09 2020 at 14:05, on Zulip):

fixed the link in the agenda too, sorry about that

Santiago Pastorino (Apr 09 2020 at 14:05, on Zulip):

got it from the calendar :), fixed the calendar link too

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

specific to the planning meeting, we are always welcome to new meeting proposals

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

(We'll be talking more about P-critical later in the meeting, so if you have questions about it, we'll get to it then.)

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

okay I guess that's it for announcements, it seems

simulacrum (Apr 09 2020 at 14:08, on Zulip):

oh actually

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

one quick announcement: we recently landed support on perf for custom cargo

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

where can I read more?

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

so if you have changes that require changes to how rustc is run (and have a cargo patch), that's now "automatic"

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

https://github.com/rust-lang/rustc-perf/pull/644 I guess, there's not really docs

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

it does the intuitive thingnow

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

thanks!

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

(thanks to @Nicholas Nethercote :heart: !)

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

okay. next up on the agenda: beta-nominations

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

we have one: "macro_rules: NtLifetime cannot start with an identifier" #70768

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

looks good to me, lets backport

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

we have no stable backport nominations

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

We have seven (!) PR's marked S-waiting-on-team

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

waiting 1/7: Fix staticlib name for *-pc-windows-gnu targets #70937

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

wow the label got added five hours ago and yet it this was on the agenda

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

this probably needs decision from folks who are familiar with how windows gnu targets work in the first place
which is likely none of us

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

I guess this is what happens when you delegate to a globally distributed team

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

I generally think mati865 has good knowledge but

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

this repeats the need for ice-breakers for specific targets and areas like windows

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

for now I usually cc @retep007 and a few other folks

nagisa (Apr 09 2020 at 14:17, on Zulip):

the important caveat is that this is -gnu target

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

but I think retep was already cc'd by @Vadim Petrochenkov

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

yeah, true

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

I'm willing to go along with it. But the most important thing is that this gets attention

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

this does fix a regression, too. @Vadim Petrochenkov mentioned:

Ignoring compatibility concerns, this seems to be the right thing to do and the fix should push LLD support for mingw targets over the finish line (or almost over).

Perhaps the best thing to do here would be to land the patch and collect possible complaints in the next 6-12 weeks.
The patch can be trivially reverted if it breaks something critical, or if we decide to prolong the complaint collection period for more release cycles.

nagisa (Apr 09 2020 at 14:17, on Zulip):

most of the windows folks just don’t bother with that target, its the people who are x-compiling from linux who do.

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

should we FCP it?

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

or just do a decision now, in this meeting?

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

(or wait a week and decide next week?)

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

I'd be inclined to go fwd based on petrochenkov's reasoning and because (iirc) we kind of delegated to mati865 to "handle this", didn't we? :)

nagisa (Apr 09 2020 at 14:18, on Zulip):

fcp sounds overbearing to me, I’m in favour of merging this

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

me too, it feels like it wouldn't really add much

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

Okay I'm okay with merging.

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

lets move along then

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

waiting 2/7: A big options clean-up #70729 (also in Nominated Issues list)

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

this is waiting for some people (incl me) to check their boxes

nagisa (Apr 09 2020 at 14:19, on Zulip):

/me just checked

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

/me will look at it after the meeting

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

I think all we need to do here is advertise it

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

waiting 3/7: Move LLVM bitcode destination #70458

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

this already went through FCP, right? The agenda says

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

It's still tagged final-comment-period

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

by "went through FCP", I mean "T-compiler checked off boxes"

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

I'd be ok w/ not waiting -- but then I think we should change definition of "fcp" so it starts from the point someone writes rfcbot fcp merge

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

and thus we probably didn't need it on today's agenda. If anyone here disagrees, let me know

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

(I'm more just making a remarking about what the agenda needs to have, and maybe what S-waiting-on-team is supposed to mean...)

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

Maybe the S-waiting-on-team label should be removed when the team finishes checking off boxes?

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

lets move along, in any case

Santiago Pastorino (Apr 09 2020 at 14:22, on Zulip):

maybe some of those are good to just share here and avoid discussions, like we have this waiting on team because this reason and move on (?)

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

waiting 4/7: Remove -Z no-landing-pads flag #70175

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

similar situation

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

so I'm just sharing here and moving on

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

waiting 5/7: Add Option to Force Unwind Tables #69984

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

this has unchecked check boxes. This one I'm willing to check my box off on now

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

(which should be enough to have to go to the final FCP)

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

waiting 6/7: Add error codes duplicates check #68639

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

this says "Waiting on something from wg-diagnostics?" in the agenda ...

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

It was not clear to me what this PR is waiting on

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

oh I see, we were only added recently as the team

nagisa (Apr 09 2020 at 14:25, on Zulip):

Do we have consensus as to not having duplicate error code usage? I personally feel like that's a pretty odd policy to have, but if @estebank and @rust-lang/wg-diagnostics feel that we should enforce this then I'm not opposed.

nagisa (Apr 09 2020 at 14:25, on Zulip):

I think

centril (Apr 09 2020 at 14:26, on Zulip):

I find that the policy is pretty odd too

centril (Apr 09 2020 at 14:26, on Zulip):

duplicate error codes can be useful

centril (Apr 09 2020 at 14:26, on Zulip):

and it can lead to forcing bad code structure in the compiler

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

I think the intention was to avoid accidental collision or reuse?

nagisa (Apr 09 2020 at 14:26, on Zulip):

it forces you to structure code in weird ways, yes.

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

I'm of two minds

centril (Apr 09 2020 at 14:27, on Zulip):

Like having an fn foobar_error<'a>(...) -> DiagnosticBuilder<'a> just because of that check (even causing architectural problems! of the "rustc_middle crate too big" variety)

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

I won't argue with the point about it forcing odd code structures

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

I've always been of the opinion that non-numeric error codes (which are unlikely to conflict) would be a nice alternative, and I can't quite tell if we are moving in that direction? Is that what "stringy" error codes refers to?

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

But I do wonder -- if not for this check, is there some other way that duplicates will be detected?

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

e.g., when the error code is declared?

centril (Apr 09 2020 at 14:28, on Zulip):

@nikomatsakis https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/get.20rid.20of.20error.20codes

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

(i.e., if two independent PRs should try to add the same error code)

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

@oli wrote:

If we move to stringy error codes, all we need is a check that each has a test emitting it.

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

PS, this is obviously a great use for MCP. Reminds me that I plan to open that RFC today.

simulacrum (Apr 09 2020 at 14:28, on Zulip):

we already should error on duplicate definitions, I believe

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

what does "a check that each has a test emitting it" mean? Why does that resolve the collision issue?

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

Or is that assuming that "stringy error codes" means ones with semantic meaning embedded in the string?

centril (Apr 09 2020 at 14:29, on Zulip):

Example:

simulacrum said:

error[E0502]: cannot borrow `x` as immutable because it is also borrowed as mutable
 --> src/main.rs:4:13
  |
3 |     let a = &mut x;
  |             ------ mutable borrow occurs here
4 |     let b = &x;
  |             ^^ immutable borrow occurs here
5 |     *a = 3;
  |     ------ mutable borrow later used here
error[borrow_check::double_mutable]: cannot borrow `x` as immutable because it is also borrowed as mutable
 --> src/main.rs:4:13
  |
3 |     let a = &mut x;
  |             ------ mutable borrow occurs here
4 |     let b = &x;
  |             ^^ immutable borrow occurs here
5 |     *a = 3;
  |     ------ mutable borrow later used here
error: cannot borrow `x` as immutable because it is also borrowed as mutable
 --> src/main.rs:4:13
  |
3 |     let a = &mut x;
  |             ------ mutable borrow occurs here
4 |     let b = &x;
  |             ^^ immutable borrow occurs here
5 |     *a = 3;
  |     ------ mutable borrow later used here

    help: longer explanation can be viewed via `rustc --explain borrow_check::double_mutable`
oli (Apr 09 2020 at 14:29, on Zulip):

we don't solve the collision issue, afaict we stopped doing that a while back

oli (Apr 09 2020 at 14:30, on Zulip):

but when we move away from the ids (the first step is to just use ids but in strings), then the assumption is that collisions become highly unlikely

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

so, we already stopped detecting duplicate uses some time back, and we are moving to a system where duplicates will be less likely, but we also have htis PR adding back the duplicate check?

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

if so, seems like it's not needed

centril (Apr 09 2020 at 14:30, on Zulip):

@oli I don't think strings are necessary; we can use $p:path

simulacrum (Apr 09 2020 at 14:30, on Zulip):

yeah, so personally, I feel like we can close this (i.e. that it's not necessary)

centril (Apr 09 2020 at 14:30, on Zulip):

more well-formed... but details

simulacrum (Apr 09 2020 at 14:31, on Zulip):

in the sense that AFAIK we should already be checking in other places for this

simulacrum (Apr 09 2020 at 14:31, on Zulip):

but I could be wrong

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

Okay. I guess I will trust wg-diagnostics' expertise here

simulacrum (Apr 09 2020 at 14:31, on Zulip):

I would say that I want a MCP for this and other diagnostics stuff if it does happen

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

(I personally am worried about things like @nagisa 's point regarding variable length codes)

simulacrum (Apr 09 2020 at 14:32, on Zulip):

(or at the very least some docs in rustc-guide, because I personally have no idea what the current state is)

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

(I do however feel pretty strongly like this move to string codes ought to be an MCP that is written up -- i.e., is the convention going to be borrow_check::foo, etc? that seems not obviously correct to me, but whatever we do we had better document it)

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

I at least feel quite happy but surprised to learn it is happening :)

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

in any case, we don't want to get too far afield here

centril (Apr 09 2020 at 14:32, on Zulip):

( @nikomatsakis borrow::double_mut if you fancy something briefer )

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

so to bring the focus back to this PR

simulacrum (Apr 09 2020 at 14:32, on Zulip):

imo, we should move on, and re-assign this PR to someone from wg-diagnostics

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

it sounds like the consensus is that we don't need don't need the check being added here, and can close the PR?

simulacrum (Apr 09 2020 at 14:33, on Zulip):

(and they can decide whether to close or not)

centril (Apr 09 2020 at 14:33, on Zulip):

@oli want to take this perhaps?

simulacrum (Apr 09 2020 at 14:33, on Zulip):

I'm not the right reviewer for the decision, though I can review the technical bits

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

okay I'll assign to @oli and we'll move along

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

waiting 7/7: Ensure all iterations in Rayon iterators run in the presence of panics #68171

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

I was just talking about this PR recently

nagisa (Apr 09 2020 at 14:36, on Zulip):

this sounds to me like something we definitely want to do.

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

I think this is not obviously something we want

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

heh

nagisa (Apr 09 2020 at 14:36, on Zulip):

I’m curious to hear why @nikomatsakis thinks so.

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

during the pre-triage we saw a concrete example of a panic that originates from the parser

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

Well, we don't normally use panics for controlled failures, so this applies only to ICEs. That said, I guess having determinstic ICEs and so forth would still be quite useful. =)

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

and then, for ... reasons ... causes a process abort rather than an ICE

centril (Apr 09 2020 at 14:37, on Zulip):

@pnkfelix not sure that is related though

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

true

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

I wouldn't expect us to be using par_iter within the parser

centril (Apr 09 2020 at 14:38, on Zulip):

don't think it has anything to do with parallelism

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

I don't have a strong objection to the PR, mind you, although I found it made things look less elegant (but that could be refactored)

centril (Apr 09 2020 at 14:38, on Zulip):

@nikomatsakis well... iirc @Zoxc wanted to parallelize parsing or make it "speculate and start early", though that probably means tweaking expansion, not parsing

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

lets at least take @nagisa 's feedback as a sign that we should look more carefully at this PR?

centril (Apr 09 2020 at 14:39, on Zulip):

(though it's probably hard to encode that speculation correctly)

simulacrum (Apr 09 2020 at 14:39, on Zulip):

yeah, I think something like this PR is maybe good, but w/o parallelism (which we've stalled on) it's not too interesting, I think

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

I think that the motivation of "we want output to be as determinstic as possible, even ICEs" kind of persuades me

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

its currently assigned to @simulacrum ; shall we reassign it?

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

but I also do feel like there are larger questions about parallelism and the right strategies there

simulacrum (Apr 09 2020 at 14:39, on Zulip):

I think I'm not necessarily the wrong assignee

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

(that I don't care to revisit at this moment)

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

we could also just let it wait

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

if its parallelism specific

simulacrum (Apr 09 2020 at 14:40, on Zulip):

in some sense, I think, we can either just let it wait or close as "blocked" in some sense

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

then we can just couple it with other parallelism stuff

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

that has to be resolved at a later time

centril (Apr 09 2020 at 14:40, on Zulip):

Poor Zoxc gets all their PRs blocked, heh :slight_smile:

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

for various reasons I'm going to leave #68171 unchanged for now. I will follow up on it later.

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

Okay, next on agenda

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

Issues of Note

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

(notably, the P-high stable-to-beta issue is assigned and does have a backport pending.)

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

do the regressions have folks assigned?

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

two of the P-high stable-to-nightly regressions are unassigned

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

I guess that would ordinarily be part of the P-critical coverage

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

going to add that in general to the structure, note the ones unassigned here

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

unassigned P-high stable-to-nightly regression 1/2:
Compile regression "cannot infer an appropriate lifetime for lifetime parameter" #70917

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

oh right, this is the one that's nominated for T-lang to discuss

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

oh this is blocked on lang tea- yeah

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

I will respond on #70917, taking a look now

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

unassigned P-high stable-to-nightly regression 2/2: file not found for module #70314

Santiago Pastorino (Apr 09 2020 at 14:47, on Zulip):

actually out of the unassigned ones I think yeah are on T-lang

Santiago Pastorino (Apr 09 2020 at 14:47, on Zulip):

well maybe that one is not

centril (Apr 09 2020 at 14:47, on Zulip):

pnkfelix said:

unassigned P-high stable-to-nightly regression 2/2: file not found for module #70314

self assigned

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

thanks @centril

centril (Apr 09 2020 at 14:48, on Zulip):

mostly to investigate "is this a bug" and then to fix if so

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

okay lets jump to the nominated issues

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

there are 7 (but one is a duplicate with waiting-on-team)

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

nom 1/7: "Compile regression "cannot infer an appropriate lifetime for lifetime parameter"" #70917

centril (Apr 09 2020 at 14:48, on Zulip):

just discussed

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

yeah but there was a reason

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

oh no I was thinking of the next one

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

okay right, we can move along post #70917

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

nom 2/7: "PhantomData<T> no longer dropck?" #70841

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

so this one is interesting in a meta-sense

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

@WG-prioritization was debating

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

this seemed like a potential release blocker, if it had been caught on beta or nightly

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

and thus something that we would tag as P-critical in that scenario

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

however, #70841 leaked into stable, some time ago

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

and the question was: "should we still mark as P-critical"

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

even though, in my opinion, we "obviously" would not block a new release on a bug that is already present in the current release

centril (Apr 09 2020 at 14:51, on Zulip):

Imo should be P-critical; soundness hole, doesn't seem too contrived to walk into by accident, and if we let this wait I suspect it will take a long time

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

I've been wavering back and forth on this, but overall I think I agree with @centril here

centril (Apr 09 2020 at 14:51, on Zulip):

I don't know whether that means it blocks a release, but I think it should be "drop most of other things"

simulacrum (Apr 09 2020 at 14:52, on Zulip):

I don't really see why it should block a release, though, given its not a current regression

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

which would then imply that P-critical does not in every case mean "release blocker"

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

I think I agree. It's a trcky one, but the combination of "not too hard to hit by accident" and "wish to avoid as much as possible people relying on the behavior"

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

but its slightly more nuanced

Santiago Pastorino (Apr 09 2020 at 14:52, on Zulip):

I think I agree with P-critical and also if the definition of P-critical is like potentially release blocker this will be revisited and maybe not block the release

centril (Apr 09 2020 at 14:52, on Zulip):

@simulacrum I agree with you there; but I think "blocks release" is too narrow -- almost nothing fits

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

(I think it is good for P-critical to have a narrow scope)

eddyb (Apr 09 2020 at 14:53, on Zulip):

I don't understand why this is a bug

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

Well, hmm. I'm not sure. Maybe this is the slippery slope that leads to useless tags

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

@eddyb heh. Maybe its not a bug

eddyb (Apr 09 2020 at 14:53, on Zulip):

given the explanation in https://github.com/rust-lang/rust/issues/70841#issuecomment-610004241

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

I want to look at it more

simulacrum (Apr 09 2020 at 14:53, on Zulip):

Sure. I don't object to it as a high priority thing just not something we must fix before another release

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

In any case we should definitely try to ensure someone is investigating it

eddyb (Apr 09 2020 at 14:53, on Zulip):

there's no actual Drop so why would it error

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

PhantomData is special

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

I'm going to self assign this to try to understand what happened

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

and determine if it is a bug or not

eddyb (Apr 09 2020 at 14:54, on Zulip):

I'm not sure we should use I-unsound if it can't be abused

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

I'm not 100% it should error, have to go refresh memory, but I think it may be important that it does

centril (Apr 09 2020 at 14:54, on Zulip):

@eddyb you might want to leave a comment as well possibly

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

(I had hoped to look at it before this meeting, but ... childcare ...)

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

I think it can lead to cycles that are undetected, in particular

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

That is, the idea was that unsafe code can use phantom-data to indicate "a value of type T will be dropped"

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

anyway, its assigned now, and I think we agree that we can, for now assign an issue like this P-critical

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

(and that this in turn has meaning that might prevent cycles)

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

(and then, after someone investigates and confirms that it isn't actually a bug, then potentially close or downgrade...)

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

sound okay?

centril (Apr 09 2020 at 14:56, on Zulip):

sounds great

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

let's try it, but I think we sohuld specify why -- it's definitely not just "unsound"

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

yeah we need to work out the nuance of what makes a bug P-critical

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

there is a dedicated topic to that question

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

e.g. here it still errors https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=58bc5a72ab4ace6ae402dda1986427fa

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

because there could be code that runs

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

dedicated topic to p-critical's meaning: https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/meaning.20of.20p-critical/near/193381978

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

I see, it has no Drop defined

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

(ok, @eddyb may be correct that this is not a bug)

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

making needs_drop::<PhantomData<T>>() == needs_drop::<T>() seems far more breaking than this "bug"

eddyb (Apr 09 2020 at 14:58, on Zulip):

because it would disallow Copy in cases where it's allowed today, if I'm not mistaken

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

lets maybe not try to resolve these questions right here

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

given that we have ... 2 minutes left ...

eddyb (Apr 09 2020 at 14:58, on Zulip):

sigh

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

we already discussed “A big options clean-up” #70729

eddyb (Apr 09 2020 at 14:59, on Zulip):

some of the things to discuss could maybe overflow into tomorrow, unless that's also undesireable

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

there are four remaining nominated issues

pnkfelix (Apr 09 2020 at 14:59, on Zulip):
pnkfelix (Apr 09 2020 at 15:00, on Zulip):

I admit, I'm a little surprised to see WIP stuff here

eddyb (Apr 09 2020 at 15:00, on Zulip):

the first one should be really quick

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

is it looking for general feedback from the team or something?

eddyb (Apr 09 2020 at 15:00, on Zulip):

as opposed to a bikeshed

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

okay lets look at #70953 then

eddyb (Apr 09 2020 at 15:00, on Zulip):

the proposal is to add "which query are we in" information to all ICEs by default

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

oh I see

eddyb (Apr 09 2020 at 15:01, on Zulip):

because it keeps coming up as "this is very helpful information but it's harder to get at than reasonable"

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

the point is that not everyone goes through the step of making a backtrace when they report a bug?

eddyb (Apr 09 2020 at 15:01, on Zulip):

that's part of it yeah

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

and therefore there is potentially a big payoff?

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

sounds fine to me. Anyone who objects should perhaps post a comment on the issue (or here)?

eddyb (Apr 09 2020 at 15:01, on Zulip):

the other thing is that users could guess where in their code they're triggering the ICE

nikomatsakis (Apr 09 2020 at 15:01, on Zulip):

+1 from me

pnkfelix (Apr 09 2020 at 15:02, on Zulip):

eddyb said:

the other thing is that users could guess where in their code they're triggering the ICE

Oh i suppose that's true too. That would also be good, if true.

eddyb (Apr 09 2020 at 15:02, on Zulip):

to work around it in the meanwhile or know which error to fix (in case it's a side-effect of an error) to get rid of it

pnkfelix (Apr 09 2020 at 15:02, on Zulip):

what about Zoxc's concern regarding a potential panic?

pnkfelix (Apr 09 2020 at 15:02, on Zulip):

should the top most element always be accessible without a panic?

eddyb (Apr 09 2020 at 15:02, on Zulip):

their comment states it's not a problem w/o RUST_BACKTRACE=1

pnkfelix (Apr 09 2020 at 15:03, on Zulip):

gotcha

eddyb (Apr 09 2020 at 15:03, on Zulip):

it's not about grabbing it but rather printing it

pnkfelix (Apr 09 2020 at 15:03, on Zulip):

okay. the word "Getting" in "Getting / printing the query stack" is what worried me

pnkfelix (Apr 09 2020 at 15:03, on Zulip):

Alright well we are over time

eddyb (Apr 09 2020 at 15:03, on Zulip):

oh yeah that's just going to result in an Option basically and we can just omit it

pnkfelix (Apr 09 2020 at 15:04, on Zulip):

I decided not to worry about the WG check'ins too much

pnkfelix (Apr 09 2020 at 15:04, on Zulip):

because, due to some infrastructure issues, we already heard from these teams recently

pnkfelix (Apr 09 2020 at 15:04, on Zulip):

but I think one of them does have somethign to report ... right?

pnkfelix (Apr 09 2020 at 15:04, on Zulip):

@mark-i-m ?

mark-i-m (Apr 09 2020 at 15:05, on Zulip):

We've done a lot

mark-i-m (Apr 09 2020 at 15:05, on Zulip):

Accomplished

mark-i-m (Apr 09 2020 at 15:05, on Zulip):
mark-i-m (Apr 09 2020 at 15:05, on Zulip):
mark-i-m (Apr 09 2020 at 15:05, on Zulip):
mark-i-m (Apr 09 2020 at 15:05, on Zulip):
mark-i-m (Apr 09 2020 at 15:05, on Zulip):
mark-i-m (Apr 09 2020 at 15:06, on Zulip):
mark-i-m (Apr 09 2020 at 15:06, on Zulip):

Next steps:

mark-i-m (Apr 09 2020 at 15:06, on Zulip):
mark-i-m (Apr 09 2020 at 15:06, on Zulip):
mark-i-m (Apr 09 2020 at 15:06, on Zulip):
mark-i-m (Apr 09 2020 at 15:06, on Zulip):
mark-i-m (Apr 09 2020 at 15:06, on Zulip):

<EOM>

pnkfelix (Apr 09 2020 at 15:07, on Zulip):

Okay, thanks @mark-i-m !!!

pnkfelix (Apr 09 2020 at 15:07, on Zulip):

and thanks to everyone in @T-compiler/meeting for attending!!! Great meeting alll, thanks for your patience

Santiago Pastorino (Apr 09 2020 at 15:08, on Zulip):

I want to thank and congratulate @WG-rustc-dev-guide the progress the group is making is amazing!!!

Santiago Pastorino (Apr 09 2020 at 15:10, on Zulip):

the progress @mark-i-m have shared is since last checkin that happened 2 weeks ago (that is due to an error in the js that handles checkins)

Peter Rabbit (Apr 20 2020 at 01:52, on Zulip):

nikomatsakis said:

for now I usually cc retep007 and a few other folks

When are y'all gonna learn the difference between me and retep007?

nikomatsakis (Apr 20 2020 at 22:24, on Zulip):

probably never

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

is retep007 also a bunny?

pnkfelix (Apr 21 2020 at 15:21, on Zulip):

(perhaps a superspy bunny?)

nagisa (Apr 21 2020 at 15:35, on Zulip):

I don't believe so.

pnkfelix (Apr 21 2020 at 15:35, on Zulip):

okay so that makes things simple

pnkfelix (Apr 21 2020 at 15:35, on Zulip):

one is a bunny, the other is a british secret agent. Super easy to remember.

Last update: May 29 2020 at 18:00UTC