Stream: t-compiler

Topic: weekly meeting 2019-03-21 #54818


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

Hey @nikomatsakis , are you willing to be responsible for a WG-traits check-in tomorrow at the T-compiler weekly meeting?

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

(I am planning to either be the representative for WG-nll checkin, or find someone else tonight who will do so.)

nikomatsakis (Mar 20 2019 at 14:27, on Zulip):

@pnkfelix yep

oli (Mar 20 2019 at 14:28, on Zulip):

I'm not going to be there at the weekly meeting, I'll read the transcript on friday

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

Hi @T-compiler/meeting ; our weekly meeting, held in this topic area, will be starting in about 70 minutes.

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

In the meantime I will be doing pre-meeting triage in a parallel topic

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

:construction_worker: seeking volunteer for ICE issue "Encountered error Unimplemented selecting <...> during codegen" #58375

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

:construction_worker: seeking volunteer for LLVM error "Building Firefox with rustc 1.34.0-nightly fails with LLVM ERROR: broken function found." #58881

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

:construction_worker: seeking volunteer for beta-regressing ICE issue "ICE on beta and nightly: index out of bounds in RestoreSubsliceArrayMoveOut MIR pass" #59048

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

okay hi @T-compiler/meeting !

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

you may notice that my triage was ... not so thorough today. I got distracted part way through. I did go through all the unassigned P-highs (thus the requests for volunteers above)

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

but I didn't go through the assigned P-high issues double-checking about status. I will try to do that pass after the meeting.

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

so, having said that, lets do the beta-nominations dance

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

only one T-compiler one today: "[beta] Do not accidentally treat multi-segment meta-items as single-segment" #59259

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

is this the one we talked about last week?

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

but pared down I guess? (cc @Vadim Petrochenkov)

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

This is the backport that @Vadim Petrochenkov prepared because it was ambigous which subset of PR #58899 was intended for backport, yes

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

much of cdd934 appears mechanical...

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

yeah, I'm skimming

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

it's a lot of code

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

i sort of wish some of the extraneous stuff had been filtered out, e.g. changes to diagnostics. but that's more of a reviewing impedence issue, not a problem with the PR itself.

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

do we have e idea of the overall benefits

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

(i'm referring e.g. to expand.rs)

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

I agree re: mechan ical

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

the actual "substantive" changes seem relatively few

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

it's a bit hard to see what they are :)

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

regressions fixed:

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

~~looks like https://github.com/rust-lang/rust/issues/53489~~

UPDATE: this was fixed by something else

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

hmm. these seem like stable-to-stable regressions then

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

so its just a question of whether the fix gets in 6 weeks earlier or not, right?

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

yes, stable-to-stable

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

sounds correct?

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

I'm basing this on a bit of digging, too bad @Vadim Petrochenkov isn't here to confirm

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

I'm trying figure out what the impact was of these regressiosn

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

we probably cannot wait another week to decide, right?

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

personally i'm okay with approving

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

I agree we can't wait another week

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

I am ok

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

I could go either way is the truth

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

but I wish it were a little cleaner

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

but I'm inclined to do what @Vadim Petrochenkov wants :)

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

as a rule of thumb ;)

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

right, and I doubt @Vadim Petrochenkov would have gone through the effort of making this variant PR on a whim

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

exactly

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

So okay, that sounds like a lukewarm beta-approve to me

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

I'll try to make a message conveying such on the PR.

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

maybe we can let them make the call

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

I do want it to get reviewed for real

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

speaking of, it would be good to try and write out our criteria better

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

did @eddyb review the first one?

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

good poitn

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

e.g., the fact that stable-to-stable seems less important is not immediately obvious

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

@Esteban Küber reviewed the first one

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

(in an ideal world, we would have a sort of "formula"that gives us a "default" result)

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

hey @Esteban Küber are you available to do a review of PR #59259 ?

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

Anyway lets move along, this was a lot of time

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

there are zero beta-noms with no team assigned

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

zero T-compiler stable-noms

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

I already mentioned the unassigned P-high issues, so that covered the stable-to-beta regressions relevant to us

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

and I believe I also already mentioned the relevant stable-to-nightly regressions

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

