Stream: t-compiler

Topic: weekly meeting 2019-04-18 #54818


oli (Apr 18 2019 at 11:00, on Zulip):

I won't be able to take part in todays meeting. I'll read through the log afterwards, feel free to assign stuff to me XD I'll look at it on tuesday at the latest

pnkfelix (Apr 18 2019 at 11:31, on Zulip):

Thanks @oli

pnkfelix (Apr 18 2019 at 11:31, on Zulip):

as a reminder to the rest of @T-compiler/meeting , we'll be having our weekly meeting in this topic, starting in about 2.5 hours.

pnkfelix (Apr 18 2019 at 11:32, on Zulip):

I will be doing pre-meeting triage in parallel topic.

davidtwco (Apr 18 2019 at 11:48, on Zulip):

What working groups are checking in today?

pnkfelix (Apr 18 2019 at 12:33, on Zulip):

@davidtwco funny you ask that; I spent a little while trying to find that table that I think you made showing an ad-hoc schedule

pnkfelix (Apr 18 2019 at 12:33, on Zulip):

@davidtwco but I could not find it and decided it was more important to move forward with pre-triage

pnkfelix (Apr 18 2019 at 12:33, on Zulip):

if you can find it and point me at it (and then I'll add it to the agenda at #54818) that would be great

davidtwco (Apr 18 2019 at 12:40, on Zulip):

I only ask so that the people have a chance to prepare something, here's the schedule.

pnkfelix (Apr 18 2019 at 12:43, on Zulip):

of course; that is the same reason I wanted to look it up

pnkfelix (Apr 18 2019 at 12:43, on Zulip):

so okay, schedule says wg-llvm and wg-async-await

pnkfelix (Apr 18 2019 at 12:44, on Zulip):

hey @nagisa , do you think you will be around to provide a check-in regarding what's going on with WG-llvm?

pnkfelix (Apr 18 2019 at 12:44, on Zulip):

I think @Taylor Cramer has said in the past that the rustc meeting time is not good for them; will @nikomatsakis be available to provide a check-in from the WG-async-await ?

pnkfelix (Apr 18 2019 at 14:01, on Zulip):

Hi @T-compiler/meeting

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

another week, another case of felix not finishing all the pre-triage he wanted.

nikomatsakis (Apr 18 2019 at 14:02, on Zulip):

I think Taylor Cramer has said in the past that the rustc meeting time is not good for them; will nikomatsakis be available to provide a check-in from the WG-async-await ?

yep

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

So there are a lot of P-high issues

pnkfelix (Apr 18 2019 at 14:03, on Zulip):

P-high issues

pnkfelix (Apr 18 2019 at 14:03, on Zulip):

but we also have a lot of nominated issues (and maybe PRs)

pnkfelix (Apr 18 2019 at 14:03, on Zulip):

that I would prefer to try to get through today

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

So I'll just ask everyone watching: Take a look at the list of P-high issues above. The ones assigned to you, please do try to write a note regarding status

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

The ones not assigned to you, consider taking it. (If you are in this meeting and cannot be assigned to issues, let me know and I'll see about adding you to the appropriate group so that you can)

nikomatsakis (Apr 18 2019 at 14:05, on Zulip):

So there are a lot of P-high issues

yeah there are :(

pnkfelix (Apr 18 2019 at 14:05, on Zulip):

And if you have an issue assigned to you that you know you do not have time to address in the next two weeks: Consider trying to find someone else to mentor

pnkfelix (Apr 18 2019 at 14:05, on Zulip):

and/or delegate to

pnkfelix (Apr 18 2019 at 14:06, on Zulip):

(by "address", I don't necessarily mean "fix 100%")

pnkfelix (Apr 18 2019 at 14:06, on Zulip):

e.g. some of these bugs are known long standing work items.

pnkfelix (Apr 18 2019 at 14:06, on Zulip):

okay that's all I'll say for now about the P-high list

pnkfelix (Apr 18 2019 at 14:07, on Zulip):

we have zero beta backport nominations

pnkfelix (Apr 18 2019 at 14:07, on Zulip):

There is one stable backport nomination

pnkfelix (Apr 18 2019 at 14:07, on Zulip):

namely "Use informational target machine for metadata" #58605

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

So I don't know much about this bug nor about its fix

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

hey nagisa , do you think you will be around to provide a check-in regarding what's going on with WG-llvm?

sure.

mw (Apr 18 2019 at 14:09, on Zulip):

I can't remember if this bug only occurred for cortex-m?

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

the original fixed issue was #58323

mw (Apr 18 2019 at 14:09, on Zulip):

because if it does then a backport is not warranted, I think

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

but the claim is that it also fixes #59898

pnkfelix (Apr 18 2019 at 14:11, on Zulip):

I don't know what --features="stm32f429" denotes

pnkfelix (Apr 18 2019 at 14:11, on Zulip):

does that mean something that is similarly only on cortex-m ?

mw (Apr 18 2019 at 14:11, on Zulip):

another embedded platform

nagisa (Apr 18 2019 at 14:12, on Zulip):

I think the bug in question could occur for any cargo check use?

pnkfelix (Apr 18 2019 at 14:12, on Zulip):

someone said that reproduced "on linux", but I don't know if that meant embedded linux

nagisa (Apr 18 2019 at 14:12, on Zulip):

My inclination is to only backport-to-stable if we end up releasing a point release for stable otherwise.

pnkfelix (Apr 18 2019 at 14:12, on Zulip):

or desktop linux?

nagisa (Apr 18 2019 at 14:12, on Zulip):

for some other reason

nikomatsakis (Apr 18 2019 at 14:12, on Zulip):

My inclination is to only backport-to-stable if we end up releasing a point release for stable otherwise.

cc @Pietro Albini @simulacrum -- any reason to think we will do so?

mw (Apr 18 2019 at 14:12, on Zulip):

cargo check definitely didn't break on Linux in general

pnkfelix (Apr 18 2019 at 14:13, on Zulip):

okay well

centril (Apr 18 2019 at 14:13, on Zulip):

@nikomatsakis we have sort of already scheduled a 1.34.1 but we may change our minds since some reexports that we thought we were going to do may not be happening

mw (Apr 18 2019 at 14:13, on Zulip):

@nagisa would you say that there's a risk attached to backporting?

nagisa (Apr 18 2019 at 14:14, on Zulip):

I would very much rather avoid backporting it to stable, yeah.

eddyb (Apr 18 2019 at 14:14, on Zulip):

I think we're talking about "cross-compile cargo check"

nagisa (Apr 18 2019 at 14:14, on Zulip):

Seeing how many iterations this required to get right (and how spaghetti the code in question was before) I’m not at all confident the patch is rock-stable

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

is there anyone here who wants to argue for backporting?

eddyb (Apr 18 2019 at 14:15, on Zulip):

cargo check on a project that is destined to run on an embedded board, presumably w/o even an OS on it

eddyb (Apr 18 2019 at 14:15, on Zulip):

I'd say not backporting might result in worse developer experiece, but it could be marginal enough to not matter

eddyb (Apr 18 2019 at 14:16, on Zulip):

and presumably it's fixed on beta? so people could use that for a while? or is that unacceptable

pnkfelix (Apr 18 2019 at 14:16, on Zulip):

they apparently can also work around by choosing different opt-levels

pnkfelix (Apr 18 2019 at 14:16, on Zulip):

which ... they can do specifically for a cargo check dev profile?

mw (Apr 18 2019 at 14:17, on Zulip):

sounds like it's not worth the risk

pnkfelix (Apr 18 2019 at 14:17, on Zulip):

they apparently can also work around by choosing different opt-levels

(I'm basing this on one of the comments; I'm not certain its generally true.)

pnkfelix (Apr 18 2019 at 14:17, on Zulip):

okay. lets decline to backport and wait to see who yells in response.

Pietro Albini (Apr 18 2019 at 14:18, on Zulip):

the plan was to release 1.34.1 next week, mainly to include the ICE fixes but also to let me learn the release process

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

next, beta regressions

Pietro Albini (Apr 18 2019 at 14:18, on Zulip):

if the backport is declined... well, we're not going to do a point release for just one clippy ice fix

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

only beta regression is "Tuple indexing regression" #59553

pnkfelix (Apr 18 2019 at 14:19, on Zulip):

I think the main thing here is I want to make sure someone is assigned to this

pnkfelix (Apr 18 2019 at 14:19, on Zulip):

the general dialogue is that we may be fine just letting the "regression" slide

pnkfelix (Apr 18 2019 at 14:19, on Zulip):

without adding future-compat warning stuff

pnkfelix (Apr 18 2019 at 14:19, on Zulip):

(depending on how crater goes)

pnkfelix (Apr 18 2019 at 14:19, on Zulip):

but I don't like having it unassigned.

pnkfelix (Apr 18 2019 at 14:20, on Zulip):

So: Anyone want to take a bug that may require ZERO effort?

eddyb (Apr 18 2019 at 14:20, on Zulip):

heh

nikomatsakis (Apr 18 2019 at 14:20, on Zulip):

only beta regression is "Tuple indexing regression" #59553

hmm I am ... of mixed minds about this change.

eddyb (Apr 18 2019 at 14:20, on Zulip):

I actually hit something similar and didn't realize tuple.0usize was ever allowed

nikomatsakis (Apr 18 2019 at 14:20, on Zulip):

i.e., obviously we wish that we didn't permit this but is it worth regressing things?

centril (Apr 18 2019 at 14:21, on Zulip):

I think we are too liberal with C-future-compatibility lints

centril (Apr 18 2019 at 14:21, on Zulip):

I want to see a significant reduction of them and be more strict with when they are used

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

I didn't have in mind a lint

eddyb (Apr 18 2019 at 14:21, on Zulip):

(I have to say, it's really painful to generate a plain integer, more so than I would've hoped for... we should've just removed literal suffixes before 1.0 :P)

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

I had in mind never changing this behavior at all

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

Why is the macro expander including a literal suffix here?

eddyb (Apr 18 2019 at 14:22, on Zulip):

quote! is

pnkfelix (Apr 18 2019 at 14:22, on Zulip):

or is it quote! thats doing that?

nikomatsakis (Apr 18 2019 at 14:22, on Zulip):

Basically I think we should consider reverting https://github.com/rust-lang/rust/pull/59421

eddyb (Apr 18 2019 at 14:22, on Zulip):

it's the behavior for interpolating an integer in quote! and I think it's maybe a bit much

Esteban Küber (Apr 18 2019 at 14:22, on Zulip):

The end user is using quote incorrectly

nikomatsakis (Apr 18 2019 at 14:22, on Zulip):

(And, I think we probably need to have a broader conversation / RFC on this topic to create better guidelines. I've noticed it is coming up a lot lately.)

centril (Apr 18 2019 at 14:23, on Zulip):

I don't agree with a permanent revert; it clearly seems like a bug to me

Esteban Küber (Apr 18 2019 at 14:23, on Zulip):

It's a one line change to the users crate to get this fixed for them

nikomatsakis (Apr 18 2019 at 14:23, on Zulip):

The end user is using quote incorrectly

For what it's worth, I'm pretty sure I used quote! exactly like this in salsa :)

eddyb (Apr 18 2019 at 14:23, on Zulip):

I don't have a problem with warning that you shouldn't have a literal suffix, and just letting it slide

pnkfelix (Apr 18 2019 at 14:23, on Zulip):

@Esteban Küber why is this an incorrect use of quote? Are you only supposed to interpolate string data or something?

nikomatsakis (Apr 18 2019 at 14:23, on Zulip):

I don't agree with a permanent revert; it clearly seems like a bug to me

I appreciate that, but I think at minimum we should have the broader conversation

Esteban Küber (Apr 18 2019 at 14:23, on Zulip):

We can make this warn in beta and stable for a bit

eddyb (Apr 18 2019 at 14:23, on Zulip):

https://github.com/rust-lang/gll/blob/master/src/generate/rust.rs#L833-L835

nikomatsakis (Apr 18 2019 at 14:24, on Zulip):

I promise you that this will affect code that is not on crates.io

eddyb (Apr 18 2019 at 14:24, on Zulip):

this is how you're supposed to get the unsuffixed literals

nikomatsakis (Apr 18 2019 at 14:24, on Zulip):

We can make this warn in beta and stable for a bit

at minimum I thnk we sohuld do this

centril (Apr 18 2019 at 14:24, on Zulip):

@nikomatsakis what does that broader conversation look like?

I'm also concerned that we still don't have the minimum lint levels infrastructure

pnkfelix (Apr 18 2019 at 14:24, on Zulip):

At minimum I think someone should take this bug

nikomatsakis (Apr 18 2019 at 14:24, on Zulip):

Basically, I'd want to judge "how important is it to fix this".

Esteban Küber (Apr 18 2019 at 14:24, on Zulip):

Of course, I spoke with David in Montevideo and he was adamant that quote wouldn't change for this and was convinced, and Taylor was of a kind that we should just let it ride the train

nikomatsakis (Apr 18 2019 at 14:25, on Zulip):

what do you mean by "quote wouldn't change"?

centril (Apr 18 2019 at 14:25, on Zulip):

I think David is right; the bug is in users of quote!, not in quote! itself

eddyb (Apr 18 2019 at 14:25, on Zulip):

I think quote! is a bit too hard on this, but it could be backwards-incompat for quote! to change anyway

pnkfelix (Apr 18 2019 at 14:25, on Zulip):

can we determine that quote! was involved from the span (expansion stack)

pnkfelix (Apr 18 2019 at 14:25, on Zulip):

and provide better feedback on usage then?

eddyb (Apr 18 2019 at 14:26, on Zulip):

I'd prefer it if quote! made you do #i: usize if you wanted a certain type, but, like I said, literal suffixes are
bad in the first place,,,

eddyb (Apr 18 2019 at 14:26, on Zulip):

@pnkfelix we could maybe track whether the literal was synthetic

nikomatsakis (Apr 18 2019 at 14:26, on Zulip):

What is the motivation to do https://github.com/rust-lang/rust/pull/59421/ ?

Esteban Küber (Apr 18 2019 at 14:26, on Zulip):

We can add a note pointing at the ticket

nikomatsakis (Apr 18 2019 at 14:26, on Zulip):

Like, why not continue to accept this behavior, perhaps deprecated?

eddyb (Apr 18 2019 at 14:26, on Zulip):

not quote! specifically, but using a Literal constructor

Esteban Küber (Apr 18 2019 at 14:26, on Zulip):

With a shirt explanation of what changed

centril (Apr 18 2019 at 14:27, on Zulip):

@nikomatsakis it fixes a bug where random garbage was allowed in tuple indexing

pnkfelix (Apr 18 2019 at 14:27, on Zulip):

@nikomatsakis well maybe its was beaqcuse we accepted too many kindsof literals: #59418

Esteban Küber (Apr 18 2019 at 14:27, on Zulip):

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4280ded6698f9f9f3877ad0498769cb7

nikomatsakis (Apr 18 2019 at 14:27, on Zulip):

we could therefore do a more narrow fix

Esteban Küber (Apr 18 2019 at 14:27, on Zulip):

@nikomatsakis ^

Esteban Küber (Apr 18 2019 at 14:27, on Zulip):

Certainly

centril (Apr 18 2019 at 14:27, on Zulip):

what does "more narrow fix" entail?

eddyb (Apr 18 2019 at 14:28, on Zulip):

@pnkfelix this is how quote! causes this: https://docs.rs/quote/0.6.12/src/quote/to_tokens.rs.html#123-127

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

What is the motivation to do https://github.com/rust-lang/rust/pull/59421/ ?

The struct doesn't have a field named 0usize.
0 is not really a number in that position, it's an identifier.

Esteban Küber (Apr 18 2019 at 14:28, on Zulip):

But that would still be different behavior to rust 1.1x

eddyb (Apr 18 2019 at 14:28, on Zulip):

@pnkfelix as you can see below that, it explicitly uses _suffixed constructors

Esteban Küber (Apr 18 2019 at 14:28, on Zulip):

A more narrow change would be accepting 0usize for now @centril

pnkfelix (Apr 18 2019 at 14:28, on Zulip):

what does "more narrow fix" entail?

(I imagine it would involve only rejecting suffixes that do not look like existing suffixes.)

eddyb (Apr 18 2019 at 14:29, on Zulip):

we could then mark the suffixes as synthetic and allow them with a warning despite erroring on tuple.0usize parsed from source code

Esteban Küber (Apr 18 2019 at 14:29, on Zulip):

The only one would be usize and maybe i32

pnkfelix (Apr 18 2019 at 14:29, on Zulip):

So

pnkfelix (Apr 18 2019 at 14:29, on Zulip):

We are in the weeds officially

pnkfelix (Apr 18 2019 at 14:29, on Zulip):

But the good news is

pnkfelix (Apr 18 2019 at 14:29, on Zulip):

we clearly have a lot of people excited about discussing this

eddyb (Apr 18 2019 at 14:29, on Zulip):

@Esteban Küber that's betting on only some types being used but I wouldn't be so sure

pnkfelix (Apr 18 2019 at 14:30, on Zulip):

So can one of you agree to take on this bug and then we can move on in this meeting?

eddyb (Apr 18 2019 at 14:30, on Zulip):

if you want nothing to be done, you can assign it to me :P

centril (Apr 18 2019 at 14:30, on Zulip):

I agree with such a narrow fix as a temporary hack; I don't agree with random garbage and hacks into the grammar of the language

eddyb (Apr 18 2019 at 14:30, on Zulip):

@centril eh, we're a long way from properly filtering stuff like this in any model of the grammar

centril (Apr 18 2019 at 14:31, on Zulip):

@eddyb not sure what the point is?

eddyb (Apr 18 2019 at 14:31, on Zulip):

it'd be more interesting if we allowed tuple.0.1.2.3 but that's... tricky, in terms of what we treat as a "literal" for macro_rules and proc macros

pnkfelix (Apr 18 2019 at 14:31, on Zulip):

that's it

nikomatsakis (Apr 18 2019 at 14:31, on Zulip):

So can one of you agree to take on this bug and then we can move on in this meeting?

I will try to lead it to resolution.

pnkfelix (Apr 18 2019 at 14:31, on Zulip):

no more discussion of ths issue

pnkfelix (Apr 18 2019 at 14:32, on Zulip):

we have three stable-t-nightly regressions

Esteban Küber (Apr 18 2019 at 14:32, on Zulip):

Can take it too if Niko is to busy

Esteban Küber (Apr 18 2019 at 14:32, on Zulip):

Sync off line

centril (Apr 18 2019 at 14:32, on Zulip):

(split it into a new topic)

pnkfelix (Apr 18 2019 at 14:32, on Zulip):

the two ones marked P-high were filed within the last week

pnkfelix (Apr 18 2019 at 14:33, on Zulip):

and they are unassigned. (So, see note above about considering assigning yourself to P-hihg tickets)

pnkfelix (Apr 18 2019 at 14:33, on Zulip):

but I'm not going to spell them out now

pnkfelix (Apr 18 2019 at 14:33, on Zulip):

(becasue we are so pressed for time)

pnkfelix (Apr 18 2019 at 14:34, on Zulip):

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

pnkfelix (Apr 18 2019 at 14:34, on Zulip):

the first is one we've oft discussed, "[do not merge] Measure performance impact of local interners" #57214

pnkfelix (Apr 18 2019 at 14:35, on Zulip):

but I don't think we''re waiting anymore here, right?
it looks like everyone has now resolved their concerns

pnkfelix (Apr 18 2019 at 14:35, on Zulip):

so I'll update the labels accordingly

pnkfelix (Apr 18 2019 at 14:35, on Zulip):

next: "Add llvm.sideeffect to potential infinite loops and recursions" #59546

nagisa (Apr 18 2019 at 14:35, on Zulip):

Still needs to have its performance benchmarked, not aware of any changes there

pnkfelix (Apr 18 2019 at 14:35, on Zulip):

hmm. this was changed to waiting-on-team 3 days ago

pnkfelix (Apr 18 2019 at 14:35, on Zulip):

but I agree with @nagisa

pnkfelix (Apr 18 2019 at 14:36, on Zulip):

we need performance benchmark results

pnkfelix (Apr 18 2019 at 14:36, on Zulip):

Do we expect to ask the PR author to provide that? Or do we task someone else with it internally?

pnkfelix (Apr 18 2019 at 14:37, on Zulip):

who's the developer in charge of lolbench.rs?

nagisa (Apr 18 2019 at 14:37, on Zulip):

Since we have lolbench we should figure out how to easily get that to run. That’s @nbp I think.

nagisa (Apr 18 2019 at 14:37, on Zulip):

who’s in charge of lolbench

mw (Apr 18 2019 at 14:37, on Zulip):

@anp GH, I think

pnkfelix (Apr 18 2019 at 14:37, on Zulip):

its not @Adam Perry ?

pnkfelix (Apr 18 2019 at 14:38, on Zulip):

I'll write a follow-up comment on #59546 explaining our position

nagisa (Apr 18 2019 at 14:38, on Zulip):

Maybe. So last time we talked about it, it is apparently possible to run these benchmarks locally, except it takes like a day.

nikomatsakis (Apr 18 2019 at 14:38, on Zulip):

I'd be willing to run them on my machine, if somebody links to some isntructions

nikomatsakis (Apr 18 2019 at 14:39, on Zulip):

It's pretty idle these days, sadly

nikomatsakis (Apr 18 2019 at 14:39, on Zulip):

/me hasn't compiled rustc in too long :(

pnkfelix (Apr 18 2019 at 14:39, on Zulip):

there are ten I-nominated T-compiler issues

pnkfelix (Apr 18 2019 at 14:39, on Zulip):

which is too many for us to go through and do the WG checkins, I think

pnkfelix (Apr 18 2019 at 14:40, on Zulip):

some of them I either nominated or left nominated because I didn't know how to prioiritize them

pnkfelix (Apr 18 2019 at 14:41, on Zulip):

and I tagged "Decouple nightly RLS from Clippy" #59761 as T-compiler because I wasn't sure if T-compiler could/should be assisting with that decoupling

nagisa (Apr 18 2019 at 14:41, on Zulip):

I have already written the text for WG-llvm checkin, so unless there are any questions, it will take a minute for you to read throguh

pnkfelix (Apr 18 2019 at 14:41, on Zulip):

there are a cuple that I do think are high priority to figure out

pnkfelix (Apr 18 2019 at 14:41, on Zulip):

so let me try to cherry-pick them

pnkfelix (Apr 18 2019 at 14:41, on Zulip):

"Can define and use async fn without feature gate on nightly" #60069

pnkfelix (Apr 18 2019 at 14:42, on Zulip):

#![feature(futures_api)] is in FCP for stabilization, but async fn might be leaking through on it

pnkfelix (Apr 18 2019 at 14:42, on Zulip):

it seems at very least we should block that stabilization until this is resolved, right?

pnkfelix (Apr 18 2019 at 14:42, on Zulip):

who wants to take point on this?

pnkfelix (Apr 18 2019 at 14:43, on Zulip):

@nikomatsakis can you maybe give it to @Taylor Cramer ?

varkor (Apr 18 2019 at 14:43, on Zulip):

this should be very easy to fix

varkor (Apr 18 2019 at 14:43, on Zulip):

I can take a look :)

nikomatsakis (Apr 18 2019 at 14:43, on Zulip):

it seems at very least we should block that stabilization until this is resolved, right?

seems correct

pnkfelix (Apr 18 2019 at 14:43, on Zulip):

okay I'm assigning to @varkor , thahks!

Esteban Küber (Apr 18 2019 at 14:43, on Zulip):

If we have pr to gate it properly, would that be enough to beta backport and let future continue?

nikomatsakis (Apr 18 2019 at 14:43, on Zulip):

Would a beta backport be required?

nikomatsakis (Apr 18 2019 at 14:44, on Zulip):

(Seems ok, if so)

nikomatsakis (Apr 18 2019 at 14:44, on Zulip):

(That is, is the stabilization on beta?)

nikomatsakis (Apr 18 2019 at 14:44, on Zulip):

(I thought it wasn't yet)

Esteban Küber (Apr 18 2019 at 14:44, on Zulip):

Depends on where on the tracks future_api is

varkor (Apr 18 2019 at 14:44, on Zulip):

I don't think we would need to backport, if it's never actually usuable without a feature flag

pnkfelix (Apr 18 2019 at 14:44, on Zulip):

it would be good to link to the appropriate tracking issue

pnkfelix (Apr 18 2019 at 14:45, on Zulip):

(my attempt to quickly search for it failed)

pnkfelix (Apr 18 2019 at 14:45, on Zulip):

there's one more nominated issue that I want to try to discuss here before we do the WG-checkin

pnkfelix (Apr 18 2019 at 14:45, on Zulip):

this one: "regression in deterministic generation of binary from 1.32 to 1.33" #59542

pnkfelix (Apr 18 2019 at 14:46, on Zulip):

a problem here is that the issue reporter hasn't actually provided a test input

pnkfelix (Apr 18 2019 at 14:46, on Zulip):

just descriptions of behavior

pnkfelix (Apr 18 2019 at 14:46, on Zulip):

but I wanted to ask

pnkfelix (Apr 18 2019 at 14:47, on Zulip):

what guarantees are we providing today, supposedly, w.r.t. determinism of builds?

centril (Apr 18 2019 at 14:47, on Zulip):

std::future::Future won't be backported to 1.35.

pnkfelix (Apr 18 2019 at 14:47, on Zulip):

I know we want to get to reproducible builds

pnkfelix (Apr 18 2019 at 14:47, on Zulip):

but is a regression with respect to them actually a P-high thing?

nagisa (Apr 18 2019 at 14:47, on Zulip):

I don’t think we have guaranteed anything, but people do rely on it

mw (Apr 18 2019 at 14:47, on Zulip):

no guarantees, I think, but it's been a soft goal for a while

pnkfelix (Apr 18 2019 at 14:47, on Zulip):

I would have said no, its not P-high, but there is a comment in the issue saying that many people are relying on it

eddyb (Apr 18 2019 at 14:48, on Zulip):

this is not about reproducible builds with the same configuration

eddyb (Apr 18 2019 at 14:48, on Zulip):

it's "reproducible while changing the source dir"

pnkfelix (Apr 18 2019 at 14:49, on Zulip):

oh right, I should edit that title

eddyb (Apr 18 2019 at 14:49, on Zulip):

I doubt determinism for actual identical builds broke as badly, or at all

mw (Apr 18 2019 at 14:50, on Zulip):

it's "reproducible while changing the source dir"

that's what --remap-path-prefix is there for

mw (Apr 18 2019 at 14:50, on Zulip):

i.e. that's the only real reason for having that feature

eddyb (Apr 18 2019 at 14:50, on Zulip):

wait, so is it supposed to allow reproducible builds, or not?

nikomatsakis (Apr 18 2019 at 14:50, on Zulip):

I would have said no, its not P-high, but there is a comment in the issue saying that many people are relying on it

I think it's a "soft guarantee" we should try to preserve if it's achievable

nikomatsakis (Apr 18 2019 at 14:50, on Zulip):

(but I guess I should read the issue to understand the particulars)

mw (Apr 18 2019 at 14:51, on Zulip):

yes, it should allow reproducible builds (and has done so in the past)

eddyb (Apr 18 2019 at 14:51, on Zulip):

like, symbol hashes change despite --remap-path-prefix

pnkfelix (Apr 18 2019 at 14:51, on Zulip):

okay. @mw , do you think you can take point on this issue?

mw (Apr 18 2019 at 14:51, on Zulip):

I'm not sure from the description in the issue

pnkfelix (Apr 18 2019 at 14:51, on Zulip):

at this point its mostly about interacting withteh issue filers

pnkfelix (Apr 18 2019 at 14:51, on Zulip):

I don't expect us to take action until they provide us with a real test case

pnkfelix (Apr 18 2019 at 14:51, on Zulip):

but it sounds like they need help making one

Esteban Küber (Apr 18 2019 at 14:51, on Zulip):

I feel that if we don't have tests for it we haven't committed to not breaking it 2¢

mw (Apr 18 2019 at 14:52, on Zulip):

yes, I can take it

eddyb (Apr 18 2019 at 14:52, on Zulip):

<https://github.com/rust-lang/rust/issues/59542#issuecomment-482853270> is where I noticed the symbol hashes are wildly different

pnkfelix (Apr 18 2019 at 14:52, on Zulip):

(I imagine many in the community could similarly assist with such feedback for the filer, who is a self-admitted newbie)

eddyb (Apr 18 2019 at 14:52, on Zulip):

with some exceptions, maybe those don't depend on whatever happens to depend on file paths

pnkfelix (Apr 18 2019 at 14:53, on Zulip):

I still don't know if this is P-high or P-medium, but maybe that is something that @mw can also resolve

mw (Apr 18 2019 at 14:53, on Zulip):

sure

pnkfelix (Apr 18 2019 at 14:53, on Zulip):

so lets spend the remaining ... seven minutes on WG checkin

pnkfelix (Apr 18 2019 at 14:53, on Zulip):

...

eddyb (Apr 18 2019 at 14:53, on Zulip):

@mw do you think incremental could be used to diagnose this? that is, measure what incremental thinks has changed?

pnkfelix (Apr 18 2019 at 14:53, on Zulip):

since @nagisa already has notes typed up

pnkfelix (Apr 18 2019 at 14:53, on Zulip):

lets start with @nikomatsakis

nagisa (Apr 18 2019 at 14:53, on Zulip):

WG-llvm had a somewhat quiet period (but I cannot say I have been following happenings too closely either). The work on optimisation of the overflow intrinsics has continued. An option of not emitting overflow intrinsics for add/sub at all (and instead emitting IR that achieves this without an intrinisic) has come up as well, but that needs to be implemented and benchmarked to evaluate the impact first. In LLVM world there is a recent discussion about reworking/improving the noalias system to better suit C’s restrict semantics, which is something that may be relevant to us as well. We have a PR to Rust that solves the long-standing loop {} bug, but benchmarks need to be ran there as well to verify that it does not regress performance of unrelated code. I have on top of my TODO list to implement fixes to LLVM which would resolve this once-and-for-all properly, but am not finding much time for OSS work lately. @Nikita Popov or @dlrobertson may have more say about overall progress on their specific efforts.

pnkfelix (Apr 18 2019 at 14:53, on Zulip):

from .. whoa!

nagisa (Apr 18 2019 at 14:53, on Zulip):

I gotta run in a min

nagisa (Apr 18 2019 at 14:53, on Zulip):

gotta get some food before my workday begins

nagisa (Apr 18 2019 at 14:53, on Zulip):

so here you go

pnkfelix (Apr 18 2019 at 14:54, on Zulip):

thanks @nagisa !

pnkfelix (Apr 18 2019 at 14:54, on Zulip):

if you have any qeustions

pnkfelix (Apr 18 2019 at 14:54, on Zulip):

don't ask them now

pnkfelix (Apr 18 2019 at 14:54, on Zulip):

ping @nagisa later after they eat

nikomatsakis (Apr 18 2019 at 14:54, on Zulip):

@nagisa this all sounds pretty exciting, nice

nagisa (Apr 18 2019 at 14:54, on Zulip):

works for me.

pnkfelix (Apr 18 2019 at 14:54, on Zulip):

okay, @nikomatsakis , you have the remaining time to report from @WG-async-await

nikomatsakis (Apr 18 2019 at 14:54, on Zulip):

So,

# Async-await check-in

nikomatsakis (Apr 18 2019 at 14:55, on Zulip):

Presently we are working through blocking issues

nikomatsakis (Apr 18 2019 at 14:55, on Zulip):

Some of the things tagged as AsyncAwait-Blocking perhaps shouldn't be, though

nikomatsakis (Apr 18 2019 at 14:55, on Zulip):

(These are meant to be issues that would block stabilizing an initial MVP of async await)

nikomatsakis (Apr 18 2019 at 14:55, on Zulip):

The most notable issues:

nikomatsakis (Apr 18 2019 at 14:56, on Zulip):
nikomatsakis (Apr 18 2019 at 14:56, on Zulip):
nikomatsakis (Apr 18 2019 at 14:57, on Zulip):
nikomatsakis (Apr 18 2019 at 14:57, on Zulip):

There is one more thing, but any questions on those before I continue? :)

davidtwco (Apr 18 2019 at 14:57, on Zulip):

See #5623.

#56238 (for those following along)

nikomatsakis (Apr 18 2019 at 14:58, on Zulip):

The thorniest bug remains "Unused arguments to async fn are dropped too early" #54716.

nikomatsakis (Apr 18 2019 at 14:58, on Zulip):

We wanted to solve it by desugaring something like

async fn foo(pat: Type) {
   ...
}

into

fn foo(arg0: Type) -> impl Future<...> {
  async move {
    let pat = arg0;
  }
}
nikomatsakis (Apr 18 2019 at 14:58, on Zulip):

but (a) that revealed some subtle inconsistencies with the actual drop order for regular functions (which isn't as consistent as one might like) and (b) this wasn't so easy to do because it required more invasive changes to the AST and HIR than expected.

nikomatsakis (Apr 18 2019 at 14:58, on Zulip):

(@davidtwco was pushing on that)

nikomatsakis (Apr 18 2019 at 14:59, on Zulip):

In the meantime, cramertj has raised some arguments that perhaps the drop-order should remain as is, though I am personally unconvinced.

nikomatsakis (Apr 18 2019 at 14:59, on Zulip):

I think we're still going to want to do some fix here, but I'm not sure quite what

varkor (Apr 18 2019 at 14:59, on Zulip):

is this a compiler or language issue?

nikomatsakis (Apr 18 2019 at 14:59, on Zulip):

(It was one thing I had hoped to talk about in a possible design meeting)

nikomatsakis (Apr 18 2019 at 14:59, on Zulip):

Both, really.

nikomatsakis (Apr 18 2019 at 15:00, on Zulip):

The problem, to be clear, is that if you have an unused argument

nikomatsakis (Apr 18 2019 at 15:00, on Zulip):

In the present desugaring

nikomatsakis (Apr 18 2019 at 15:00, on Zulip):

it is never captured by the async move { } block

eddyb (Apr 18 2019 at 15:00, on Zulip):

I'm curious about the invasive changes, fwiw

nikomatsakis (Apr 18 2019 at 15:00, on Zulip):

and hence it gets dropped immediately when foo is called (i.e., before the future has begun to work)

nikomatsakis (Apr 18 2019 at 15:01, on Zulip):

But most users would expect the unused argument to get dropped when the future completes (i.e., when the async move block "returns")

nikomatsakis (Apr 18 2019 at 15:01, on Zulip):

I'm curious about the invasive changes, fwiw

Yeah, I don't really have the details on the tip of my tongue right now

nikomatsakis (Apr 18 2019 at 15:01, on Zulip):

Though @davidtwco could certainly point you to their PR

nikomatsakis (Apr 18 2019 at 15:02, on Zulip):

But most users would expect the unused argument to get dropped when the future completes (i.e., when the async move block "returns")

anyway the reason I said both is that, presuming that we want some form of this behavior, it's not entirely obvious how to implement it

eddyb (Apr 18 2019 at 15:02, on Zulip):

the desugaring you provided makes sense to me fwiw

nikomatsakis (Apr 18 2019 at 15:02, on Zulip):

I think @eddyb part of the problem is that we have no name arg0 to refer to the "argument that got given" (i.e., without the pattern)

nikomatsakis (Apr 18 2019 at 15:02, on Zulip):

the desugaring you provided makes sense to me fwiw

yes, to me too, I continue to think that's what we want

eddyb (Apr 18 2019 at 15:02, on Zulip):

however, I have a simpler one :P

davidtwco (Apr 18 2019 at 15:02, on Zulip):

Though @davidtwco could certainly point you to their PR

I had this working, but it broke when I rebased and stopped specifying the <ty> in let <pat>: <ty> = __arg0;. It causes a type inference error now and I've struggled to resolve that, would appreciate any thoughts people have on resolving that in #59823.

nikomatsakis (Apr 18 2019 at 15:03, on Zulip):

however, I have a simpler one :P

do tell :)

centril (Apr 18 2019 at 15:03, on Zulip):

@nikomatsakis so this change to introduce let pat = arg0; is done in lowering.rs, right?

eddyb (Apr 18 2019 at 15:03, on Zulip):

let _ = binding; for each binding in the enclosing fn's argument list

pnkfelix (Apr 18 2019 at 15:03, on Zulip):

/me needs to leave

pnkfelix (Apr 18 2019 at 15:03, on Zulip):

thank you @T-compiler/meeting for attending!

nikomatsakis (Apr 18 2019 at 15:03, on Zulip):

@eddyb that doesn't handle cases like

async fn foo(_: Blah) { .. }
davidtwco (Apr 18 2019 at 15:04, on Zulip):

nikomatsakis so this change to introduce let pat = arg0; is done in lowering.rs, right?

That's where we introduce the statement into the HIR, but I construct it in the parser because I need to use it in name resolution and a few other places.

nikomatsakis (Apr 18 2019 at 15:04, on Zulip):

(Should we continue in #t-compiler/wg-async-await though?)

davidtwco (Apr 18 2019 at 15:04, on Zulip):

(Should we continue in #t-compiler/wg-async-await though?)

this topic

eddyb (Apr 18 2019 at 15:04, on Zulip):

@nikomatsakis whoops, I miscalculated the scopes. in that case, just do the proposed desugaring

Nick Lawrence (Apr 18 2019 at 15:46, on Zulip):

possibly dumb question, the maintainers are who set the p-high labels?

Wesley Wiser (Apr 18 2019 at 18:44, on Zulip):

Should we write up a summary of this week's meeting? (I also volunteer to write said summary if it's desired)

pnkfelix (Apr 18 2019 at 21:39, on Zulip):

I think eddyb part of the problem is that we have no name arg0 to refer to the "argument that got given" (i.e., without the pattern)

clearly Rust needs something analogous to the arguments object in Javascript (</sarcasm>)

eddyb (Apr 19 2019 at 09:07, on Zulip):

@pnkfelix you joke, but with VG, something like:

fn foo(...args: (A, B, C)) {
    bar(args)
}

could be used, to do what you need this for, today:

fn foo(a: A, b: B, c: C) {
    bar((a, b, c))
}

and we could even allow this before actually letting you have <...Args>(...args: Args) (i.e. actual variadic generics)

nikomatsakis (Apr 22 2019 at 21:19, on Zulip):

Should we write up a summary of this week's meeting? (I also volunteer to write said summary if it's desired)

@Wesley Wiser I think we should try to do some summaries of trigae meteings -- did you ever do this?

Wesley Wiser (Apr 22 2019 at 21:27, on Zulip):

@nikomatsakis https://github.com/rust-lang/compiler-team/pull/66 :slight_smile:

Wesley Wiser (Apr 23 2019 at 13:35, on Zulip):

@nikomatsakis Just in case you didn't see my reply yesterday:

https://github.com/rust-lang/compiler-team/pull/66

nikomatsakis (Apr 24 2019 at 19:42, on Zulip):

Ah, great! merged, @Wesley Wiser

nikomatsakis (Apr 24 2019 at 20:33, on Zulip):

@Wesley Wiser you mentioned posting it in an internals thread, did you do so? Not sure which thread you would use :)

Wesley Wiser (Apr 24 2019 at 20:33, on Zulip):

@nikomatsakis I posted it in the thread you created ~2 weeks ago for triage meetings

https://internals.rust-lang.org/t/compiler-team-triage-meeting/9803/3?u=wesleywiser

nikomatsakis (Apr 24 2019 at 20:35, on Zulip):

Ooookay

nikomatsakis (Apr 24 2019 at 20:35, on Zulip):

Sounds good

nikomatsakis (Apr 24 2019 at 20:35, on Zulip):

/me can't remember what they did this morning, much less 2 weeks ago

nikomatsakis (Apr 24 2019 at 20:36, on Zulip):

(apparently)

Wesley Wiser (Apr 24 2019 at 20:36, on Zulip):

Haha no worries, I'm the same way

Wesley Wiser (Apr 24 2019 at 20:36, on Zulip):

Is the general structure of the notes what you were expecting/ok?

Wesley Wiser (Apr 24 2019 at 20:37, on Zulip):

I can also volunteer to continue writing them going forward if that's valuable

nikomatsakis (Apr 24 2019 at 20:38, on Zulip):

I think it's great, yeah

Last update: Nov 16 2019 at 01:05UTC