Stream: t-compiler

Topic: weekly meeting 2019-12-12 #54818


pnkfelix (Dec 12 2019 at 12:47, on Zulip):

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

pnkfelix (Dec 12 2019 at 12:48, on Zulip):

I will be doing pre-triage in a parallel topic

pnkfelix (Dec 12 2019 at 12:49, on Zulip):

today we are scheduled to have a checkin with WG-meta and WG-mir-opt

pnkfelix (Dec 12 2019 at 12:50, on Zulip):

@davidtwco or @Santiago Pastorino : are one of you available to provide checkin report on behalf of WG-meta at time of triage meeting?

pnkfelix (Dec 12 2019 at 12:50, on Zulip):

@oli are you available to provide a checkin report on behalf of WG-mir-opt?

davidtwco (Dec 12 2019 at 12:52, on Zulip):

@Santiago Pastorino might disagree, but I'm not sure there's anything to report from #t-compiler/wg-meta.

Santiago Pastorino (Dec 12 2019 at 12:59, on Zulip):

yeah, lately nothing substantial has been happening. I guess these checkins are since last checkin, in our last checking we've talked about ICE-breaker groups in general and LLVM one in particular. We were talking about ICE breaker reducers and diagnostics groups since then but I'm not sure if maybe @nikomatsakis has something relevant to say there

oli (Dec 12 2019 at 14:33, on Zulip):

yes, I can do a mir-opt check-in

nikomatsakis (Dec 12 2019 at 15:02, on Zulip):

Well, I think from wg-meta I could see it being useful to discuss:

pnkfelix (Dec 12 2019 at 15:02, on Zulip):

okay

nikomatsakis (Dec 12 2019 at 15:03, on Zulip):

But that in some sense is also the update, and we could have the discussion on #t-compiler/wg-meta :)

pnkfelix (Dec 12 2019 at 15:03, on Zulip):

lets get started

pnkfelix (Dec 12 2019 at 15:03, on Zulip):

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

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

so lets have five minutes for ...

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

Announcements

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

I posted an RFC about future-incompat lints, RFC 2834

eddyb (Dec 12 2019 at 15:05, on Zulip):

#66821 landed, which should give us all of these nice wins: https://perf.rust-lang.org/compare.html?start=2da942f32802c8233a09744024dfbc34431adf65&end=1ff04410af642dde1480ae29b085544c2d05c33c

pnkfelix (Dec 12 2019 at 15:05, on Zulip):

(RFC 2834 is not just a cargo thing, despite the title. It impacts rustc too.)

nikomatsakis (Dec 12 2019 at 15:05, on Zulip):

Side note, @pnkfelix, I wonder if that'd be a good "project group", since it seems to involve changes to a number of different things.

pnkfelix (Dec 12 2019 at 15:05, on Zulip):

maybe when/if it gets accepted?

eddyb (Dec 12 2019 at 15:05, on Zulip):

