Stream: t-compiler

Topic: weekly meeting 2019-03-14 #54818


pnkfelix (Mar 14 2019 at 12:02, on Zulip):

hi @T-compiler/meeting , our weekly meeting will be held in this topic area in about two hours

pnkfelix (Mar 14 2019 at 12:03, on Zulip):

I'm going to start the pre-triage process in another topic on this stream.

pnkfelix (Mar 14 2019 at 12:11, on Zulip):

i just realized I forgot to actually reach out to any WG leads on tuesday

pnkfelix (Mar 14 2019 at 12:11, on Zulip):

so maybe we won't have any WG-checkins today, unless I find some volunteers in next ~100 minutes

davidtwco (Mar 14 2019 at 12:12, on Zulip):

We discussed a working group check-in schedule in the #t-compiler/wg-meta meeting and I threw this together (compiler-team#37) at the weekend but there's been no discussion or review so I assume we won't be following it this week.

davidtwco (Mar 14 2019 at 12:12, on Zulip):

The next #t-compiler/wg-meta meeting is tonight so there will likely be a look at it then.

davidtwco (Mar 14 2019 at 12:15, on Zulip):

According to that though, there's a wg-async-await and wg-llvm check-in (I just went around the list, so there's no particular reason for the order). wg-async-await had a meeting on Tuesday and there are notes from that which could be used in a check-in if we wanted.

pnkfelix (Mar 14 2019 at 12:19, on Zulip):

I like the idea of hearing from wg-async-await

pnkfelix (Mar 14 2019 at 12:20, on Zulip):

heck I like both of the suggestions for today from compiler-team#37

pnkfelix (Mar 14 2019 at 12:21, on Zulip):

hey @nikomatsakis and @nagisa , would you two be willing to provide WG-checkins today (for wg-async-await and wg-llvm, respectively) ?

nikomatsakis (Mar 14 2019 at 12:21, on Zulip):

yep

pnkfelix (Mar 14 2019 at 13:07, on Zulip):

also, @nikomatsakis , do you want to try to allocate time during either a steering or a triage meeting to figure out planning for #58465? or should we switch to resolving that asynchronously?

pnkfelix (Mar 14 2019 at 13:49, on Zulip):

:question: request for volunteer to fix: "ICE on beta and nightly: index out of bounds in RestoreSubsliceArrayMoveOut MIR pass" #59048

pnkfelix (Mar 14 2019 at 13:59, on Zulip):

:question: request for volunteer to fix: "Compiler panic when using a slice pattern" #59016

pnkfelix (Mar 14 2019 at 14:00, on Zulip):

:question: request for volunteer to fix: "Building Firefox with rustc 1.34.0-nightly fails with LLVM ERROR: broken function found." #58881

pnkfelix (Mar 14 2019 at 14:01, on Zulip):

okay high hi @T-compiler/meeting

pnkfelix (Mar 14 2019 at 14:01, on Zulip):

I didn't finish all the triage that I wanted but I don't want to delay further

nikomatsakis (Mar 14 2019 at 14:02, on Zulip):

also, nikomatsakis , do you want to try to allocate time during either a steering or a triage meeting to figure out planning for #58465? or should we switch to resolving that asynchronously?

@pnkfelix I don't think a triage meeting is really the right place. It's probably something we should talk about at the next steering meeting.

nikomatsakis (Mar 14 2019 at 14:02, on Zulip):

which is next week, actually

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

It's probably something we should talk about at the next steering meeting.

okay

nikomatsakis (Mar 14 2019 at 14:03, on Zulip):

I've already added it to the list of steering meeting agenda ideas, feel free to un-nominate

pnkfelix (Mar 14 2019 at 14:03, on Zulip):

so I was working my way through the nominated issues, as people can see on the pretriage topic

nagisa (Mar 14 2019 at 14:03, on Zulip):

Checkin for WG-llvm (since i won’t be able to participate in the meeting): @dlrobertson has upstreamed some work in instcombine between satirating ops and regular ops. That’s all to my knowledge.

pnkfelix (Mar 14 2019 at 14:03, on Zulip):

@nagisa okay thanks

dlrobertson (Mar 14 2019 at 14:04, on Zulip):

@Nikita Popov has also done some work

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

Regarding the P-high issues, there are still a bunch I didn't look at, but only one of the ones remaining is unassigned is "ICE: Existential type (w/ and w/o NLL)" #53598

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

so lets go ahead and put up another call-for-volunteer effort:

pnkfelix (Mar 14 2019 at 14:05, on Zulip):

:question: request for volunteer to fix: "ICE: Existential type (w/ and w/o NLL)" #53598

nikomatsakis (Mar 14 2019 at 14:05, on Zulip):

