Stream: t-compiler

Topic: weekly meeting 2020-02-06 #54818


pnkfelix (Feb 06 2020 at 12:16, on Zulip):

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

pnkfelix (Feb 06 2020 at 12:17, on Zulip):

I will be doing pre-triage in a parallel topic

pnkfelix (Feb 06 2020 at 12:17, on Zulip):

this week's WG checkins are with @WG-rls2.0 and @WG-self-profile

pnkfelix (Feb 06 2020 at 12:18, on Zulip):

@matklad , will you be around in about 3.5 hours to provide checkin for RLS 2.0?

pnkfelix (Feb 06 2020 at 12:19, on Zulip):

@mw or @Wesley Wiser , will you be around in about 3.5 hours to provide checkin for WG-self-profile?

pnkfelix (Feb 06 2020 at 12:34, on Zulip):

I'll be building up today's specific agenda on this hackmd as I do pre-triage

mw (Feb 06 2020 at 12:39, on Zulip):

@pnkfelix I can give an update on WG-self-profile

matklad (Feb 06 2020 at 12:47, on Zulip):

@pnkfelix will be there!

pnkfelix (Feb 06 2020 at 14:59, on Zulip):

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

pnkfelix (Feb 06 2020 at 14:59, on Zulip):

we'll start with five minutes for ...

pnkfelix (Feb 06 2020 at 15:00, on Zulip):

Announcements

pnkfelix (Feb 06 2020 at 15:00, on Zulip):
pnkfelix (Feb 06 2020 at 15:00, on Zulip):

(meeting is, as usual, on Friday, starting same time as this meeting.)

pnkfelix (Feb 06 2020 at 15:01, on Zulip):

there's some great stuff to read up on ahead of time, if you follow the link above.

pnkfelix (Feb 06 2020 at 15:02, on Zulip):

@davidtwco are you around? Did you want to say anything about the status of your polymorphization work, or design questions there?

pnkfelix (Feb 06 2020 at 15:02, on Zulip):
pnkfelix (Feb 06 2020 at 15:03, on Zulip):
mw (Feb 06 2020 at 15:04, on Zulip):

(as major changes go, the proposed change is rather minor :) I mostly wanted to give the new process a test drive)

pnkfelix (Feb 06 2020 at 15:05, on Zulip):

Makes sense! (and so it makes sense for me to announce it here,as part of that test drive.)

mw (Feb 06 2020 at 15:05, on Zulip):

it does indeed

pnkfelix (Feb 06 2020 at 15:06, on Zulip):

one more announcement

pnkfelix (Feb 06 2020 at 15:06, on Zulip):
pnkfelix (Feb 06 2020 at 15:07, on Zulip):

but it does interact with rustc too, so feel free to take a look there and give feedback.

pnkfelix (Feb 06 2020 at 15:07, on Zulip):

okay so having said all that, lets move on to the meeting agenda.

pnkfelix (Feb 06 2020 at 15:08, on Zulip):

agenda items

pnkfelix (Feb 06 2020 at 15:08, on Zulip):

first, beta-nominations

pnkfelix (Feb 06 2020 at 15:08, on Zulip):

beta-nom 1/2: "Correct ICE caused by macros generating invalid spans." #68611

pnkfelix (Feb 06 2020 at 15:10, on Zulip):

I have to ask myself, should we be investing effort in fixing the fundamental brokenness with macros generating invalid spans? Hmm.

nikomatsakis (Feb 06 2020 at 15:10, on Zulip):

seems harmless to backport, though an unconditional warn is suboptimal

nikomatsakis (Feb 06 2020 at 15:11, on Zulip):

er, I guess it's a warn through log

pnkfelix (Feb 06 2020 at 15:11, on Zulip):

are you concerned that it e.g. won't respect cap-lints ?

nikomatsakis (Feb 06 2020 at 15:11, on Zulip):

not sure what that does by default

pnkfelix (Feb 06 2020 at 15:11, on Zulip):

/me doesn't know

nikomatsakis (Feb 06 2020 at 15:11, on Zulip):

well I mean it's obviously debug spew:

nikomatsakis (Feb 06 2020 at 15:11, on Zulip):
         warn!("Invalid span {:?}. Err={:?}", sp, e);
nikomatsakis (Feb 06 2020 at 15:11, on Zulip):

i.e., not suitable for an end user

pnkfelix (Feb 06 2020 at 15:11, on Zulip):

right. so the question, as you point out, is what does log::warn! do for a rustc end-user in the first place...

pnkfelix (Feb 06 2020 at 15:12, on Zulip):

maybe we hold off on backporting this until after we resolve that question?