hey Esteban Küber are you available to do a review of PR #59259 ?

(okay great, I'll assign @Esteban Küber to that PR)

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

:construction_worker: seeking volunteer for LLVM error "Building Firefox with rustc 1.34.0-nightly fails with LLVM ERROR: broken function found." #58881

@nagisa (from the thread) seemed to have an idea of the cause (bad dereferenceable attribute)

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

er, sorry if I'm acting out of turn

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

though we may want to reassign ""Cannot create local mono-item" ICE building cortex-m code on nightly" #58323

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

(I was just going back and looking over the "volunteer wanted" thing)

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

no no, its fine

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

https://github.com/rust-lang/rust/issues/59048

could use a bisection, I can try to do that

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

I was just making sure the regressions appear under control

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

most of them appear under control or are nominated for discussion

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

there are thirteen open nominated issues

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

there are thirteen open nominated issues

did you want to start going through those, then?

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

well its either that or discuss the bugs I was seeking volunteers for

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

(I know that I at least nominated some issues for discussion)

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

(to e.g. get help determining a P-label)

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

some of the nominations can continue to wait another week, e.g. "Future-incompatible warnings should always print a warning, even if lints are allowed" #34596

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

but I don't want to go past the 30 minute mark with triage stuff. So maybe we can focus first on whether anyone wants to volunteer for the bugs listed above

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

(the ones marked with a :construction_worker: )

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

I volunteer to bisect

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

okay I'll assign that to you and you can unassign at whim

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

I .. might be willing to volunteer to investigate https://github.com/rust-lang/rust/issues/58375. I think I could at least put in an hour or two tomorrow.

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

I might have to drop out though

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

Better might be helping others =)

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