hmm. I'm not sure if this should be P-high or what

pnkfelix (Mar 14 2019 at 14:05, on Zulip):

If anyone is looking for a (hopefully self-contained) bug to fix, go ahead and skim the :question:s above

nikomatsakis (Mar 14 2019 at 14:06, on Zulip):

(but I approve of this "request for volunteer to fix" idea, and I think we should probably try to raise the visibility on that)

nikomatsakis (Mar 14 2019 at 14:06, on Zulip):

/me ponders a T-compiler twitter account :)

pnkfelix (Mar 14 2019 at 14:06, on Zulip):

hmm. I'm not sure if this should be P-high or what

you mean because of its dependence on feature(existential_type) ?

nikomatsakis (Mar 14 2019 at 14:06, on Zulip):

Yes.

pnkfelix (Mar 14 2019 at 14:06, on Zulip):

I'm wondering if it might be reducable to something with impl Trait alone

nikomatsakis (Mar 14 2019 at 14:06, on Zulip):

I feel like it's sort of a "this would be p-high for a WG working on trying to stabilize existential type, but no such WG exists"

nikomatsakis (Mar 14 2019 at 14:07, on Zulip):

i.e., when we decide to make that a priority, it'd be good, and maybe we can "pre-triage" it a bit so that when that happens we're ready

pnkfelix (Mar 14 2019 at 14:07, on Zulip):

is stabilizing existential types in some form on the agenda for this year? or the next edition?

pnkfelix (Mar 14 2019 at 14:08, on Zulip):

I've been assuming it is, given the attention given to the proposed type T = impl Trait; syntax

pnkfelix (Mar 14 2019 at 14:08, on Zulip):

well in any case I gave it P-high assignment because, like I said, I worried it might represent a deeper impl Trait bug

pnkfelix (Mar 14 2019 at 14:09, on Zulip):

though I think I'm now realizing that this ... cannot be the case?

nikomatsakis (Mar 14 2019 at 14:09, on Zulip):

is stabilizing existential types in some form on the agenda for this year? or the next edition?

I think it could be, yes, but we need to plan for that. (Which intersects this "pipelined compilation" question I was thinking about for steering meeting.)

nikomatsakis (Mar 14 2019 at 14:09, on Zulip):

Basically the meta question is "how do we manage the resources we have". That was the original vision for what we would do in our steering meetings :)

nikomatsakis (Mar 14 2019 at 14:10, on Zulip):

well in any case I gave it P-high assignment because, like I said, I worried it might represent a deeper impl Trait bug

Yeah, I don't know, I was assuming it had something to do with the specifics of where impl Trait appears

nikomatsakis (Mar 14 2019 at 14:10, on Zulip):

er, that is, with using existential type in that particular position. I could be wrong. @oli would probably have a good guess.

pnkfelix (Mar 14 2019 at 14:11, on Zulip):

yeah okay my quick immediate attempts to reduce to a simpler form using impl Trait alone did not do the trick

pnkfelix (Mar 14 2019 at 14:11, on Zulip):

so I'll now assume that this really is tied to feature(existential_type)

oli (Mar 14 2019 at 14:12, on Zulip):

yes, impl trait is currently not usable in associated types

pnkfelix (Mar 14 2019 at 14:12, on Zulip):

which means I agree its not P-high, at least not until we see some sort of plan for stabilizing that feature

oli (Mar 14 2019 at 14:12, on Zulip):

existential types and using impl trait in associated types is equivalent

oli (Mar 14 2019 at 14:12, on Zulip):

it should be a blocker for stabilizing existential types

oli (Mar 14 2019 at 14:12, on Zulip):

but not P-high imo

pnkfelix (Mar 14 2019 at 14:12, on Zulip):

Thus, downgrading #53598 to P-medium, and adding as blocker to tracking issue for existential type feature.

pnkfelix (Mar 14 2019 at 14:14, on Zulip):

Okay so that's all the time I want to spend on P-high stuff for now

pnkfelix (Mar 14 2019 at 14:14, on Zulip):

lets see about the beta nominations

pnkfelix (Mar 14 2019 at 14:14, on Zulip):

/poll how does this work

varkor (Mar 14 2019 at 14:15, on Zulip):

one thing I noticed about polls last week is that they don't show up on mobile

varkor (Mar 14 2019 at 14:15, on Zulip):