pnkfelix (Feb 06 2020 at 15:12, on Zulip):

anyone want to take point on looking into that?

pnkfelix (Feb 06 2020 at 15:12, on Zulip):

(I would but I already self-assigned a bunch of bugs during pre-triage...)

pnkfelix (Feb 06 2020 at 15:13, on Zulip):

well anyway the point is that we will wait a week on this. (and likewise for the corresponding stable nom of the same PR)

nikomatsakis (Feb 06 2020 at 15:14, on Zulip):

what is the timeline till next release?

nikomatsakis (Feb 06 2020 at 15:14, on Zulip):

seems ok to wait a week, let's just leave a comment

nikomatsakis (Feb 06 2020 at 15:14, on Zulip):

it's also true that there's no test (as @centril pointed out on the PR)

mw (Feb 06 2020 at 15:14, on Zulip):

we had a release last week

simulacrum (Feb 06 2020 at 15:14, on Zulip):

5 weeks?

simulacrum (Feb 06 2020 at 15:14, on Zulip):

March 12th 2020

pnkfelix (Feb 06 2020 at 15:15, on Zulip):

seems ok to wait a week, let's just leave a comment

done

pnkfelix (Feb 06 2020 at 15:15, on Zulip):

(a regression test might also have allowed for more immediate answer to our running Q regarding warn!)

pnkfelix (Feb 06 2020 at 15:16, on Zulip):

beta-nom 2/2: "Do not ICE on multipart suggestions touching multiple files" #68530

pnkfelix (Feb 06 2020 at 15:17, on Zulip):

another case where there is no regression test

nikomatsakis (Feb 06 2020 at 15:17, on Zulip):

yeah, I just left a comment about that

pnkfelix (Feb 06 2020 at 15:17, on Zulip):

it does seem "obviously correct" :)

pnkfelix (Feb 06 2020 at 15:18, on Zulip):

beta-approved then. We can do a regression test as a followup: @Esteban Küber do you mind making a PR with a regression test (no need for backport of the test, i think)

nikomatsakis (Feb 06 2020 at 15:18, on Zulip):

it does seem "obviously correct" :)

yes, I would be more interested in future refactorings maintaining that property

pnkfelix (Feb 06 2020 at 15:19, on Zulip):

I wonder if one could even lint for this

pnkfelix (Feb 06 2020 at 15:19, on Zulip):

I bet clippy aleady does

pnkfelix (Feb 06 2020 at 15:19, on Zulip):

"You're using unwrap in a method where ? would work"

simulacrum (Feb 06 2020 at 15:20, on Zulip):

hm, that seems like not always correct, so would need to be allow by default at least

pnkfelix (Feb 06 2020 at 15:20, on Zulip):

oKay that's all the beta-noms, and we're skipping the single stable-nom (its the same as the first beta-nom that we are waiting a week on.)

Esteban Küber (Feb 06 2020 at 15:20, on Zulip):

That can change the logic: sometimes bubbling up the error is incorrect and panicking is

pnkfelix (Feb 06 2020 at 15:20, on Zulip):

hm, that seems like not always correct, so would need to be allow by default at least

its definitely not always correct.

pnkfelix (Feb 06 2020 at 15:21, on Zulip):

anyway we need not go into the weeds there.

pnkfelix (Feb 06 2020 at 15:22, on Zulip):

there are three PRs marked S-waiting-on-team. I picked out one of them for us to discuss now:

pnkfelix (Feb 06 2020 at 15:22, on Zulip):

"Print nicer async/await trait errors for generators in any place in the error 'stack'"e #67116

pnkfelix (Feb 06 2020 at 15:22, on Zulip):

@nikomatsakis you want to drive discussion here, since you marked it thus?

pnkfelix (Feb 06 2020 at 15:23, on Zulip):

I'm guessing its waiting on us to decide about the "information overload" questions ?

nikomatsakis (Feb 06 2020 at 15:23, on Zulip):

that's right

nikomatsakis (Feb 06 2020 at 15:23, on Zulip):

I kind of forgot about this

nikomatsakis (Feb 06 2020 at 15:24, on Zulip):

but basically we seem to be at an impasse

nikomatsakis (Feb 06 2020 at 15:24, on Zulip):

and I'm looking to broaden the set of folks and get some idea how to resolve

pnkfelix (Feb 06 2020 at 15:24, on Zulip):

are there rustc flags to control the level of information output?

nikomatsakis (Feb 06 2020 at 15:24, on Zulip):

Not that I know of

nikomatsakis (Feb 06 2020 at 15:24, on Zulip):

I think it's debatable if we want to go that road

nikomatsakis (Feb 06 2020 at 15:24, on Zulip):