(i.e., if somebody wanted to take it on, I'd be happy to spend an hour or two digging into it together, and they can maybe take it from there)

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

its (#58375) something with trait impl selection, right?

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

confirm

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

are there people looking to learn more about that codebase that you could mentor?

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

hmm maybe @tmandry ?

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

or @Sunjay Varma ?

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

I'm thinking of folks from @WG-traits

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

maybe @Alexander Regueiro ?

Aaron Turon (Mar 21 2019 at 14:29, on Zulip):

/me could also help

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

if any of you have an interest in trying to investigate/fix a regression, ping me, it's #58375

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

ah, good point

Aaron Turon (Mar 21 2019 at 14:29, on Zulip):

feel free to assign

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

ok, let's assign @Aaron Turon, and I'll try to sync up with them

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

okay. well I'll take the third one, "Building Firefox with rustc 1.34.0-nightly fails with LLVM ERROR: broken function found." #58881

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

so, lets move on to WG-checkin

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

this may go very quickly

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

(in which case we could go back to the nominated issue list.)

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

Since i'm running the meeting and I'm representing the WG-nll here, I'll go first

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

NLL is on the cusp of landing migration mode for 2015 edition, so that all editions of Rust would be using NLL

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

the only thing blocking the PR that lands 2015 migration is another PR that restricts two-phased borrows in order to accommodate the formal semantics that @RalfJ has been working on

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

the relevant PRs here are "Enable NLL migrate mode on the 2015 edition" #59114

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

and "More restrictive 2 phase borrows - take 2" #58739

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

PR #58739 is currently blocked on the lang team, but I believe assert the question there will be resolved one way or another tonight

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

(hint: this was the task that was distracted me during pre-triage earlier)

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

there are still a slew of NLL related issues, many of them diagnostic ones

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

but @Matthew Jasper made the excellent point to me last night that we should first focus on landing the 2015 migration mode

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

once that's in place, we'll have a lot more incentive (and perhaps volunteers?) to continue with diagnostic fixups.

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

so that's all from WG-NLL

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

@nikomatsakis, can you report on WG-traits?

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

Yes.

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

First, we've decided to adopt a 6-week sprint model. In Monday's meeting, we set ourselves some goals

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

or maybe "themes" is a better choice, basically projects to pursue

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

we are now going to be chasing those projects for 6-weeks, and we'll re-evaluate after that.

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

(I think ideally we would have more concrete goals for the sprint, but we're not that far yet to be able to estimate such things.)

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

hmm. 6-week implementation compared to 6-week release cycle.

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

As an aside, this is also documented on our compiler-team page

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

hmm. 6-week implementation compared to 6-week release cycle.

not a coincidence :)

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

We're tracking our goals etc in this paper document here

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

One big conversation we had was about GATs

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

And whether we should first try to implement them atop rustc's existing solver

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

Or shoot for chalk integration

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

The conclusion was that chalk integration made more sense, because implementing atop rustc's existing solver likely wouldn't be able to handle some of the use cases we want.

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

So we've started pursuing that in a bit more earnest, beginning with a series of video sessions (the first one of which is recorded and online) describing the current impl and how it works, and the overall strategy

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

The intention is to build up enough material for people to be able to get involved

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

and making videos is just way easier than writing docs, so we're starting there :)

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

we're also pursuing a bit of work on itnegrating chalk into RLS 2.0, which is related -- but which likely permits a deeper integration than rustc

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

in addition, @Alexander Regueiro has been working (and will continue to work) on implementing the "associated type bounds" RFC

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

I hope that over the next week or so we'll be able to flesh out better just waht the goals are around chalk integration, but basically right now we're focusing on closing some of the FIXMEs we had left, as well as targeting a piece of the story that wasn't fully worked out.

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

Fin, I guess, unless somebody wants me to get into more details on a particular piece.

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

are you seeking more volunteers?

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

Hmm, I think not just yet

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

I mean people are welcome, but we don't have like a pool of tasks right now

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

right, that's what I meant

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

(I think NLL is in a similar state)

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

I think my goal for this sprint is basically to get far enough that we would start to have such a pool

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

(or rather, NLL is winding down, at least in its present implementation. While WG-traits is continuing to wind up)

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

okay so that seems good for the checkin

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

right

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

maybe we can dedicate the remaining 17 minutes to the nominations then

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

nominated T-compiler issues

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

I'm going to try to dynamic infer prioritization

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

so it may seem like i'm going out of order. because there is no order

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

first: "edition compatibility lints: Warning about dyn in a macro incorrectly" #56327

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

PS -- random aside -- I think we should start posting "light summaries" of these meetings, especially the volunteer parts. I'll volunteer to do the first one to show what I have in mind, but we can think about how to sustain that going forward :)

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

so the reason I nominated this is that I wanted to point out that this issue was filed months ago

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

and the bug here effectively led to this other bug filed more recently: "cargo fix --edition failure (probably macros related)" #59065

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

heh, that's sort of amusing

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

is that specific to macros? I can imagine it

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

I don't know exactly what we intend or want to do here.

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

I think we have trouble identifying the role of dyn in a macro until it is expanded

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

but we give the warning based on the pre-expansion contents

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

as in, based on the macro definition itself, regardless of where it is invoked?

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

correct

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

is that the right thing to do?

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

i mean, in an ideal world we could do it

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

well

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

but it would require macros to specify

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

I thought so :)

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

i'm trying to remember why

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

what context(s) they are intended to be expanded in

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

right now you can have a macro that just expands to dyn Trait

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

and do e.g. fn foo() -> Box<that_macro!()>

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

so I don't see how one could hope to know what was intended

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

(without the invocations)

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

(maybe macros 2.0 should have an output syntax kind as well as input kinds)

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

I think the problem is

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

anyway I don't actually know if this is high priority to fix or not

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

or if it is really fixable at all

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

yeah I guess it comes to the priority as much as anthing

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

doesn't feel super high priority to me

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

nor me

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

we've gotten this far without more reports

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

I mostly wonder if we should loosen the lint in question for dyn

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

as far as I can tell, the lint that's doing this was landed to catch occurrences of async

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

(or maybe await ? let me check)

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

so the relevnat issue is "Write lint for usage of edition-gated keywords" #49716

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

is dyn considered an edition-gated keyword?

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

or am I confusing things, and the same phenomenon we are describing will arise with asyncanyway (when used in a macro definition)?

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

anyway

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

I'll probably call it (#56327) P-medium for now

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

you're right that async was I think a bigger deal

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

I .. honestly have forgotten where we landed with dyn

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

ah, right

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

on 2018, it's a keyword, yes

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

so e.g. let dyn = 22 does not work

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

on 2015 that does (but you can also use it in the type context)

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

anyway my sense remains "medium priority"

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

okay. So one could e.g. make a my_dyn macro that just expands to dyn and use that in 2015

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

and we should be presumably linting for that, because macros can only be used in expression or type contexts

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

anyway I think we can migrate further discussion to take place asynchronously

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

next nominated issue (or PR in this case): "Combine input and eval_always query types" #59091

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

@Zoxc is asking for feedback on the approach

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

but @mw is on PTO

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

I imagine @eddyb or @nikomatsakis may have opinions on the design of the query types, yes?

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

I have vague opinions

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

I do think @mw is right that we should try to remove the special case

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

but I guess @Zoxc is saying "I combined two special cases into one, we could try the idea of removing some of these special cases further later"

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

I can take a look and give my 2c, this doesn't feel like a "big deal" to me

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

okay. sounds reasonable.

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

i.e., I don't think it needs anything more than a stanrad r+ ultimately

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

do you know when @mw will be back? Is this worth reassigning to @nikomatsakis in the short term?

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

I believe @mw is back next week

Zoxc (Mar 21 2019 at 14:59, on Zulip):

@mw is not suggesting removing eval_always, just moving some eval_always queries to regular queries. I think

Wesley Wiser (Mar 21 2019 at 14:59, on Zulip):

@mw Told me they'd be back Monday

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

okay I will leave assigned to @mw

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

I'll write a comment on the issue noting that we discussed it here.

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

We have time for one last nominated issue before the hour is really up

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

namely: "fn generated by macro exported from crate loses global #![allow(non_snake_case)]" #58502

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

I'm planning at this point to close this as a wontfix

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

i.e. that the change in behavior is an expected outcome from a lint improvement

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

but I also wanted to make sure I gave visibility here before I close it

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

I feel ok about that.

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

(the short version of the story is that in an older compiler, if you had a macro sudo_make_me_a_fn!(NonSnakeCaseName); that expanded into fn NonSnakeCaseName() { }, the compiler used to not yell at you about it

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

It feels like something where we may want to do better but not sure it's worth doing better now

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

based on the analysis indicating that the functino defintion itself came from an external crate, and thus a user cannot address the lint, so the compiler would silence the lint

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

(the bug title is misleading, in that the global allow in the external crate is irrelevant.)

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

((the logic here applies regardless of any allow/warn/deny attributes in the extern crate, that is.))

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

but a later revision to the lint code narrowed the scope of the reported warning

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

so that the span would encompass just the offending identifier

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

this caused the downstream logic within the compiler to say "ah, that span does not come from an external crate. so let the non_snake_case warning go through.")

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

and this change in behavior is, in principle a breaking change

Zoxc (Mar 21 2019 at 15:05, on Zulip):

Seems like a bugfix to me too

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

since a crate with #![deny(non_snake_case)] ((or #![deny(warnings)])) would go from compiling to not compiling.

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

I mostly bring it up because its an example, I think, of totally unintended consequences

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

I.e. narrowing the span of a lint can cause code to stop compiling. That's not something I would have predicted.

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

yep

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

but I also agree that in terms of what a user expects, if someone has #![deny(non_snake_case)] turned on, they probably want to get an error in this case

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

i.e. they want to know that they inadvertantly created a fn like that.

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

okay so that's enough out of me.

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

thanks everyone for attending!

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

:wave: thanks all

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

and thanks @pnkfelix as ever for doing such an excellent job running the meeting :)

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

PS -- random aside -- I think we should start posting "light summaries" of these meetings, especially the volunteer parts. I'll volunteer to do the first one to show what I have in mind, but we can think about how to sustain that going forward :)

light summaries sound nice. I suspect I don't want to do them, mostly because I'm terrible at creating light summaries; they may start skeletal but end up bloated monsters.

Alexander Regueiro (Mar 21 2019 at 17:25, on Zulip):

in addition, Alexander Regueiro has been working (and will continue to work) on implementing the "associated type bounds" RFC

It's very nearly complete. Just doing some boring stuff now like feature gating and feature-gate tests, plus an error message change. :-)

Last update: Nov 16 2019 at 01:05UTC