(and there's no indication there should be a poll)

pnkfelix (Mar 14 2019 at 14:15, on Zulip):

/poll "resolve: Account for new importable entities" #59047

nikomatsakis (Mar 14 2019 at 14:16, on Zulip):

one thing I noticed about polls last week is that they don't show up on mobile

hmm seems bad

pnkfelix (Mar 14 2019 at 14:16, on Zulip):

@varkor oh no that is unfortunate. Do the emojis show up on mobile? And are they clickable by mobile clients?

Esteban Küber (Mar 14 2019 at 14:16, on Zulip):

Yes

varkor (Mar 14 2019 at 14:16, on Zulip):

okay, so checking again: the polls are now visible on mobile, but show up as bullet points (that can't be interacted with)

varkor (Mar 14 2019 at 14:16, on Zulip):

so emoji reactions are best for now

pnkfelix (Mar 14 2019 at 14:17, on Zulip):

well maybe I can use emojis on the poll?

pnkfelix (Mar 14 2019 at 14:18, on Zulip):

oh dear does the poll also not render the emojis I put into the poll items? WTF...

nikomatsakis (Mar 14 2019 at 14:18, on Zulip):

we gotta file some bugs about polls :)

pnkfelix (Mar 14 2019 at 14:18, on Zulip):

oh dear does the poll also not render the emojis I put into the poll items? WTF...

that's gotta be a bug

nikomatsakis (Mar 14 2019 at 14:18, on Zulip):

so how are we doing this :)

pnkfelix (Mar 14 2019 at 14:19, on Zulip):

I guess we'll use emojis

pnkfelix (Mar 14 2019 at 14:19, on Zulip):

lets continue

pnkfelix (Mar 14 2019 at 14:19, on Zulip):

"Always emit unclosed delimiter diagnostics" #58903

pnkfelix (Mar 14 2019 at 14:20, on Zulip):

"Do not accidentally treat multi-segment meta-items as single-segment" #58899 (the first three commits)

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

(by the way, if people would prefer a discussion period after each item, rather than me issuing them in sequence... well, i don't know if we have time for me to pause signfiicantly between each. I think best to just speak up, maybe.)

Vadim Petrochenkov (Mar 14 2019 at 14:21, on Zulip):

(the first three commits)

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

(the first three commits)

ah thanks for clarifying; edited accordingly.

pnkfelix (Mar 14 2019 at 14:22, on Zulip):

"Expand where negative supertrait specific error is shown" #58861

nikomatsakis (Mar 14 2019 at 14:22, on Zulip):

(the first three commits)

am I correct @Vadim Petrochenkov that #58899 seems to close a lot of regressions?

nikomatsakis (Mar 14 2019 at 14:24, on Zulip):

It seems like a hefty diff (although I need to check which changes are due to just the 1st 3 commits, I guess) but also seems probably worthwhile, is why I ask.

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

Many kinds of regressions, yes, but each kind is not too likely.
Crater didn't find any regressions fixes.

nikomatsakis (Mar 14 2019 at 14:25, on Zulip):

(by the way, if people would prefer a discussion period after each item, rather than me issuing them in sequence... well, i don't know if we have time for me to pause signfiicantly between each. I think best to just speak up, maybe.)

My vote: I like this way -- I think we should set "fixed time period" like this, e.g. 10-15 minutes to give people time to peruse, with the option to ask for more. =)

pnkfelix (Mar 14 2019 at 14:26, on Zulip):

what does "this way" mean

pnkfelix (Mar 14 2019 at 14:26, on Zulip):

I assume you mean "keep doing what you're doing"

nikomatsakis (Mar 14 2019 at 14:26, on Zulip):

posting all the backports at the beginning

pnkfelix (Mar 14 2019 at 14:26, on Zulip):

okay

nikomatsakis (Mar 14 2019 at 14:26, on Zulip):

to persue at our liesure

nikomatsakis (Mar 14 2019 at 14:26, on Zulip):

I just feel like chats over zulip it's often hard to tell when we've waited "long enough"

pnkfelix (Mar 14 2019 at 14:26, on Zulip):

anyway it looks like people are generally in favor of backporting all of these

pnkfelix (Mar 14 2019 at 14:27, on Zulip):

luckily due to the daylight saving time disfunction I have extra time post meeting today to follow up on this stuff

pnkfelix (Mar 14 2019 at 14:27, on Zulip):

so lets move along and i'll tag them all after meeting is done

mw (Mar 14 2019 at 14:27, on Zulip):

#58899 seems pretty big for a backport

pnkfelix (Mar 14 2019 at 14:27, on Zulip):

#58899 seems pretty big for a backport

even just the first three commits you mean, right?

pnkfelix (Mar 14 2019 at 14:28, on Zulip):

second commit is unit tests

nikomatsakis (Mar 14 2019 at 14:28, on Zulip):

#58899 seems pretty big for a backport

the third commit in particular is not small

nikomatsakis (Mar 14 2019 at 14:28, on Zulip):

(which is why I was asking about the "magnitude" of changes fixed)

pnkfelix (Mar 14 2019 at 14:28, on Zulip):

yes. much may be mechanical?

Vadim Petrochenkov (Mar 14 2019 at 14:28, on Zulip):

(Actually, the first three commits are no longer first, GitHub reordered all the things again.)

pnkfelix (Mar 14 2019 at 14:28, on Zulip):

I see lots of s/.name()/.ident_str()/

pnkfelix (Mar 14 2019 at 14:29, on Zulip):

(Actually, the first three commits are no longer first, GitHub reordered all the things again.)

Oh no!

mw (Mar 14 2019 at 14:29, on Zulip):

:)