We have talked in the past about a --learn flag, to give more useful output for beginners

nikomatsakis (Feb 06 2020 at 15:24, on Zulip):

but this would be something rather different I suppose

nikomatsakis (Feb 06 2020 at 15:25, on Zulip):

In any case, we don't have one.

pnkfelix (Feb 06 2020 at 15:25, on Zulip):

I do see that @simulacrum suggested something similar on the comment thread

nikomatsakis (Feb 06 2020 at 15:25, on Zulip):

I remember scala had a flag like this

simulacrum (Feb 06 2020 at 15:25, on Zulip):

We do have -Zteach today

nikomatsakis (Feb 06 2020 at 15:25, on Zulip):

I don't remember ever using it myself :)

nikomatsakis (Feb 06 2020 at 15:25, on Zulip):

Yeah, but this isn't really about teaching

simulacrum (Feb 06 2020 at 15:25, on Zulip):

used... in some places

pnkfelix (Feb 06 2020 at 15:25, on Zulip):

This is an interesting point: "The issue with this is that enabling it will require a full rebuilds if the entire crate graph (and then another rebuild when you disable it again)."

pnkfelix (Feb 06 2020 at 15:25, on Zulip):

Seems like we could/should have a way to work around that.

nikomatsakis (Feb 06 2020 at 15:25, on Zulip):

That's not actually true

nikomatsakis (Feb 06 2020 at 15:26, on Zulip):

cargo rustc -- -Zteach, for example

nikomatsakis (Feb 06 2020 at 15:26, on Zulip):

would do the job

simulacrum (Feb 06 2020 at 15:26, on Zulip):

(though notably that won't always work)

nikomatsakis (Feb 06 2020 at 15:26, on Zulip):

but I Think we'd really want

nikomatsakis (Feb 06 2020 at 15:26, on Zulip):

cargo build --teach

pnkfelix (Feb 06 2020 at 15:26, on Zulip):

cargo rustc -- -Zteach, for example

as in, cargo does not treat -Zteach as something that should force a rebuild?

nikomatsakis (Feb 06 2020 at 15:26, on Zulip):

regardless, I maintain that this is more of a "verbose" output thing

eddyb (Feb 06 2020 at 15:26, on Zulip):

cargo rustc flags only affect the leaf compilation

nikomatsakis (Feb 06 2020 at 15:26, on Zulip):

I don't think that Teaching and giving all the info are equivalent, in other words

pnkfelix (Feb 06 2020 at 15:27, on Zulip):

Right, I agree that teach is not the right thing here.

nikomatsakis (Feb 06 2020 at 15:27, on Zulip):

In fact, maybe the opposite in some ways :)

pnkfelix (Feb 06 2020 at 15:27, on Zulip):

cargo rustc flags only affect the leaf compilation

gotcha.

eddyb (Feb 06 2020 at 15:27, on Zulip):

(so cargo rustc -p foo -- bar will build all dependencies of foo then run rustc for foo with bar as extra flags)

pnkfelix (Feb 06 2020 at 15:27, on Zulip):

(maybe I (and Aaron1011?) was thinking of RUSTC_FLAGS RUSTFLAGS ?)

nikomatsakis (Feb 06 2020 at 15:28, on Zulip):

Yes, I think so

simulacrum (Feb 06 2020 at 15:28, on Zulip):

RUSTFLAGS, but yes

nikomatsakis (Feb 06 2020 at 15:28, on Zulip):

Anyway, I guess I still believe that a more minimal output will be better, and that the danger of too much info is real, but as I wrote, i'm open to being told I am wrong. Maybe we should do some sort of poll on internals? twitter poll? I don't know

eddyb (Feb 06 2020 at 15:28, on Zulip):

RUSTFLAGS affects the entire dependency graph yeah

pnkfelix (Feb 06 2020 at 15:28, on Zulip):

Okay well we've given the PR some visibility

pnkfelix (Feb 06 2020 at 15:28, on Zulip):

we don't need to make a decision right here

simulacrum (Feb 06 2020 at 15:28, on Zulip):

I (still) think we should land it in nightly a note: asking for feedback if people are overwhelmed

nikomatsakis (Feb 06 2020 at 15:28, on Zulip):

This is why I was suggesting that it'd be good to have some canonical writeup + example

nikomatsakis (Feb 06 2020 at 15:29, on Zulip):

I (still) think we should land it in nightly a note: asking for feedback if people are overwhelmed

Interesting. We can discuss on thread. I feel like if they're overwhelmed, they'll skip past that too :)

pnkfelix (Feb 06 2020 at 15:29, on Zulip):