(I guess there should be a nightly with it now but I haven't grabbed that diff from perf)

oli (Dec 12 2019 at 15:05, on Zulip):

const eval now has if/match support (unstable) and a PR for loop/while is open

pnkfelix (Dec 12 2019 at 15:05, on Zulip):

or maybe you mean the project group should be about authoring the RFC itself?

nikomatsakis (Dec 12 2019 at 15:06, on Zulip):

Given that the RFC exists, seems fine, just create if it's accepted.

nikomatsakis (Dec 12 2019 at 15:06, on Zulip):

(And/or move some questions to be decided through that process, if needed)

pnkfelix (Dec 12 2019 at 15:07, on Zulip):

wow eddyb, nice work, -4 to -5% on a number of non-contrived benchmarks?

eddyb (Dec 12 2019 at 15:08, on Zulip):

yeah we were just not doing trait caching in the cases that matter a lot (i.e. when type parameters were involved)

eddyb (Dec 12 2019 at 15:08, on Zulip):

presumably because Chalk has been on the horizon for a while :P

nikomatsakis (Dec 12 2019 at 15:08, on Zulip):

heh yes

nikomatsakis (Dec 12 2019 at 15:08, on Zulip):

"a while"

pnkfelix (Dec 12 2019 at 15:08, on Zulip):

that is the danger of having the next gen system "within sight"

nikomatsakis (Dec 12 2019 at 15:09, on Zulip):

One announcement would be to call attention the pre-design meeting topic for the meeting tomorrow

pnkfelix (Dec 12 2019 at 15:09, on Zulip):

oh of course

nikomatsakis (Dec 12 2019 at 15:10, on Zulip):

Which is to discuss a proposal around the future of IDEs / library-ification

eddyb (Dec 12 2019 at 15:10, on Zulip):

sorry this took me a while, but I think this is the actual diff between relevant master builds https://perf.rust-lang.org/compare.html?start=033662dfbca088937b9cdfd3d9584015b5e375b2&end=90b957a17c1abba979aa41234ce0993a61030e67&stat=instructions:u

pnkfelix (Dec 12 2019 at 15:10, on Zulip):

okay so I think that's all the announcments

pnkfelix (Dec 12 2019 at 15:11, on Zulip):

if anyone has something else to add, privmsg me and I'll allocate time at the end

pnkfelix (Dec 12 2019 at 15:11, on Zulip):

so I've made an agenda hackmd

pnkfelix (Dec 12 2019 at 15:11, on Zulip):

its relatively light this week

pnkfelix (Dec 12 2019 at 15:12, on Zulip):

so lets do beta-nominations first

pnkfelix (Dec 12 2019 at 15:12, on Zulip):

beta-nom 1/2: "resolve: Always resolve visibilities on impl items" #67236

pnkfelix (Dec 12 2019 at 15:14, on Zulip):

yeah this seems clear beta-accept

pnkfelix (Dec 12 2019 at 15:15, on Zulip):

beta-nom 2/2: "resolve: Resolve visibilities on fields with non-builtin attributes" #67106

nikomatsakis (Dec 12 2019 at 15:16, on Zulip):

seems like just the 1st commit?

centril (Dec 12 2019 at 15:16, on Zulip):

yep

pnkfelix (Dec 12 2019 at 15:17, on Zulip):

ugh I should have put the first few words from the commit msg next to the hash I wrote

pnkfelix (Dec 12 2019 at 15:18, on Zulip):

anyway looks like a reasonable beta accept

pnkfelix (Dec 12 2019 at 15:19, on Zulip):

okay, next up, stable noms

pnkfelix (Dec 12 2019 at 15:19, on Zulip):

stable-nom 1/1: "resolve: Always resolve visibilities on impl items" #67236

pnkfelix (Dec 12 2019 at 15:20, on Zulip):

So, I don't know if anyone else feels this way, but have we gotten more liberal in stable-accepting

pnkfelix (Dec 12 2019 at 15:20, on Zulip):

?

mw (Dec 12 2019 at 15:20, on Zulip):

we beta accepted this and it will be stable in a week

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

is the release that soon? But maybe that's not our decision anyway

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

or rather, I'm not sure if its supposed to factor into our decision here?

mw (Dec 12 2019 at 15:21, on Zulip):

dec 19, I think

simulacrum (Dec 12 2019 at 15:21, on Zulip):

no need for stable noms this week

simulacrum (Dec 12 2019 at 15:21, on Zulip):

(we're not doing a point release for sure in the last ~2 weeks basically)

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

okay. I'll just decline based on our soon the release is

pnkfelix (Dec 12 2019 at 15:22, on Zulip):

and I'll wait until the next stable nom to check my gut again about how liberal/conservative we are with respect to stable backports

pnkfelix (Dec 12 2019 at 15:22, on Zulip):

there are three PR's marked S-waiting-on-team

pnkfelix (Dec 12 2019 at 15:22, on Zulip):

and one of them seemed worth discussing here

pnkfelix (Dec 12 2019 at 15:23, on Zulip):

S-waiting-on-team: “[experiment] Do not deduplicate diagnostics in -Z ui-testing mode” #67122

pnkfelix (Dec 12 2019 at 15:23, on Zulip):

I mention it here not to try to resolve the questions posed there

pnkfelix (Dec 12 2019 at 15:24, on Zulip):

but rather to raise awareness. I,e. read over the disxcussion and post your feedback

pnkfelix (Dec 12 2019 at 15:24, on Zulip):

there are also a bunch of nominated issues. I picked two of them to discuss here

pnkfelix (Dec 12 2019 at 15:25, on Zulip):

I-nominated: "MacOS: add linker flag "-undefined dynamic_lookup" for shared libs." #66204

pnkfelix (Dec 12 2019 at 15:25, on Zulip):

this has been in flight since November 8th

pnkfelix (Dec 12 2019 at 15:26, on Zulip):

As I understand it, the PR author is making a crate to make it possible to write postgres extensions in Rust

nikomatsakis (Dec 12 2019 at 15:26, on Zulip):

I am reminded of the discussion about internalize symbols

pnkfelix (Dec 12 2019 at 15:26, on Zulip):

in what sense?

nikomatsakis (Dec 12 2019 at 15:27, on Zulip):

Mostly that I feel like we lack a clear "plan" around linkers :)

pnkfelix (Dec 12 2019 at 15:27, on Zulip):

that it was an area that is not richly specified?

nikomatsakis (Dec 12 2019 at 15:27, on Zulip):

I guess they're not overly related

pnkfelix (Dec 12 2019 at 15:27, on Zulip):

ah yes

pnkfelix (Dec 12 2019 at 15:27, on Zulip):

well the funny thing that struck me about that

nikomatsakis (Dec 12 2019 at 15:27, on Zulip):

I just wish that we had some folks who owned this area

pnkfelix (Dec 12 2019 at 15:27, on Zulip):

is that we seemed to feel free to change behavior with respect to internalization of symbols

pnkfelix (Dec 12 2019 at 15:27, on Zulip):

and just say "well it seems to work!"

pnkfelix (Dec 12 2019 at 15:28, on Zulip):

while here, alex is saying we've never changed linker arguments

pnkfelix (Dec 12 2019 at 15:28, on Zulip):

due to how conservative we want to try to be

pnkfelix (Dec 12 2019 at 15:28, on Zulip):

I'm certainly a fan of taking conservative approaches

pnkfelix (Dec 12 2019 at 15:28, on Zulip):

but it just struck me as funny, since I didn't think this project was necessarily conservative in such matters

mw (Dec 12 2019 at 15:29, on Zulip):

I think Rust dylibs were always a special case where we were not so conservative

pnkfelix (Dec 12 2019 at 15:29, on Zulip):

true. This PR is changing linker flags for a broader set of cases

nikomatsakis (Dec 12 2019 at 15:29, on Zulip):

It seems like part of the problem here

nikomatsakis (Dec 12 2019 at 15:29, on Zulip):

is that the PR is changed the defaults

pnkfelix (Dec 12 2019 at 15:29, on Zulip):

anyway, there is a meta-topic here

pnkfelix (Dec 12 2019 at 15:30, on Zulip):

which is that this author just wants to find someone to take responsibility for a decision here

pnkfelix (Dec 12 2019 at 15:30, on Zulip):

and everyone says "shoot, I'm not an expert in that area."

nikomatsakis (Dec 12 2019 at 15:31, on Zulip):

This seems pretty clearly (to me) like the wrong fix

pnkfelix (Dec 12 2019 at 15:31, on Zulip):

personally I think the right solution may be something like what was suggested in the comments

pnkfelix (Dec 12 2019 at 15:31, on Zulip):

where an upstream crate could have a build.rs that generates flags that influence its clients linker invocations

pnkfelix (Dec 12 2019 at 15:31, on Zulip):

changing the defaults for everyone does sound like a very crude hammer

nikomatsakis (Dec 12 2019 at 15:31, on Zulip):

I'll try to leave a comment about it. I'm not sure what I think the right fix is. But indiscriminately changing our default linker arguments to not error on undefined symbols for all builds on Mac OS just seems like it can't be right.

nikomatsakis (Dec 12 2019 at 15:32, on Zulip):

At minimum it feels like it merits an RFC to get more eyes and feedback

pnkfelix (Dec 12 2019 at 15:32, on Zulip):

is this person building a dylib?

nikomatsakis (Dec 12 2019 at 15:32, on Zulip):

Anyway, it is an interesting situation, but I don't think we should land a broad change like this without somebody owning it, and sometimes that bandwidth is not around.

pnkfelix (Dec 12 2019 at 15:32, on Zulip):

yes, they are building a dylib

pnkfelix (Dec 12 2019 at 15:33, on Zulip):

so the change in behavior isn't for all linker invocations.

pnkfelix (Dec 12 2019 at 15:33, on Zulip):

just for linking to build a dylib, I think.

mw (Dec 12 2019 at 15:33, on Zulip):

Rust dylib or C dylib?

pnkfelix (Dec 12 2019 at 15:33, on Zulip):

oh good point ...

mw (Dec 12 2019 at 15:34, on Zulip):

Rust dylibs are such a sad feature

pnkfelix (Dec 12 2019 at 15:34, on Zulip):

I cannot tell off hand from the diff context

nikomatsakis (Dec 12 2019 at 15:34, on Zulip):

you are correct that it's a bit more narrow

nikomatsakis (Dec 12 2019 at 15:34, on Zulip):

but it's still not "opt-in" in any sense

nikomatsakis (Dec 12 2019 at 15:34, on Zulip):

I believe this is when building a C dylib

nikomatsakis (Dec 12 2019 at 15:35, on Zulip):

that said, it's sort of surprising to me that we don't have some way to configure the linker flags for a project

pnkfelix (Dec 12 2019 at 15:35, on Zulip):

okay well we have probably spent enough time on this

pnkfelix (Dec 12 2019 at 15:35, on Zulip):

Unless someone wants to claim ownership of this topic?

pnkfelix (Dec 12 2019 at 15:36, on Zulip):

anyway lets move to another nominated issue

pnkfelix (Dec 12 2019 at 15:36, on Zulip):

I-nominated: "./x.py check failed if incremental builds enabled"
#58633

pnkfelix (Dec 12 2019 at 15:36, on Zulip):

so this is an old issue that I plugged some time ago

pnkfelix (Dec 12 2019 at 15:36, on Zulip):

but its rearing its head again

eddyb (Dec 12 2019 at 15:37, on Zulip):

I think things have gotten hectic since we've started not removing incremental caches all the time (cc @simulacrum)

eddyb (Dec 12 2019 at 15:37, on Zulip):

when it works, it's great, when it doesn't, rm -r

pnkfelix (Dec 12 2019 at 15:38, on Zulip):

but here one runs into it during every attempt to develop on a certain part of libcore ?

simulacrum (Dec 12 2019 at 15:38, on Zulip):

this is true, we're now essentially never cleaning out your target directories

eddyb (Dec 12 2019 at 15:38, on Zulip):

(previously a change in e.g. libstd would cause all of the librustc_* incremental caches to be destroyed, even if they were likely still mostly usable, and fixing that is why we changed anything here)

pnkfelix (Dec 12 2019 at 15:39, on Zulip):

so maybe I misunderstand

nikomatsakis (Dec 12 2019 at 15:39, on Zulip):

huh, wait, what are we doing here?

nikomatsakis (Dec 12 2019 at 15:39, on Zulip):

we're just re-using the old incremental data even though the compiler has changed in the interim?

eddyb (Dec 12 2019 at 15:39, on Zulip):

@nikomatsakis presumably rustc itself can detect that situation?

mw (Dec 12 2019 at 15:39, on Zulip):

it certainly can't :)

eddyb (Dec 12 2019 at 15:40, on Zulip):

getting some strong deja-vu about this

nikomatsakis (Dec 12 2019 at 15:40, on Zulip):

I mean if it could

mw (Dec 12 2019 at 15:40, on Zulip):

It can usually, but not during bootstrapping

nikomatsakis (Dec 12 2019 at 15:40, on Zulip):

it'd be no different than us doing rm -rf

mw (Dec 12 2019 at 15:40, on Zulip):

because it relies on git commit hashes

nikomatsakis (Dec 12 2019 at 15:40, on Zulip):

(right?)

eddyb (Dec 12 2019 at 15:40, on Zulip):

@mw but isn't the problem that beta changed?

eddyb (Dec 12 2019 at 15:41, on Zulip):

stage1 doesn't use incremental AFAIK, so a locally built compiler isn't a concern

mw (Dec 12 2019 at 15:41, on Zulip):

@eddyb hm, that should be detected, I guess

eddyb (Dec 12 2019 at 15:41, on Zulip):

and ./x.py check doesn't run a locally built compiler anyway

mw (Dec 12 2019 at 15:42, on Zulip):

this might be a differently problem then

eddyb (Dec 12 2019 at 15:42, on Zulip):

hmm based on https://github.com/rust-lang/rust/issues/58633#issuecomment-562738568 it might be a problem with reusing caches for different compilation modes

mw (Dec 12 2019 at 15:43, on Zulip):

do we still fill the "used attributes" map as a side-effect of certain queries?

eddyb (Dec 12 2019 at 15:43, on Zulip):

but I get something similar (... or so I thought?) when beta changes (spurious attribute-related errors), and I have to nuke stage0-std. and I don't ever use ./x.py check

mw (Dec 12 2019 at 15:44, on Zulip):

if the [tracked] and [untracked] annoations for commandline args are correct, different modes should not be a problem

mw (Dec 12 2019 at 15:45, on Zulip):

but if used-attributes detection relies on certain queries to run, but incremental skips those queries...

pnkfelix (Dec 12 2019 at 15:48, on Zulip):

okay forked thread into zulip topic

pnkfelix (Dec 12 2019 at 15:48, on Zulip):

zulip topic title "x.py check fails under incremental due to unused attr weirdness #58633"

davidtwco (Dec 12 2019 at 15:49, on Zulip):

(#t-compiler > x.py check fails under incremental due to unused attr wei... )

pnkfelix (Dec 12 2019 at 15:49, on Zulip):

thank you

pnkfelix (Dec 12 2019 at 15:49, on Zulip):

okay so lets do some WG checkins

oli (Dec 12 2019 at 15:49, on Zulip):

wg-mir-opt check-in

I may have forgotten some peephole optimization or sth, the last month was insane.

Also @eddyb has an announcement about a mir-optimization

pnkfelix (Dec 12 2019 at 15:50, on Zulip):

okay @oli has taken the reins

eddyb (Dec 12 2019 at 15:50, on Zulip):

my announcement is that I'm resurrecting https://github.com/rust-lang/rust/pull/48300

eddyb (Dec 12 2019 at 15:50, on Zulip):

two years of dust have not been kind to it :P

nikomatsakis (Dec 12 2019 at 15:51, on Zulip):

This all sounds fantastic, man, so much going on.

eddyb (Dec 12 2019 at 15:51, on Zulip):

it's a relatively small optimization, but it should hopefully play well with others (such as const prop, in e.g. structs with mixed runtime and constant fields)

nikomatsakis (Dec 12 2019 at 15:51, on Zulip):

I want to give a shout-out to @oli, at least from what @Santiago Pastorino tells me, @oli has been doing a ton of mentoring and general leadership here. :clap: :clap: :clap:

Wesley Wiser (Dec 12 2019 at 15:52, on Zulip):

Yes, @oli has been doing a fantastic job!!

centril (Dec 12 2019 at 15:52, on Zulip):

We also have plans for optimizations for removing unreachable blocks, BB-deduplication, etc.

Santiago Pastorino (Dec 12 2019 at 15:52, on Zulip):

@oli great work!!! :heart:

centril (Dec 12 2019 at 15:52, on Zulip):

@oli what happened to referring to statics in constants?

Santiago Pastorino (Dec 12 2019 at 15:53, on Zulip):

there's also this coming https://github.com/rust-lang/rust/pull/67000, it's literally done, there's not PlaceBase anymore, just Local

oli (Dec 12 2019 at 15:53, on Zulip):

oli what happened to referring to statics in constants?

not merged, in work: https://github.com/rust-lang/rust/pull/66302

pnkfelix (Dec 12 2019 at 15:54, on Zulip):

okay great

pnkfelix (Dec 12 2019 at 15:55, on Zulip):

Regarding WG-meta, there wasn't much to report it sounded like. But @nikomatsakis did say:

Well, I think from wg-meta I could see it being useful to discuss:

mw (Dec 12 2019 at 15:55, on Zulip):

MIR optimization might be a good success story of how much potential can be freed once a component is cleanly encapsulated

pnkfelix (Dec 12 2019 at 15:56, on Zulip):

but maybe that was more directed at the WG-meta members themselves, and not T-compiler ?

eddyb (Dec 12 2019 at 15:56, on Zulip):

@mw only took 2-3 years of limbo :P

nikomatsakis (Dec 12 2019 at 15:56, on Zulip):

No, I'd like feedback from anyone

pnkfelix (Dec 12 2019 at 15:57, on Zulip):

I think a reducer ICE-breaker would be great

nikomatsakis (Dec 12 2019 at 15:57, on Zulip):

I think that's the obvious next step

nikomatsakis (Dec 12 2019 at 15:57, on Zulip):

Ah there is one other thing

pnkfelix (Dec 12 2019 at 15:57, on Zulip):

potentially orthogonally: after my blog post on rust reduction pattersn

nikomatsakis (Dec 12 2019 at 15:57, on Zulip):

@Santiago Pastorino has been working on improving cargo-bisect

nikomatsakis (Dec 12 2019 at 15:57, on Zulip):

which I was kind of semi-waiting on

pnkfelix (Dec 12 2019 at 15:57, on Zulip):

people did mention trying to put my strategies into creduce

nikomatsakis (Dec 12 2019 at 15:57, on Zulip):

since it seemed like having a really easily usable bisection tool would make it easier

nikomatsakis (Dec 12 2019 at 15:58, on Zulip):

When I read your post @pnkfelix I was thinking it might make sense to have a kind of "lightweight" description and then "heavier-weight" strategies

nikomatsakis (Dec 12 2019 at 15:58, on Zulip):

i.e., I tend to do something rather different, but I fall back to strategies like yours is I'm having trouble

nikomatsakis (Dec 12 2019 at 15:58, on Zulip):

I suspect @centril has some good tips, since I know they do a lot of reducing too

pnkfelix (Dec 12 2019 at 15:59, on Zulip):

i.e., I tend to do something rather different, but I fall back to strategies like yours is I'm having trouble

yeah, I think it can depend on how well you understand the code in question from the outset

centril (Dec 12 2019 at 15:59, on Zulip):

@pnkfelix's post is mostly around big projects

pnkfelix (Dec 12 2019 at 15:59, on Zulip):

and I was trying to describe how you could work effectively blind

centril (Dec 12 2019 at 15:59, on Zulip):

I tend to shrink issues that already fit in the playground

eddyb (Dec 12 2019 at 16:00, on Zulip):

keep in mind you can go from a dozen lines to 50k lines to a dozen lines again

eddyb (Dec 12 2019 at 16:00, on Zulip):

if you include dependencies

pnkfelix (Dec 12 2019 at 16:00, on Zulip):

and macro-expansions

pnkfelix (Dec 12 2019 at 16:00, on Zulip):

(which I guess is a kind of dependency)

eddyb (Dec 12 2019 at 16:00, on Zulip):

so "fits in playground" is not specific enough :P

centril (Dec 12 2019 at 16:00, on Zulip):

@eddyb zero dependencies

centril (Dec 12 2019 at 16:00, on Zulip):

200 LOC max

pnkfelix (Dec 12 2019 at 16:01, on Zulip):

pretty sure you don't use #![no_std] for all your reductions

pnkfelix (Dec 12 2019 at 16:01, on Zulip):

but that's just me being petty

Matthew Jasper (Dec 12 2019 at 16:01, on Zulip):

#![no_core] or it doesn't count. :upside_down:

centril (Dec 12 2019 at 16:01, on Zulip):

only if it would simplify finding the bug ^^

pnkfelix (Dec 12 2019 at 16:01, on Zulip):

okay I have a hard out now at the hour mark

eddyb (Dec 12 2019 at 16:01, on Zulip):

I still regret bothering with #![no_std] when the bug had nothing to do with anything I was imagining

pnkfelix (Dec 12 2019 at 16:01, on Zulip):

thank you to all of @T-compiler/meeting for attending! this was a great meeting you all!

centril (Dec 12 2019 at 16:13, on Zulip):

Post meeting announcement: I've hacked up an experimental (in the sense of the proposal) but full implementation of half-open range patterns, https://github.com/rust-lang/rust/pull/67258

Last update: May 26 2020 at 10:05UTC