pnkfelix (Mar 14 2019 at 14:29, on Zulip):

I think you need to provide more specific indication of your intentions then

pnkfelix (Mar 14 2019 at 14:29, on Zulip):

e.g. list the commits to cherry pick

pnkfelix (Mar 14 2019 at 14:29, on Zulip):

or even ... post the PR itself you're proposing for backport...?

nikomatsakis (Mar 14 2019 at 14:30, on Zulip):

either of those would definitely be helpful:)

Vadim Petrochenkov (Mar 14 2019 at 14:30, on Zulip):

post the PR itself you're proposing for backport...?

Yeah, I'll do that.
I also realized that the PR breaks clippy and clippy cannot be broken on beta, so some removed APIs will also need to be resurrected.

pnkfelix (Mar 14 2019 at 14:31, on Zulip):

okay lets maybe table discussion of #58899 for now

pnkfelix (Mar 14 2019 at 14:31, on Zulip):

we won't approve that for back port this week

pnkfelix (Mar 14 2019 at 14:31, on Zulip):

but we won't explicitly reject it either

pnkfelix (Mar 14 2019 at 14:31, on Zulip):

sound okay?

pnkfelix (Mar 14 2019 at 14:31, on Zulip):

okay we don't have any stable backport nominations

pnkfelix (Mar 14 2019 at 14:32, on Zulip):

Oh!

pnkfelix (Mar 14 2019 at 14:32, on Zulip):

there is one P-high issue I did want to discuss

pnkfelix (Mar 14 2019 at 14:33, on Zulip):

or actually, its on the nominated list

pnkfelix (Mar 14 2019 at 14:33, on Zulip):

we'll get to it then

pnkfelix (Mar 14 2019 at 14:34, on Zulip):

the stable-to-beta regressions look under control

pnkfelix (Mar 14 2019 at 14:35, on Zulip):

and I think i already touched on the stable-to-nightly regressions either in my request-for-volunteers above or in the pre-triage topic

pnkfelix (Mar 14 2019 at 14:35, on Zulip):

under waiting for our team there is still one issue

pnkfelix (Mar 14 2019 at 14:35, on Zulip):

namely "[do not merge] Measure performance impact of local interners" #57214

pnkfelix (Mar 14 2019 at 14:36, on Zulip):

there was a ping two weeks ago to Ping @eddyb @nagisa @nikomatsakis @pnkfelix Your vote is needed

pnkfelix (Mar 14 2019 at 14:37, on Zulip):

(I'm willing to give up a 5% memory increase to reduce our internal API complexity, yes. I'll go ahead and vote now)

eddyb (Mar 14 2019 at 14:37, on Zulip):

huh I thought I looked at all FCP items

pnkfelix (Mar 14 2019 at 14:37, on Zulip):

there's discussion in the ticket

pnkfelix (Mar 14 2019 at 14:37, on Zulip):

rfcbot doesn't show rfcbot polls

eddyb (Mar 14 2019 at 14:37, on Zulip):

it was way worse than 5% when I added local interners :P

mw (Mar 14 2019 at 14:37, on Zulip):

@nagisa raised concerns that we already use too much memory

eddyb (Mar 14 2019 at 14:38, on Zulip):

or at least I'm not sure, but 90-something% of all interned things had inference variables

pnkfelix (Mar 14 2019 at 14:38, on Zulip):

maybe we should dedicate some time to discuss this , but not on the fly?

eddyb (Mar 14 2019 at 14:38, on Zulip):

if we're moving towards more canonicalization, local interners seem less useful and maybe we can eventually get rid of inference variables

mw (Mar 14 2019 at 14:38, on Zulip):

@nikomatsakis this would be improved by removing regions from type inference, right?

nikomatsakis (Mar 14 2019 at 14:38, on Zulip):

nagisa raised concerns that we already use too much memory

I think this is a fair point, but also I wonder if we should address this by focusing on reducing memory usage in specific cases

eddyb (Mar 14 2019 at 14:38, on Zulip):

I'm definitely for making progress in this area one way or another

nikomatsakis (Mar 14 2019 at 14:39, on Zulip):