is there already a zulip topic for this PR for followup chat?

nikomatsakis (Feb 06 2020 at 15:29, on Zulip):

Not that I'm aware of, discussion is on the PR

pnkfelix (Feb 06 2020 at 15:30, on Zulip):

okay. I guess we can keep discussion on PR if people like that, the comment thread there hasn't gotten out of control (yet)

nikomatsakis (Feb 06 2020 at 15:30, on Zulip):

I'm going to try and open an internals topic I think

nikomatsakis (Feb 06 2020 at 15:30, on Zulip):

I'd like feedback from users most of all

pnkfelix (Feb 06 2020 at 15:31, on Zulip):

okay, I assume @nikomatsakis will post link to internals thread on the PR #67116's comment thread

pnkfelix (Feb 06 2020 at 15:31, on Zulip):

so lets move on

pnkfelix (Feb 06 2020 at 15:31, on Zulip):

I picked out five nominated issues for us to look at

pnkfelix (Feb 06 2020 at 15:31, on Zulip):

nominated: "TEXTREL in i686 since 1.41.0" #68794

pnkfelix (Feb 06 2020 at 15:31, on Zulip):

a change to compiler-builtins has broken android-x86

pnkfelix (Feb 06 2020 at 15:32, on Zulip):

I self-assigned this but I suspect there may be someone at this meeting better suited to investivgate

simulacrum (Feb 06 2020 at 15:32, on Zulip):

specifically it's https://github.com/rust-lang/rust/commit/76a252ea9e7be93a61ffdf33b3533e24a9cf459d

pnkfelix (Feb 06 2020 at 15:32, on Zulip):

and also: Do we not test Android-x86 in our CI?

simulacrum (Feb 06 2020 at 15:33, on Zulip):

we test arm-linux-androideabi

pnkfelix (Feb 06 2020 at 15:33, on Zulip):

gotcha

simulacrum (Feb 06 2020 at 15:33, on Zulip):

no idea whether that's x86, to be honest

pnkfelix (Feb 06 2020 at 15:33, on Zulip):

the fact that it says "arm" makes me assume it is not x86

nikomatsakis (Feb 06 2020 at 15:34, on Zulip):

sounds correct:)

simulacrum (Feb 06 2020 at 15:34, on Zulip):

we do build rust for some other androids

pnkfelix (Feb 06 2020 at 15:34, on Zulip):

but I'm the one who didn't know that SystemV meant "everyone but windows" so what do I know

simulacrum (Feb 06 2020 at 15:34, on Zulip):

I'm not yet clear if the problem is that you cannot build rust, or if it's some internal linting

simulacrum (Feb 06 2020 at 15:34, on Zulip):

e.g. for whatever reason they don't want textrel

pnkfelix (Feb 06 2020 at 15:35, on Zulip):

anyway, is there anyone present with experience building for android-i686?

pnkfelix (Feb 06 2020 at 15:35, on Zulip):

(or "x86", whatever)

nikomatsakis (Feb 06 2020 at 15:35, on Zulip):

Breaking android definitely seems bad, though I don't know how common i686 is -- the problem is specific to i686?

nikomatsakis (Feb 06 2020 at 15:35, on Zulip):

I guess it'd be good to know which of those compiler-builtin PRs broke this, eh?

pnkfelix (Feb 06 2020 at 15:36, on Zulip):

the hypothesis is that it was https://github.com/rust-lang/compiler-builtins/pull/328

pnkfelix (Feb 06 2020 at 15:36, on Zulip):

and I think that was confirmed....?

nikomatsakis (Feb 06 2020 at 15:36, on Zulip):

(Can I note one thing: it'd be nice if we had a github alias for "folks who work on / maintain compiler-builtlins")

nikomatsakis (Feb 06 2020 at 15:36, on Zulip):

I honestly have no idea who that is :)

pnkfelix (Feb 06 2020 at 15:37, on Zulip):

and I think that was confirmed....?

oh, no, just the rollup commit bumping compiler-builtins was confirmed

simulacrum (Feb 06 2020 at 15:37, on Zulip):

I think @gnzlbg and @Alex Crichton are probably good "point people" but not sure

pnkfelix (Feb 06 2020 at 15:38, on Zulip):

okay. Maybe I will try to ping them later, since no one else is jumping up and down saying that they are the local Android-x86 enthusiast

pnkfelix (Feb 06 2020 at 15:38, on Zulip):

lets move on

pnkfelix (Feb 06 2020 at 15:38, on Zulip):

nominated: "Unable to compile syntex_syntax using Rust 1.41" #68729

pnkfelix (Feb 06 2020 at 15:39, on Zulip):

I nominated this because I wanted to draw attention to the issue

pnkfelix (Feb 06 2020 at 15:39, on Zulip):

namely, we knew that this breakage was coming from a crater run

mw (Feb 06 2020 at 15:39, on Zulip):

looks like a WONTFIX to me

pnkfelix (Feb 06 2020 at 15:40, on Zulip):

(it was noted back in october)

pnkfelix (Feb 06 2020 at 15:40, on Zulip):

I personally suspect that we should just treat this as fuel to motivate moving on cargo-report-future-incompat

simulacrum (Feb 06 2020 at 15:40, on Zulip):

I also recall seeing this in the beta crater run but think I skipped filing an issue due to finding the PR

pnkfelix (Feb 06 2020 at 15:40, on Zulip):

but I wanted to at least point it out.

pnkfelix (Feb 06 2020 at 15:41, on Zulip):

the bug filer said "However, this kind of known breaking changes should be declared in blog posts of rustlang update."

nikomatsakis (Feb 06 2020 at 15:41, on Zulip):

I was just going to mention that

nikomatsakis (Feb 06 2020 at 15:41, on Zulip):

I think that is indeed reasonable, and I also liked your idea of keeping some kind of track, though I don't know how to do that in a reasonable way

pnkfelix (Feb 06 2020 at 15:42, on Zulip):

I can imagine there is tension between not wanting to draw unnecessary attention to breakage (i.e. inviting people to say "they're breaking their stability promise" when the reality is that the breakage truly does not matter)

simulacrum (Feb 06 2020 at 15:42, on Zulip):

I think we've generally tried to stick it in compat notes

pnkfelix (Feb 06 2020 at 15:42, on Zulip):

where?

simulacrum (Feb 06 2020 at 15:42, on Zulip):

(RELEASES.md)

simulacrum (Feb 06 2020 at 15:43, on Zulip):

but it's hard

simulacrum (Feb 06 2020 at 15:43, on Zulip):

e.g. inference breakage is expansive

nikomatsakis (Feb 06 2020 at 15:43, on Zulip):

I agree, I think the idea is to tag the PR as "relnotes" or something?

simulacrum (Feb 06 2020 at 15:43, on Zulip):

if the PR is tagged as relnotes, it has a much higher chance of not getting forgotten :)

pnkfelix (Feb 06 2020 at 15:43, on Zulip):

/me looks to see if RELEASES.md is linked from the blog post

nikomatsakis (Feb 06 2020 at 15:43, on Zulip):

what is hard, naming all the crates?

simulacrum (Feb 06 2020 at 15:43, on Zulip):

I guess we can lean towards being less constrained

simulacrum (Feb 06 2020 at 15:43, on Zulip):

no, figuring out "Should we list this?"

nikomatsakis (Feb 06 2020 at 15:44, on Zulip):

what makes it hard?

nikomatsakis (Feb 06 2020 at 15:44, on Zulip):

(maybe we should discuss offline; just trying to understand the details)

simulacrum (Feb 06 2020 at 15:44, on Zulip):

I guess -- tradeoff that @pnkfelix mentioned

simulacrum (Feb 06 2020 at 15:44, on Zulip):

I can imagine there is tension between not wanting to draw unnecessary attention to breakage (i.e. inviting people to say "they're breaking their stability promise" when the reality is that the breakage truly does not matter)

nikomatsakis (Feb 06 2020 at 15:44, on Zulip):

OK.

pnkfelix (Feb 06 2020 at 15:44, on Zulip):

well if an error message is associated with a new breaking-change, is there harm is just listing that error message? And saying "you might want to try updating" ...)

nikomatsakis (Feb 06 2020 at 15:44, on Zulip):

I feel like we're overdue for a revisiting of what our stability guarantees can/should be

nikomatsakis (Feb 06 2020 at 15:44, on Zulip):

(Separately)

pnkfelix (Feb 06 2020 at 15:44, on Zulip):

Anyway, I have again achieved my goal of drawing attention to the issue

nikomatsakis (Feb 06 2020 at 15:45, on Zulip):

But I guess I lean towards complete and honest reporting

nikomatsakis (Feb 06 2020 at 15:45, on Zulip):

Not necessarily with an exhaustive list of affected crates (just because that's tedious and misleading, since we can't really know it)

pnkfelix (Feb 06 2020 at 15:45, on Zulip):

so I feel comfortable moving on. Maybe we will want a design meeting regarding stability guarantees going forward.

simulacrum (Feb 06 2020 at 15:45, on Zulip):

I think we should be more eager to report yes

simulacrum (Feb 06 2020 at 15:45, on Zulip):