If I recall, at least in the past, we often had problems because of gigantic constants

nikomatsakis (Mar 14 2019 at 14:39, on Zulip):

And we had planned to address that "once miri is better" and so forth

nikomatsakis (Mar 14 2019 at 14:39, on Zulip):

a lot of the pieces are probably in place now?

nikomatsakis (Mar 14 2019 at 14:39, on Zulip):

(not sure)

nikomatsakis (Mar 14 2019 at 14:40, on Zulip):

that said, I agree with @nagisa that we should be paying attention to this and looking for opportunities to improve.

nikomatsakis (Mar 14 2019 at 14:40, on Zulip):

maybe we should dedicate some time to discuss this , but not on the fly?

yeah, it's an interesting question how to handle this change responsibly. I think there are strong reasons to do this that go beyond just simplifying the codebase (though that is a good one).

oli (Mar 14 2019 at 14:40, on Zulip):

miri has its own per-evaluation-local memory, so we only intern the result of an evaluation and even that one is deduplicated

pnkfelix (Mar 14 2019 at 14:41, on Zulip):

Okay. I don't know if the thursday meeting is best, or if @nikomatsakis wants to dedicate time during steering meeting

pnkfelix (Mar 14 2019 at 14:41, on Zulip):

but maybe lets move along. I can leave this once again tagged as "waiting-on-team"

pnkfelix (Mar 14 2019 at 14:41, on Zulip):

because there's a bunch of nominated issues

pnkfelix (Mar 14 2019 at 14:42, on Zulip):

I mentioned "Specific code layout can cause compiler panic with lto=true" #59137 elsewhere

pnkfelix (Mar 14 2019 at 14:42, on Zulip):

it appears to potentially be due to interaction between dylib and lto

mw (Mar 14 2019 at 14:42, on Zulip):

yeah, that might be a regression

nikomatsakis (Mar 14 2019 at 14:42, on Zulip):

miri has its own per-evaluation-local memory, so we only intern the result of an evaluation and even that one is deduplicated

(I think it had more to do with building a ton of MIR for very simple, but large constants)

pnkfelix (Mar 14 2019 at 14:42, on Zulip):

I want to know who should tackle it

mw (Mar 14 2019 at 14:42, on Zulip):

I'd like to fix it by removing support for Rust dylibs :P

pnkfelix (Mar 14 2019 at 14:42, on Zulip):

I'd like to fix it by removing support for Rust dylibs :P

... this does not sound realistic to me ...?

mw (Mar 14 2019 at 14:43, on Zulip):

I know :/ (although @Alex Crichton is on my side)

pnkfelix (Mar 14 2019 at 14:43, on Zulip):

but

nikomatsakis (Mar 14 2019 at 14:43, on Zulip):

Is it very hard to fix, @mw ?

mw (Mar 14 2019 at 14:44, on Zulip):

I don't know

pnkfelix (Mar 14 2019 at 14:44, on Zulip):

i did mention somewhere that maybe we should say that lto is incompatible with dylibs?

mw (Mar 14 2019 at 14:44, on Zulip):

but I guess you can assign it to me

pnkfelix (Mar 14 2019 at 14:44, on Zulip):

that at least sounds more reasonable than outright removing dylib support

eddyb (Mar 14 2019 at 14:44, on Zulip):

we can remove optimizations (e.g. metadata compression, if we still do that) from dylibs, and whatnot, but I don't think we can ever remove the crate type or break it

pnkfelix (Mar 14 2019 at 14:44, on Zulip):

Great I will assign to @mw who will presumably brainwash us all into believing we can remove dylib support

mw (Mar 14 2019 at 14:45, on Zulip):

maybe we can deprecate them (and only use them in the compiler, if we have to)

pnkfelix (Mar 14 2019 at 14:45, on Zulip):

next nominated issue: "cargo fix --edition failure (probably macros related)" #59065

pnkfelix (Mar 14 2019 at 14:46, on Zulip):

(I know we are at the 45 minute mark. Lets spend 5 more minutes on nominations since we won't be hearing from WG-llvm today)

pnkfelix (Mar 14 2019 at 14:47, on Zulip):

i mentioned #59065 during pretriage

pnkfelix (Mar 14 2019 at 14:47, on Zulip):

it struck me as a likely rustfix bug of some kind

pnkfelix (Mar 14 2019 at 14:47, on Zulip):

where we are rewriting Box<dyn Trait> to Box<r#dyn Trait>

pnkfelix (Mar 14 2019 at 14:47, on Zulip):

is @Zack M. Davis around?

nikomatsakis (Mar 14 2019 at 14:48, on Zulip):

I wonder if that is related to any of the changes @Vadim Petrochenkov made?

pnkfelix (Mar 14 2019 at 14:48, on Zulip):

anyway #59065 needs prioritization

nikomatsakis (Mar 14 2019 at 14:48, on Zulip):

i.e., in the "maybe backport" PR

pnkfelix (Mar 14 2019 at 14:48, on Zulip):

hmm maybe

nikomatsakis (Mar 14 2019 at 14:48, on Zulip):

I'm only saying that because I saw mention of raw identifiers

nikomatsakis (Mar 14 2019 at 14:48, on Zulip):

just a guess :)