Let's move on.

pnkfelix (Feb 06 2020 at 15:46, on Zulip):

nominated: "ICE field: higher-rank trait bound (HRTB) for<'a> ... hits OutputTypeParameterMismatch in librustc/traits/codegen" #62529

pnkfelix (Feb 06 2020 at 15:46, on Zulip):

I nominated this this morning

pnkfelix (Feb 06 2020 at 15:46, on Zulip):

because it collects a large set of bugs, and I added another to the set this morning

pnkfelix (Feb 06 2020 at 15:46, on Zulip):

so I wanted to ask: "even though these are all P-medium, they are piling up."

pnkfelix (Feb 06 2020 at 15:46, on Zulip):

Does this imply that we should prioritize lazy-norm for this year?

nikomatsakis (Feb 06 2020 at 15:47, on Zulip):

I thnk we should for various reasons (and, indeed, sort of are?)

pnkfelix (Feb 06 2020 at 15:47, on Zulip):

@nikomatsakis and I have had conversations of this on and off

nikomatsakis (Feb 06 2020 at 15:47, on Zulip):

Or at least we should prioritize resolving this problem

nikomatsakis (Feb 06 2020 at 15:47, on Zulip):

One challenge is that I am still struggling to dedicate time to technical work

nikomatsakis (Feb 06 2020 at 15:47, on Zulip):

Luckily others are routing around me

pnkfelix (Feb 06 2020 at 15:47, on Zulip):

right, I honestly couldn't remember if this fell into the same bucket we discussed.

nikomatsakis (Feb 06 2020 at 15:47, on Zulip):

But I really want to be "in the fray" :)

pnkfelix (Feb 06 2020 at 15:48, on Zulip):

maybe this is just a topic for niko and I to discuss 1:1

pnkfelix (Feb 06 2020 at 15:48, on Zulip):

(and potentially pull in T-compiler members who are interested in assisting in the effort.)

pnkfelix (Feb 06 2020 at 15:49, on Zulip):

anyway okay I guess I can't ask for more than that

pnkfelix (Feb 06 2020 at 15:50, on Zulip):

nominated: "[spurious] thread 'rustc' panicked at 'slice index starts at 24722962 but ends at 13279232', src/libcore/slice/mod.rs:2680:5" #68132

pnkfelix (Feb 06 2020 at 15:50, on Zulip):

this is a bug that I left nominated because I didn't know how to prioritize it

pnkfelix (Feb 06 2020 at 15:50, on Zulip):

its spurious, its perhaps non-actionable.

mw (Feb 06 2020 at 15:50, on Zulip):

I don't see any way to reproduce it

mw (Feb 06 2020 at 15:51, on Zulip):

as long as it doesn't show up with our regular backends, this is low priority, I'd say

pnkfelix (Feb 06 2020 at 15:52, on Zulip):

okay. I'll mark P-low with intent to close

pnkfelix (Feb 06 2020 at 15:52, on Zulip):

(close as non-actionable)

pnkfelix (Feb 06 2020 at 15:52, on Zulip):

do we know if adding #[track_caller} to the various slice methods would improve the panic feedback in cases like this? If so, is that worth doing, or is it too costly?

pnkfelix (Feb 06 2020 at 15:53, on Zulip):

final nomination: "Worsened debug build codegen in beta" #68855

pnkfelix (Feb 06 2020 at 15:54, on Zulip):

I just wanted to draw attention to this bug. I don't think there's anything specific to discuss yet, besides "someone noticed our codegen is worse in beta. It would be great if we could allocate resources to investigate that."

pnkfelix (Feb 06 2020 at 15:55, on Zulip):

there's a slightly higher priority thing

nikomatsakis (Feb 06 2020 at 15:55, on Zulip):

Hmm

pnkfelix (Feb 06 2020 at 15:55, on Zulip):

@Wesley Wiser pointed out to me that there is a stable nomination that I overlooked

pnkfelix (Feb 06 2020 at 15:55, on Zulip):

because I had wrongly assumeed that the stable-noms were always a subset of beta-nom

pnkfelix (Feb 06 2020 at 15:55, on Zulip):

stable-nom: "Resolve long compile times when evaluating always valid constants" #67667

nikomatsakis (Feb 06 2020 at 15:56, on Zulip):

possibly related to the other change :P

pnkfelix (Feb 06 2020 at 15:57, on Zulip):

this apparently is indeed resolving a stable-to-stable regression; the associated issue's labels are (supposedly) out of date.

pnkfelix (Feb 06 2020 at 15:57, on Zulip):

possibly related to the other change :P

beg pardon?

nikomatsakis (Feb 06 2020 at 15:57, on Zulip):

I'm sure it's not

simulacrum (Feb 06 2020 at 15:57, on Zulip):

I have not confirmed the out of date problem to be clear

nikomatsakis (Feb 06 2020 at 15:57, on Zulip):

I was just noting that this touched constants

pnkfelix (Feb 06 2020 at 15:58, on Zulip):

Looks very safe to me, I think

nikomatsakis (Feb 06 2020 at 15:58, on Zulip):

Anyway, yes, :back: from me

pnkfelix (Feb 06 2020 at 15:58, on Zulip):

stable-accepted then

pnkfelix (Feb 06 2020 at 15:58, on Zulip):

okay

pnkfelix (Feb 06 2020 at 15:58, on Zulip):

WG checkins!

pnkfelix (Feb 06 2020 at 15:59, on Zulip):

@matklad for @WG-rls2.0 : ?

matklad (Feb 06 2020 at 15:59, on Zulip):

Sure!

matklad (Feb 06 2020 at 15:59, on Zulip):

Nothing too big happened recently, we are just steadily improving things that we have

matklad (Feb 06 2020 at 16:00, on Zulip):

Like adapting the recent improvements in Chalk (which reduced crashes a lot) or moving cargo check handling into the server (which means errors in any editor, not just VS Code)

nikomatsakis (Feb 06 2020 at 16:00, on Zulip):

I think the biggest "update" might be that

pnkfelix (Feb 06 2020 at 16:00, on Zulip):

okay. and of course we have that design meeting tomorrow.

nikomatsakis (Feb 06 2020 at 16:00, on Zulip):

@matklad and I have been slowly iterating on an RFC

nikomatsakis (Feb 06 2020 at 16:00, on Zulip):

to make the plan to merge RLS/rust-analyzer "official"

nikomatsakis (Feb 06 2020 at 16:01, on Zulip):

which we probably need to just finish up already

matklad (Feb 06 2020 at 16:01, on Zulip):

We also slowly working on production readiness: we now have binary releases, and are palning to publish extension to the VS Code marketplace "soon".

pnkfelix (Feb 06 2020 at 16:01, on Zulip):

Wow wow sounds great.

nikomatsakis (Feb 06 2020 at 16:01, on Zulip):

we were also discussing (just recently, when @pnkfelix and I were in Berlin) how important it would be to use save-analysis at all

matklad (Feb 06 2020 at 16:02, on Zulip):

That is, we work on making it more "just plug & play" from both directions: in practice, and via official RFC plan

nikomatsakis (Feb 06 2020 at 16:02, on Zulip):

i.e., if we just don't yet support find all usages, maybe we don't need it, which sidesteps some complexity and controversy, at the cost of a feature regerssion

nikomatsakis (Feb 06 2020 at 16:02, on Zulip):

(something to be discussed separately, but which seems worth surfacing here)

pnkfelix (Feb 06 2020 at 16:02, on Zulip):

so yeah, everyone, if you're interested in that discussion

pnkfelix (Feb 06 2020 at 16:02, on Zulip):

go find them in the #t-compiler/wg-rls-2.0 stream

pnkfelix (Feb 06 2020 at 16:02, on Zulip):

next checkin

pnkfelix (Feb 06 2020 at 16:02, on Zulip):

@mw on WG-self-profile

pnkfelix (Feb 06 2020 at 16:03, on Zulip):

(if we haven't lost @mw due to going over time ... :sad: )

mw (Feb 06 2020 at 16:03, on Zulip):

yup, here goes:

mw (Feb 06 2020 at 16:03, on Zulip):

There's been quite a bit of progress!

mw (Feb 06 2020 at 16:03, on Zulip):
mw (Feb 06 2020 at 16:03, on Zulip):
mw (Feb 06 2020 at 16:03, on Zulip):
mw (Feb 06 2020 at 16:03, on Zulip):
mw (Feb 06 2020 at 16:03, on Zulip):

Recently activity of the working group has slowed down a bit since both @Wesley Wiser and I have been working on other things. We'll see where we'll go from here. Publishing blog posts about the awesome tooling already implemented seems like a good idea.

Wesley Wiser (Feb 06 2020 at 16:04, on Zulip):

It's in the early stages but I've started writing a post for Inside-Rust

pnkfelix (Feb 06 2020 at 16:04, on Zulip):

thank you for saying what crox is

pnkfelix (Feb 06 2020 at 16:04, on Zulip):

I had seen references to that but hadn 't gotten context

Wesley Wiser (Feb 06 2020 at 16:05, on Zulip):

ChRomium OXide => visualizing the self-profilng data with Chromium's profiler

mw (Feb 06 2020 at 16:05, on Zulip):

I'm happy to report that quite a few people gave feedback on how useful self-profiling was for them

nikomatsakis (Feb 06 2020 at 16:05, on Zulip):

This is super awesome

nikomatsakis (Feb 06 2020 at 16:06, on Zulip):

I am going to ask my usual question

nikomatsakis (Feb 06 2020 at 16:06, on Zulip):

Is there docs I can point people at? :)