nikomatsakis (Mar 14 2019 at 14:49, on Zulip):

seems surprising

pnkfelix (Mar 14 2019 at 14:49, on Zulip):

yeah I'll say

nikomatsakis (Mar 14 2019 at 14:49, on Zulip):

I mean, this doesn't look like "strange" code

nikomatsakis (Mar 14 2019 at 14:49, on Zulip):

feels like we need to investigate this

pnkfelix (Mar 14 2019 at 14:49, on Zulip):

I would have thought it would have been hit during testing of rustfix

pnkfelix (Mar 14 2019 at 14:49, on Zulip):

Okay lets make #59065 P-high then

nikomatsakis (Mar 14 2019 at 14:50, on Zulip):

oh hmm the nightly they used is .. neither old nor new aadbc459b 2019-02-23

pnkfelix (Mar 14 2019 at 14:50, on Zulip):

I'm going to skip the nominated issues that I already posted volunteer requests for (the :question:-marked things)

nikomatsakis (Mar 14 2019 at 14:50, on Zulip):

(I'm going to try and reproduce)

pnkfelix (Mar 14 2019 at 14:51, on Zulip):

I haven't made progress yet on "Incorporate RLS bug tracking into compiler team triage" #58858; hopefully I will figure out a way to stuff that into our agenda by next week.

pnkfelix (Mar 14 2019 at 14:51, on Zulip):

next is "Derives on deprecated items generate deprecation warnings" #58822

pnkfelix (Mar 14 2019 at 14:52, on Zulip):

but I don't think that needs nomination, it seems like its under control

nikomatsakis (Mar 14 2019 at 14:52, on Zulip):

sounds right

pnkfelix (Mar 14 2019 at 14:52, on Zulip):

so now the issue I wanted to talk about: "fn generated by macro exported from crate loses global #![allow(non_snake_case)]" #58502

pnkfelix (Mar 14 2019 at 14:52, on Zulip):

there's two points I wanted to bring up here

pnkfelix (Mar 14 2019 at 14:53, on Zulip):

1. sort of interesting: A change (and I think a good change) to the span for a lint actually can regress code

pnkfelix (Mar 14 2019 at 14:53, on Zulip):

due to the way that we filter out lints that are fired on code that originated from macro-expansions we got from other crates

pnkfelix (Mar 14 2019 at 14:54, on Zulip):

I spent some time (probably way too much time) investigating an architecture for mitigating this scenario

nikomatsakis (Mar 14 2019 at 14:54, on Zulip):

1. sort of interesting: A change (and I think a good change) to the span for a lint actually can regress code

yeah, this was pretty interesting to me

pnkfelix (Mar 14 2019 at 14:54, on Zulip):

i.e. finding a way to report such cases as warnings rather than errors, even when the user asked to #[deny(..)] the lint in question

pnkfelix (Mar 14 2019 at 14:55, on Zulip):

While I do think such an architecture is potentially interesting, its also not a good thing to invest time in unless we actually want to use it

pnkfelix (Mar 14 2019 at 14:55, on Zulip):

in other words, would we actually want future changes to spans reported by lints to have a history to them

pnkfelix (Mar 14 2019 at 14:56, on Zulip):

where we track both the span(s) tracked by previous version(s) of the compiler, as well as the most current span that it flags

nikomatsakis (Mar 14 2019 at 14:56, on Zulip):

the other option of course is not to change the span

pnkfelix (Mar 14 2019 at 14:56, on Zulip):

yes that is another option

pnkfelix (Mar 14 2019 at 14:56, on Zulip):

but probably not a great one?

nikomatsakis (Mar 14 2019 at 14:56, on Zulip):

in other words, would we actually want future changes to spans reported by lints to have a history to them

this way of phrasing it sounds strange; but I guess another way to put it is that there is a span that determines the "lint allow/deny level"

nikomatsakis (Mar 14 2019 at 14:56, on Zulip):

and that is (potentially) distinct from the span that is used in the print out?

nikomatsakis (Mar 14 2019 at 14:56, on Zulip):

which...I don't know, sounds less bad :P but I guess it's equivalent

nikomatsakis (Mar 14 2019 at 14:57, on Zulip):

in paricular I was imagining a world where we had rules and put a bit of thought into "what is the right span to determine the allow/deny" when it comes to macros etc

pnkfelix (Mar 14 2019 at 14:57, on Zulip):

in other words, would we actually want future changes to spans reported by lints to have a history to them

this way of phrasing it sounds strange; but I guess another way to put it is that there is a span that determines the "lint allow/deny level"

well i was more thinking of comparing whether the span has gone from "came from external crate" to "doesn't come from external crate", and downgrading from error to wanring in that case alone

nikomatsakis (Mar 14 2019 at 14:57, on Zulip):

if I am understanding correctly, anyway, the problem here is that we had something like fn $foo() { .. } or whatever, and the old span was on that construct, and thus took its "allow/deny" levels more from the macro itself?

pnkfelix (Mar 14 2019 at 14:58, on Zulip):

which I do not think is equivalent to the (simpler?) idea that niko is putting forward

nikomatsakis (Mar 14 2019 at 14:58, on Zulip):

(but now the span is on the $foo itself, and thus comes from the point where macro is applied?)

pnkfelix (Mar 14 2019 at 14:58, on Zulip):

if I am understanding correctly, anyway, the problem here is that we had something like fn $foo() { .. } or whatever, and the old span was on that construct, and thus took its "allow/deny" levels more from the macro itself?

this is what I originally thought, but its not quite that smple

pnkfelix (Mar 14 2019 at 14:58, on Zulip):

Its more that we have a blanket "don't bother reporting lints" when any part of the span originating from any external crate

pnkfelix (Mar 14 2019 at 14:59, on Zulip):

and it doesn't matter what the allow/warn/deny level was in that crate

pnkfelix (Mar 14 2019 at 14:59, on Zulip):

the thinking here is "client crates can't do anything anyway about the code that the external crate is providing, so there's no point in linting it"

pnkfelix (Mar 14 2019 at 14:59, on Zulip):

ugh we are almost out of time

pnkfelix (Mar 14 2019 at 14:59, on Zulip):

the second thing I wanted to note here

nikomatsakis (Mar 14 2019 at 15:00, on Zulip):

Its more that we have a blanket "don't bother reporting lints" when any part of the span originating from any external crate

ok, but it still has to do with the span coming from the fn $foo() as a whole, and not just $foo?

pnkfelix (Mar 14 2019 at 15:00, on Zulip):

Its more that we have a blanket "don't bother reporting lints" when any part of the span originating from any external crate

ok, but it still has to do with the span coming from the fn $foo() as a whole, and not just $foo?

yes

nikomatsakis (Mar 14 2019 at 15:00, on Zulip):

ugh we are almost out of time

I can very briefly update on the async-await WG

pnkfelix (Mar 14 2019 at 15:00, on Zulip):

The second thing I wanted to note is that due to mismanagement of #58502 (which I take responsibility for), this bug is actually in stable

pnkfelix (Mar 14 2019 at 15:00, on Zulip):

which means we need to decide whether this is worth fixing at all, and if so, is it worth a point release, etc.

nikomatsakis (Mar 14 2019 at 15:00, on Zulip):

(I appreciated your timeline, btw, I think we should consider doing more postmortems like that)

nikomatsakis (Mar 14 2019 at 15:01, on Zulip):

(though of course we should think about what we can do to alter our policy and make it less likely)

pnkfelix (Mar 14 2019 at 15:01, on Zulip):

but we don't need to talk about the fact it leaked to stable right now

Esteban Küber (Mar 14 2019 at 15:01, on Zulip):

It can be worked around by macro defs by annotating the generated code, right?

pnkfelix (Mar 14 2019 at 15:01, on Zulip):

since I don't want to try to stuff it into -1 minutes.

pnkfelix (Mar 14 2019 at 15:01, on Zulip):

It can be worked around by macro defs by annotating the generated code, right?

yes, as long as one isn't using #[forbid], I assume.

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

well

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

do you mean annotating the macro-invocatin

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

or annotating the code generated within the macro itself?

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

(actually I think either workaround works)

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

or annotating the code generated within the macro itself?

this seems like the thing you would want to be able to do

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

One thing I am going to do is post a test case I made that illustrates our behavior here

pnkfelix (Mar 14 2019 at 15:03, on Zulip):

ugh we are almost out of time

I can very briefly update on the async-await WG

maybe we can switch to this

nikomatsakis (Mar 14 2019 at 15:03, on Zulip):

OK, well, this is a hard one. I'm inclined to let it go, under our general policy of not messing about with lints, but I feel like there is a need to be refining and documenting our regression procedure when we encounter such edge cases

nikomatsakis (Mar 14 2019 at 15:03, on Zulip):

I can definitely see this irritating someone

pnkfelix (Mar 14 2019 at 15:03, on Zulip):

(people who want to discuss #58502 further are invited to post comments on that ticket)

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

@nikomatsakis do you think #58502 is worth raising to T-lang ?

nikomatsakis (Mar 14 2019 at 15:04, on Zulip):

But there is the "once it hits stable, you start risking making changes that undo the work that people did" etc

nikomatsakis (Mar 14 2019 at 15:04, on Zulip):

I'm not sure, I feel like it's a grey area for sure. I don't know that I think lang needs to be involved in this.

nikomatsakis (Mar 14 2019 at 15:05, on Zulip):

Though I think it may be worth at least talking about

nikomatsakis (Mar 14 2019 at 15:05, on Zulip):

i.e., to bring awareness that we will want to at some point probably include the "active span" for the lint

nikomatsakis (Mar 14 2019 at 15:05, on Zulip):

as part of its definition

pnkfelix (Mar 14 2019 at 15:05, on Zulip):

okay. It definitely has pushed me to be more aware of the consequences of a seemingly trivial change to spans

nikomatsakis (Mar 14 2019 at 15:05, on Zulip):

I guess @pnkfelix I think that having the ability to separate the "span for display" from the "span for allow/deny" feels...maybe useful.

nikomatsakis (Mar 14 2019 at 15:06, on Zulip):

I'm sort of tempted to say we should have considered reverting the PR at that time.

nikomatsakis (Mar 14 2019 at 15:06, on Zulip):

But not sure it's worth it now.

nikomatsakis (Mar 14 2019 at 15:06, on Zulip):

Anyway

oli (Mar 14 2019 at 15:06, on Zulip):

the allow/deny should probably not be spans, but ids, but that's a different/tangential story

pnkfelix (Mar 14 2019 at 15:06, on Zulip):

should we just skip WG-checkin for this week?

nikomatsakis (Mar 14 2019 at 15:06, on Zulip):

Yes

nikomatsakis (Mar 14 2019 at 15:07, on Zulip):

should we just skip WG-checkin for this week?

Probably, I'll post one thing :)

nikomatsakis (Mar 14 2019 at 15:07, on Zulip):

Async-await WG is working on closing out implementation issues around the async-await desugaring etc. The list is not super long, at least not of blockers. We've categorized the issues using AsyncAwait-* tags.

nikomatsakis (Mar 14 2019 at 15:07, on Zulip):

You can see the current things we are working on in our NOTES file

nikomatsakis (Mar 14 2019 at 15:09, on Zulip):

The biggest thing we have to think about I think -- one where it may be useful to get input from e.g. @eddyb and @Zoxc -- is thinking about how generators work. In particular, we have this "interior" type that defines the things captured by a generator, and it is currently created from the HIR and not the MIR, which introduces imprecisions. This can cause unexpected errors. There is some discussion about the best way to fix this already, but I don't thnk we've really started discussing in depth. (In particular, a question is whether to use a more refined HIR process, or to try and generate the MIR first.)

nikomatsakis (Mar 14 2019 at 15:10, on Zulip):

The other thing is that @davidtwco has been working on changing how the desugaring works to resolve some drop-order corner cases and was encountering some challenges around the way that HIR handles function arguments -- we kind of need a way to refer to the "pre-pattern" function argument. But they've been busy with that and have a PR and everything that I've not really caught up on so maybe they resolved that somewhat.

nikomatsakis (Mar 14 2019 at 15:10, on Zulip):

OK, fin, I think.

pnkfelix (Mar 14 2019 at 15:11, on Zulip):

okay great!

pnkfelix (Mar 14 2019 at 15:11, on Zulip):

bye everyone!

davidtwco (Mar 14 2019 at 15:12, on Zulip):

The other thing is that davidtwco has been working on changing how the desugaring works to resolve some drop-order corner cases and was encountering some challenges around the way that HIR handles function arguments -- we kind of need a way to refer to the "pre-pattern" function argument. But they've been busy with that and have a PR and everything that I've not really caught up on so maybe they resolved that somewhat.

I think I'm 95% of the way there with this, it was working for a while (with the exception of a single test) but broke after a rebase. I've hit some walls trying to fix it. I'm also not super happy with the approach I've taken. So I'd appreciate any comments or thoughts in this Zulip thread.

Zack M. Davis (Mar 14 2019 at 15:43, on Zulip):

is Zack M. Davis around?

@pnkfelix Hi, sorry I missed the meeting; I'll likely have some rustc-dev time this weekend, but I was going to spend it on #53934 followup research

Last update: Nov 16 2019 at 01:05UTC