nikomatsakis (Feb 06 2020 at 16:06, on Zulip):

(In particular, maybe in the unstable rustc guide?:)

mw (Feb 06 2020 at 16:06, on Zulip):

I think that's what the blog posts should be?

nikomatsakis (Feb 06 2020 at 16:06, on Zulip):

But seriously this really is very cool, I love the integration into perf

Wesley Wiser (Feb 06 2020 at 16:06, on Zulip):

The rustc-guide will at least tell you where to go :) https://rust-lang.github.io/rustc-guide/profiling.html

nikomatsakis (Feb 06 2020 at 16:06, on Zulip):

OK, I was thinking of the rustc book

nikomatsakis (Feb 06 2020 at 16:07, on Zulip):

like, the user's guide

nikomatsakis (Feb 06 2020 at 16:07, on Zulip):

but having the info in rustc-guide is a good start

nikomatsakis (Feb 06 2020 at 16:07, on Zulip):

maybe I'll open a PR copying the links...

pnkfelix (Feb 06 2020 at 16:07, on Zulip):

Can always file an issue in .... some repo ...

pnkfelix (Feb 06 2020 at 16:07, on Zulip):

with that TODO item

davidtwco (Feb 06 2020 at 16:07, on Zulip):

davidtwco are you around? Did you want to say anything about the status of your polymorphization work, or design questions there?

(sorry, missed the start of the meeting, the ongoing conversation you linked to summarizes the main decisions that I was unsure about)

pnkfelix (Feb 06 2020 at 16:07, on Zulip):

okay this is great stuff

nikomatsakis (Feb 06 2020 at 16:07, on Zulip):

(side note, we don't describe unstable things in the "rustc book" anyway, though I'm unconvinced that's a good policy, so really it'd be the unstable guide)

nikomatsakis (Feb 06 2020 at 16:07, on Zulip):

I'm happy to report that quite a few people gave feedback on how useful self-profiling was for them

mostly I want to keep directing people to this, I think there's a ton of value here

pnkfelix (Feb 06 2020 at 16:08, on Zulip):

I'm going to tie the meeting itself off now (but people are free to keep discussing obviously).

Wesley Wiser (Feb 06 2020 at 16:08, on Zulip):

If you cc me on the issue, I'll make sure we include something there. I didn't know the unstable rustc book was a thing

pnkfelix (Feb 06 2020 at 16:08, on Zulip):

Thanks to everyone in @T-compiler/meeting for attending!

nikomatsakis (Feb 06 2020 at 16:09, on Zulip):

If you cc me on the issue, I'll make sure we include something there. I didn't know the unstable rustc book was a thing

it's published here, and the sources are here -- but I don't know how many people even look at it. Mostly I think that having a guide that explains how to use some of rustc's more esoteric features seems good though

nikomatsakis (Feb 06 2020 at 16:11, on Zulip):

personally I think we should document unstable flags in a special section of the rustc book

nikomatsakis (Feb 06 2020 at 16:11, on Zulip):

especially "semi-stable" ones like this

nikomatsakis (Feb 06 2020 at 16:11, on Zulip):

but in any case I think @mw is right that a blog post is a better starting point and will get more attention :P

nikomatsakis (Feb 06 2020 at 16:11, on Zulip):

I'd just like to have something in there that's like "you can profile your code! check out the README here to learn more"

Wesley Wiser (Feb 06 2020 at 16:13, on Zulip):

For the blog, my goal is to show step-by-step how to use all of the tools in measureme to diagnose/inspect where rustc is spending it's compile time. It should be easy to convert that into a tutorial in the crate docs later.

nikomatsakis (Feb 06 2020 at 16:19, on Zulip):

Yes, beautiful

nikomatsakis (Feb 06 2020 at 16:32, on Zulip):

Anyway, I guess I still believe that a more minimal output will be better, and that the danger of too much info is real, but as I wrote, i'm open to being told I am wrong. Maybe we should do some sort of poll on internals? twitter poll? I don't know

I created an internals thread that includes a poll about the async-await error message. cc @simulacrum @Esteban Küber @Aaron Hill and maybe @WG-diagnostics too? :)

Last update: Jun 07 2020 at 10:40UTC