Stream: t-compiler

Topic: planning meeting 2019.01.03


nikomatsakis (Jan 03 2020 at 14:57, on Zulip):

Hey @T-compiler/meeting -- planning meeting in a few minutes. Last change to open any meeting proposals for the next few weeks. =)

nikomatsakis (Jan 03 2020 at 15:03, on Zulip):

Announcements

nikomatsakis (Jan 03 2020 at 15:03, on Zulip):

Hey @T-compiler/meeting, planning meeting starting now

nikomatsakis (Jan 03 2020 at 15:04, on Zulip):

I don't have any announcements since yesterday I don't thnk :)

nikomatsakis (Jan 03 2020 at 15:04, on Zulip):

I guess we might as well get started?

nikomatsakis (Jan 03 2020 at 15:05, on Zulip):

I'm not sure how many proposals we'll have this round anyway... mostly old ones I guess...

nikomatsakis (Jan 03 2020 at 15:05, on Zulip):

Perhaps first thing to discuss is what days we are scheduling...

nikomatsakis (Jan 03 2020 at 15:05, on Zulip):

January 10, 17, and 24 according the calendar.

nikomatsakis (Jan 03 2020 at 15:06, on Zulip):

Er, wait

nikomatsakis (Jan 03 2020 at 15:06, on Zulip):

Well ok the calendar has the next planning meeting on Jan 17 :)

nikomatsakis (Jan 03 2020 at 15:06, on Zulip):

It's also worth noting that Jan 31 is the Mozilla All Hands, and @pnkfelix, @mw and I will be in Berlin and probably not able to do a planning or design meeting

pnkfelix (Jan 03 2020 at 15:06, on Zulip):

yeah I'm trying to understand that too (the planning meeting on the 17th)

nikomatsakis (Jan 03 2020 at 15:06, on Zulip):

Well ok the calendar has the next planning meeting on Jan 17 :)

This is because it was keeping the original "every 4 week" schedule, and I moved one meeting

nikomatsakis (Jan 03 2020 at 15:07, on Zulip):

but it didn't shift the following meetings I guess

nikomatsakis (Jan 03 2020 at 15:07, on Zulip):

I could probalby adjust it

pnkfelix (Jan 03 2020 at 15:07, on Zulip):

well

pnkfelix (Jan 03 2020 at 15:07, on Zulip):

either we'll fill up the next three meetngs

pnkfelix (Jan 03 2020 at 15:08, on Zulip):

or we'll have just ... one ...

nikomatsakis (Jan 03 2020 at 15:08, on Zulip):

but I could also seem some logic in sort of skipping the meeting today/next week and trying again on the 17 :)

pnkfelix (Jan 03 2020 at 15:08, on Zulip):

maybe lets skim the proposals to inform that decision

pnkfelix (Jan 03 2020 at 15:08, on Zulip):

proposals

nikomatsakis (Jan 03 2020 at 15:08, on Zulip):

ps did we never create minutes from the IDE meeting?

nikomatsakis (Jan 03 2020 at 15:08, on Zulip):

I forget @pnkfelix if you or I was going to do that ...

pnkfelix (Jan 03 2020 at 15:09, on Zulip):

I think I agreed to do it (I definitely remember starting to do so)

nikomatsakis (Jan 03 2020 at 15:09, on Zulip):

anyway no big thing

nikomatsakis (Jan 03 2020 at 15:09, on Zulip):
nikomatsakis (Jan 03 2020 at 15:09, on Zulip):
nikomatsakis (Jan 03 2020 at 15:09, on Zulip):
nikomatsakis (Jan 03 2020 at 15:09, on Zulip):
nikomatsakis (Jan 03 2020 at 15:10, on Zulip):
nikomatsakis (Jan 03 2020 at 15:10, on Zulip):
nikomatsakis (Jan 03 2020 at 15:10, on Zulip):

I thnk here we were waiting for data?

nikomatsakis (Jan 03 2020 at 15:10, on Zulip):

Maybe @mw was going to gather it from firefox or servo or something?

centril (Jan 03 2020 at 15:10, on Zulip):

Rust has had a long-standing problem where LLVM optimizes empty loops into UB. This can very easily create real bugs for folks. We've got a pending PR (#59546) that fixes this by inserting llvm.sideeffect instructions, but until recently it was blocked on getting some lolbench measurements done. These measurements were recently completed (thanks @mati865!). They suggest the impact is "generally" small but non-zero (I put them in a world readable spreadsheet here, feel free to copy and play with it). We need to make a decision whether this is good enough! I'm going to cc the @rust-lang/lang team since I think lang team input would be useful here.

centril (Jan 03 2020 at 15:10, on Zulip):

data was gathered?

mw (Jan 03 2020 at 15:11, on Zulip):

Maybe mw was going to gather it from firefox or servo or something?

I'll put that on my todo list for monday

pnkfelix (Jan 03 2020 at 15:11, on Zulip):

since the last time this was discussed?

nikomatsakis (Jan 03 2020 at 15:11, on Zulip):

I think we said that we would land the PR and gather data from a larger application

nikomatsakis (Jan 03 2020 at 15:11, on Zulip):

see comment here

pnkfelix (Jan 03 2020 at 15:11, on Zulip):

and it is merged, right?

mw (Jan 03 2020 at 15:11, on Zulip):

(it has gotten slightly more complicated because of changes in FF CI)

pnkfelix (Jan 03 2020 at 15:11, on Zulip):

(under a Z flag)

nikomatsakis (Jan 03 2020 at 15:11, on Zulip):

I see I also said something about measuring "some async application" :P

mw (Jan 03 2020 at 15:11, on Zulip):

Yes, I think so

centril (Jan 03 2020 at 15:11, on Zulip):

I would like to see a deadline for getting rid of this egregious soundness hole, and some deadline for data-gathering also

nikomatsakis (Jan 03 2020 at 15:12, on Zulip):

I'm not sure what I meant by that but .. I think there are some pretty standard benchmarks we could run, e.g. hyper serving as a proxy

nikomatsakis (Jan 03 2020 at 15:12, on Zulip):

I'll ping @Sean McArthur about it :)

pnkfelix (Jan 03 2020 at 15:12, on Zulip):

you know: We could be a little more aggressive here

centril (Jan 03 2020 at 15:12, on Zulip):

(I think we need to set expectations that there will be perf regressions, and that we need to live with those...)

pnkfelix (Jan 03 2020 at 15:12, on Zulip):

by flipping the Z flag meaning

pnkfelix (Jan 03 2020 at 15:12, on Zulip):

I.e. we turn it on by default, and provide an "easy" way to turn it off

pnkfelix (Jan 03 2020 at 15:12, on Zulip):

(perhaps even under a -C flag...)

centril (Jan 03 2020 at 15:13, on Zulip):

(perhaps even under a -C flag...)

Soundness should not be subject to -C flags

pnkfelix (Jan 03 2020 at 15:13, on Zulip):

so that end-users can determine for themselves if it is causing a performance regression for them

nikomatsakis (Jan 03 2020 at 15:13, on Zulip):

I think we should set a deadline for gathering some more data

centril (Jan 03 2020 at 15:13, on Zulip):

(e.g. -C no-alias is also something that I think we should never have)

nikomatsakis (Jan 03 2020 at 15:14, on Zulip):

I wouldn't be in favor of a permanent -C flag around this

pnkfelix (Jan 03 2020 at 15:14, on Zulip):

I'm happy to retract my suggestion (of making it a -C flag)

pnkfelix (Jan 03 2020 at 15:14, on Zulip):

just trying to make it easy for people off of nightly to do the aforementioned experiment

centril (Jan 03 2020 at 15:14, on Zulip):

What would a suitable deadline be? 1 month?

nikomatsakis (Jan 03 2020 at 15:14, on Zulip):

(But I think flipping the default and keeping the flag for a bit, so people can measure the impact, isn't a bad idea)

nikomatsakis (Jan 03 2020 at 15:15, on Zulip):

What would a suitable deadline be? 1 month?

I was going to say something like that, yeah, sort of "by next planning meeting", except we don't know when that'll be :P

mw (Jan 03 2020 at 15:15, on Zulip):

as long as we revert that change before it hits beta

pnkfelix (Jan 03 2020 at 15:15, on Zulip):

What would a suitable deadline be? 1 month?

somewhere between 1 month and a release cycle sounds plausible to me.

nikomatsakis (Jan 03 2020 at 15:15, on Zulip):

I think it should be something like this

centril (Jan 03 2020 at 15:15, on Zulip):

At least on nightly I think we should feel comfortable trying out sound-by-default and flag to opt out

nikomatsakis (Jan 03 2020 at 15:15, on Zulip):

We intend to land the change (flip the default)

nikomatsakis (Jan 03 2020 at 15:16, on Zulip):

But we have some time for people to convince us it's going to have a very high impact :)

nikomatsakis (Jan 03 2020 at 15:17, on Zulip):

ok, moving on..?

nikomatsakis (Jan 03 2020 at 15:18, on Zulip):

let me leave a comment

nikomatsakis (Jan 03 2020 at 15:19, on Zulip):

I think @pnkfelix this is perhaps a bit "vague", I feel like I'm not quite sure what scope we had in mind anymore

pnkfelix (Jan 03 2020 at 15:20, on Zulip):

i know

pnkfelix (Jan 03 2020 at 15:20, on Zulip):

when it came up earlier

centril (Jan 03 2020 at 15:20, on Zulip):

We intend to land the change (flip the default)

(Ultimately, at the end of the day, I think we'll need to come to terms with that this might have even 10% runtime perf effects and that due to our global commitment to soundness, we have no choice but to accept that)

pnkfelix (Jan 03 2020 at 15:20, on Zulip):

I was wondering if such formalism makes sense (the "Constitutional Convention")

pnkfelix (Jan 03 2020 at 15:20, on Zulip):

versus continuing to just go "organically"

nikomatsakis (Jan 03 2020 at 15:21, on Zulip):

I'm inclined to lean towards organic at this time

pnkfelix (Jan 03 2020 at 15:21, on Zulip):

okay lets just close that meeting proposal themn

nikomatsakis (Jan 03 2020 at 15:21, on Zulip):

I think we have some ideas (e.g., following up with working group leads, etc) that we haven't done

centril (Jan 03 2020 at 15:21, on Zulip):

Agree with @nikomatsakis -- overall it seems to work well

nikomatsakis (Jan 03 2020 at 15:21, on Zulip):

and I'd rather try to organize around those

centril (Jan 03 2020 at 15:22, on Zulip):

or rather semi-organic with some light steering

pnkfelix (Jan 03 2020 at 15:22, on Zulip):

I'll leave a comment and close the issue

nikomatsakis (Jan 03 2020 at 15:22, on Zulip):

I do still think there's a discussion to be had here, but I'm not sure if we're at a good point for compiler-team meeting yet.

nikomatsakis (Jan 03 2020 at 15:25, on Zulip):

on this topic, I'm curious @mw what you think. I was thinking it'd be good to maybe try to have some setup where people can bring their compile time problems and we might try to help them diagnose. It seems like a win-win, in that we help people but also get a better idea what is causing people's compilation problems. With -Zself-profile, it may also be fairly light-weight to get started... but still, where do the "people" come from?

So I started to think it'd be better for companies like Ferrous / Lyken to provide these services. I still sort of think that. So i'm kind of inclined to close this as I don't quite know what we would talk about yet.

mw (Jan 03 2020 at 15:26, on Zulip):

I think that's a good idea generally

mw (Jan 03 2020 at 15:26, on Zulip):

but I personally probably won't have much time

mw (Jan 03 2020 at 15:27, on Zulip):

i.e. I won't be able to allocate a lot of time towards that

nikomatsakis (Jan 03 2020 at 15:27, on Zulip):

yeah

mw (Jan 03 2020 at 15:27, on Zulip):

unless you all convince the FF org that it is good for Firefox

pnkfelix (Jan 03 2020 at 15:27, on Zulip):

what's the main drawback with the Ferrous/Lyken approach?

mw (Jan 03 2020 at 15:27, on Zulip):

:)

nikomatsakis (Jan 03 2020 at 15:27, on Zulip):

I mean the "minimal version" might be to have e.g. a Zulip stream

nikomatsakis (Jan 03 2020 at 15:27, on Zulip):

where people can pop in and request

nikomatsakis (Jan 03 2020 at 15:28, on Zulip):

anyway, I... think I might just close it for now

pnkfelix (Jan 03 2020 at 15:28, on Zulip):

the only drawback I can imagine is that a customer might not think they have enough "pull" compared to engaging with ... Mozilla directly? But I don't think that logic really holds up.

nikomatsakis (Jan 03 2020 at 15:28, on Zulip):

I don't see mozilla doing this or this being good for FF org in particular

centril (Jan 03 2020 at 15:28, on Zulip):

fwiw, I think we should be interested in diagnosing the problems not least because it makes ./x.py go faster, which :heart:

mw (Jan 03 2020 at 15:29, on Zulip):

I think there's generally lots of potential in the tooling around this

nikomatsakis (Jan 03 2020 at 15:29, on Zulip):

well, I guess we could have a meeting about it, to talk about what we can do to help folks. if nothing else, advertisting or talking about the companies that might do it would be interesting

nikomatsakis (Jan 03 2020 at 15:29, on Zulip):

and/or maybe something like creating a zulip stream

nikomatsakis (Jan 03 2020 at 15:29, on Zulip):

I've not really talked much to Ferrous about this specifically

nikomatsakis (Jan 03 2020 at 15:29, on Zulip):

but I'm not sure a meeting is what's really needed as next steps I guess

mw (Jan 03 2020 at 15:30, on Zulip):

agreed

nikomatsakis (Jan 03 2020 at 15:30, on Zulip):

what is up with this, @pnkfelix ?

nikomatsakis (Jan 03 2020 at 15:31, on Zulip):

I feel like there was some discussion between you and @Florian Gilcher ...?

pnkfelix (Jan 03 2020 at 15:31, on Zulip):

hmm, I don't know where we are on thart

nikomatsakis (Jan 03 2020 at 15:31, on Zulip):

and maybe we felt we don't need a meeting? (that's sort of what I remember)

pnkfelix (Jan 03 2020 at 15:31, on Zulip):

yeah, that is probably true

pnkfelix (Jan 03 2020 at 15:32, on Zulip):

we need to do the work, but the design meeting isn't the right place to assign that work

pnkfelix (Jan 03 2020 at 15:32, on Zulip):

and we'll need to send out notice of what the policies are

pnkfelix (Jan 03 2020 at 15:32, on Zulip):

but the question is whether developing the licensing policy belongs in this meeting

nikomatsakis (Jan 03 2020 at 15:32, on Zulip):

ok, maybe we should close it, or change the issue to a #t-compiler/wg-meta issue

pnkfelix (Jan 03 2020 at 15:33, on Zulip):

okay

nikomatsakis (Jan 03 2020 at 15:33, on Zulip):

I feel like most people just kind of didn't care

nikomatsakis (Jan 03 2020 at 15:33, on Zulip):

I kind of don't care

nikomatsakis (Jan 03 2020 at 15:33, on Zulip):

well I mean I care that we have a policy and I'd sort of like to know what it is :)

nikomatsakis (Jan 03 2020 at 15:33, on Zulip):

but it seems like maybe we need to develop it and see if it seems tricky enough to be worth discussing as a group first...

centril (Jan 03 2020 at 15:33, on Zulip):

(If I had my druthers we'd be licensing under GPL3.0+, but given that we have a clear set of licenses to pick, I'm happy to just conform...)

nikomatsakis (Jan 03 2020 at 15:34, on Zulip):

(that's kind of what I thought the meeting would be when I opened it, so I thought we were basically arleady done with developing it?)

pnkfelix (Jan 03 2020 at 15:34, on Zulip):

the lack of caring is what i think has led to some violations that some people got worked up about

nikomatsakis (Jan 03 2020 at 15:34, on Zulip):

indeed

centril (Jan 03 2020 at 15:34, on Zulip):

I don't think we can force people to care

pnkfelix (Jan 03 2020 at 15:34, on Zulip):

we cannot force everyone to care

centril (Jan 03 2020 at 15:34, on Zulip):

(Other than via tooling and reviews)

pnkfelix (Jan 03 2020 at 15:34, on Zulip):

but we may need to force people with r+ privs to care

nikomatsakis (Jan 03 2020 at 15:35, on Zulip):

I think we can educate and answer questions

nikomatsakis (Jan 03 2020 at 15:35, on Zulip):

I guess when I say I don't care what I mean is

nikomatsakis (Jan 03 2020 at 15:35, on Zulip):

I just want to be told what to do

pnkfelix (Jan 03 2020 at 15:35, on Zulip):

okay yes

pnkfelix (Jan 03 2020 at 15:35, on Zulip):

that's an important distinction

nikomatsakis (Jan 03 2020 at 15:36, on Zulip):

so I think a meeting with that goal would be good, but it sounds like we're not quite ready for that

nikomatsakis (Jan 03 2020 at 15:36, on Zulip):

though I'm not sure how far we are fr it

nikomatsakis (Jan 03 2020 at 15:36, on Zulip):

(I would also expect that we may uncover some practical challenges that would require minor revisions)

centril (Jan 03 2020 at 15:36, on Zulip):

would the meeting just communicate what to do?

centril (Jan 03 2020 at 15:36, on Zulip):

or should the meeting design what to do?

pnkfelix (Jan 03 2020 at 15:37, on Zulip):

I think a number of people have argued that an email is better than a meeting for the step of dictating what to do

centril (Jan 03 2020 at 15:37, on Zulip):

I feel an email is more appropriate for the former, a meeting for the latter

centril (Jan 03 2020 at 15:37, on Zulip):

@pnkfelix you have quick fingers =P

nikomatsakis (Jan 03 2020 at 15:37, on Zulip):

well, I was imagining that there would be questions

pnkfelix (Jan 03 2020 at 15:37, on Zulip):

and I think the meeting to design what to do is probably better done with a smaller group of "expderts', what ever that means

nikomatsakis (Jan 03 2020 at 15:37, on Zulip):

I also don't think people will read the e-mail, but maybe I'm projecting :)

pnkfelix (Jan 03 2020 at 15:37, on Zulip):

I also don't think people will read the e-mail, but maybe I'm projecting :)

this was my reaction as well.

nikomatsakis (Jan 03 2020 at 15:37, on Zulip):

but I'm game to try and e-mail first

pnkfelix (Jan 03 2020 at 15:37, on Zulip):

we probably need to broadcast on multiple channels, to be honest

nikomatsakis (Jan 03 2020 at 15:38, on Zulip):

at least I think we need something that can be e-mailed first

centril (Jan 03 2020 at 15:38, on Zulip):

@nikomatsakis not everyone has as many unread emails as you ;)

pnkfelix (Jan 03 2020 at 15:38, on Zulip):

but maybe email + announcement at thursday meeting would suffice.

nikomatsakis (Jan 03 2020 at 15:38, on Zulip):

ok. Shoud we close meeting proposa for now? (move to wg-meta as a thing we need to get done)

nikomatsakis (Jan 03 2020 at 15:38, on Zulip):

sonds like yes

nikomatsakis (Jan 03 2020 at 15:38, on Zulip):

I want to close out some of these long-standing open ones

pnkfelix (Jan 03 2020 at 15:38, on Zulip):

yeah moving to wg-meta sounds fine

pnkfelix (Jan 03 2020 at 15:38, on Zulip):

/me needs to join wg-meta probably.

nikomatsakis (Jan 03 2020 at 15:39, on Zulip):

we've been kind of dormant for a month or two but it seems like we're getting more and more stuff to do..

nikomatsakis (Jan 03 2020 at 15:39, on Zulip):

maybe we can talk a bit about

design of the chalk-ty library compiler-team#234

nikomatsakis (Jan 03 2020 at 15:39, on Zulip):

I'm curious about best way to give/get feedback around "library-ification" designs

mw (Jan 03 2020 at 15:40, on Zulip):

I was thinking that there are probably certain patterns that emerge here

nikomatsakis (Jan 03 2020 at 15:40, on Zulip):

the design here isn't fully written out yet, but I think it's becoming fairly clear -- so I'm trying to decide what makes the most sense -- I could see trying to finish up docs and bringing it to a meeting to talk about, not sure how much code to write beforehand :)

mw (Jan 03 2020 at 15:40, on Zulip):

i.e. how to set up code

centril (Jan 03 2020 at 15:40, on Zulip):

(TypeFamily -- not loving that name... it feels confusable with https://wiki.haskell.org/GHC/Type_families)

nikomatsakis (Jan 03 2020 at 15:40, on Zulip):

(I don't like the name either)

nikomatsakis (Jan 03 2020 at 15:41, on Zulip):

i.e. how to set up code

do you mean like "poly vs monorepo"?

nikomatsakis (Jan 03 2020 at 15:41, on Zulip):

or crate structure?

nikomatsakis (Jan 03 2020 at 15:41, on Zulip):

or both? :)

mw (Jan 03 2020 at 15:41, on Zulip):

crate structure, splitting things into traits, having something like traits that get further and further refined

centril (Jan 03 2020 at 15:42, on Zulip):

(From the discussions thus far re. mono vs. polyrepo I think we've been going with the former)

mw (Jan 03 2020 at 15:42, on Zulip):

things like that

pnkfelix (Jan 03 2020 at 15:42, on Zulip):

so @nikomatsakis , before we dive further into details of the chalk-ty topic itself

pnkfelix (Jan 03 2020 at 15:42, on Zulip):

since it is the only meeting proposal left

pnkfelix (Jan 03 2020 at 15:42, on Zulip):

(right?)

pnkfelix (Jan 03 2020 at 15:43, on Zulip):

and we were at some point discussing the matter of the "next" planning meeting being scheduled for Jan 17th

pnkfelix (Jan 03 2020 at 15:43, on Zulip):

would it be realistic to allocate Jan 10th for the chalk-ty meeting?

nikomatsakis (Jan 03 2020 at 15:43, on Zulip):

this one maybe

pnkfelix (Jan 03 2020 at 15:43, on Zulip):

(do you think you'd have everything put together in time?)

nikomatsakis (Jan 03 2020 at 15:43, on Zulip):

would it be realistic to allocate Jan 10th for the chalk-ty meeting?

depends I guess

nikomatsakis (Jan 03 2020 at 15:43, on Zulip):

what "everything" is

pnkfelix (Jan 03 2020 at 15:43, on Zulip):

Oh I guess there was compiler-team#90 too, true

nikomatsakis (Jan 03 2020 at 15:43, on Zulip):

I think I could do a bit more writing up, but it'd be pretty "early"

nikomatsakis (Jan 03 2020 at 15:43, on Zulip):

but that's maybe ok

pnkfelix (Jan 03 2020 at 15:44, on Zulip):

okay, well

pnkfelix (Jan 03 2020 at 15:44, on Zulip):

if its too soon

pnkfelix (Jan 03 2020 at 15:44, on Zulip):

then maybe we should indeed just cancel next weeks design meeting

nikomatsakis (Jan 03 2020 at 15:44, on Zulip):

yeah, that seems right

pnkfelix (Jan 03 2020 at 15:44, on Zulip):

and let Jan 17th stand as a new planning meeting

nikomatsakis (Jan 03 2020 at 15:44, on Zulip):

seems fine to me

mw (Jan 03 2020 at 15:44, on Zulip):

crate structure, splitting things into traits, having something like traits that get further and further refined

(salsa has some good lessons there too probably)

nikomatsakis (Jan 03 2020 at 15:46, on Zulip):

Yeah, I need to sync up some with @matklad on that topic too, since we were debating in rust-analyzer a lot about this.

nikomatsakis (Jan 03 2020 at 15:46, on Zulip):

(Separately, I have to say I am pretty loathe to try and move chalk into the rust-lang/rust repo, although I recognize some of the "monorepo" advantages too.)

centril (Jan 03 2020 at 15:46, on Zulip):

btw, if we have a sec over, I'd like to flag https://github.com/rust-lang/rust/pull/67833 as in possible need of some team discussion

nikomatsakis (Jan 03 2020 at 15:47, on Zulip):

Fix some of the rustfmt fallout in Miri #67833

centril (Jan 03 2020 at 15:47, on Zulip):

(cc @RalfJ)

pnkfelix (Jan 03 2020 at 15:48, on Zulip):

out of curiousity regarding the match arm formatting of PAT => macro!(<newline-yuck>

pnkfelix (Jan 03 2020 at 15:48, on Zulip):

does that get "resolved" if you add { } to the RHS of the ARM ?

nikomatsakis (Jan 03 2020 at 15:48, on Zulip):

I think I agree with you @centril that I'd prefer to avoid #[rustfmt::skip].

nikomatsakis (Jan 03 2020 at 15:49, on Zulip):

does that get "resolved" if you add { } to the RHS of the ARM ?

probably not, I thnk rustfmt tends to normalize those away, but I'm not sure about this particular case

pnkfelix (Jan 03 2020 at 15:49, on Zulip):

That's interesting, I didn't know that

centril (Jan 03 2020 at 15:50, on Zulip):

(Though I'm personally open to adding minor tweaks to rustfmt.toml because it's global; for me it's most important that format-on-save "just works" and that we collectively can stop thinking about style)

pnkfelix (Jan 03 2020 at 15:50, on Zulip):

maybe @RalfJ should just write it as write!(f, match self { ... }) . (Only half joking...)

nikomatsakis (Jan 03 2020 at 15:51, on Zulip):

e.g. try formatting this example

nikomatsakis (Jan 03 2020 at 15:52, on Zulip):

(Though I'm personally open to adding minor tweaks to rustfmt.toml because it's global; for me it's most important that format-on-save "just works" and that we collectively can stop thinking about style)

this seems like the key thing to be discussing, right?

pnkfelix (Jan 03 2020 at 15:52, on Zulip):

this case is fixed though

nikomatsakis (Jan 03 2020 at 15:52, on Zulip):

but perhaps not in this meeting exactly -- I guess the question is whether we need to raise this more broadly and where

nikomatsakis (Jan 03 2020 at 15:53, on Zulip):

this case is fixed though

yeah I don't know the precise rules, maybe to do with ;, not sure

centril (Jan 03 2020 at 15:53, on Zulip):

yea; I'm personally happy with the two tweaks we added to the rustfmt.toml

centril (Jan 03 2020 at 15:53, on Zulip):

but we shouldn't grow a lot more

centril (Jan 03 2020 at 15:53, on Zulip):

(there's always lobbying for tweaks to the official standard style ^^)

nikomatsakis (Jan 03 2020 at 15:54, on Zulip):

(side note, I do think our match style can make it hard to separate the patterns from the arm bodies...)

pnkfelix (Jan 03 2020 at 15:55, on Zulip):

this case is fixed though

yeah I don't know the precise rules, maybe to do with ;, not sure

You're right, its because of the ;. Still, seems like it would resolve @RalfJ particular issue here

pnkfelix (Jan 03 2020 at 15:55, on Zulip):

or maybe not

pnkfelix (Jan 03 2020 at 15:56, on Zulip):

/me hasn't looked too carefully at the output @RalfJ desires ...

pnkfelix (Jan 03 2020 at 15:57, on Zulip):

Anyway, is the question about whether we need to be gathering notes about these cases in some central place?

centril (Jan 03 2020 at 15:57, on Zulip):

I probably wasn't a big fan of the official style at first, but now everything else just looks wrong =P

pnkfelix (Jan 03 2020 at 15:58, on Zulip):

the reason that I agree with @RalfJ in this case, is that the write! 's i the rustfmt'd output all appear at different column numbers

pnkfelix (Jan 03 2020 at 15:58, on Zulip):

while in @RalfJ 's version, they all line up in a column

pnkfelix (Jan 03 2020 at 15:59, on Zulip):

maybe there is a tweak we could add for comma-delimited arms that would still preserve that property

centril (Jan 03 2020 at 16:00, on Zulip):

I agree Ralf's is probably somewhat nicer, but still, having uniform style is nicer still

mw (Jan 03 2020 at 16:00, on Zulip):

/me :wave:

pnkfelix (Jan 03 2020 at 16:00, on Zulip):

You're right, its because of the ;. Still, seems like it would resolve RalfJ particular issue here

(when I said this, I had ignored the detail that the return value is of course relevant, since this returns fmt::Result. Its not as trivial as what I posted in that play link.)

pnkfelix (Jan 03 2020 at 16:01, on Zulip):

Okay @T-compiler/meeting , that's an hour. I gotta go and I infer @mw had to go too. and I think @nikomatsakis also said they had a hard out after the hour

centril (Jan 03 2020 at 16:01, on Zulip):

Thanks all

RalfJ (Jan 03 2020 at 17:34, on Zulip):

I agree Ralf's is probably somewhat nicer, but still, having uniform style is nicer still

So unform bad formatting is better than sometimes good formatting? I strongly disagree.

RalfJ (Jan 03 2020 at 17:35, on Zulip):

What rustfmt does to match is generally pretty bad IMO, and it gets worse long matches: those should be formatted uniformly, but rustfmt independently applies its rules on each arm, leading to something entirely non-uniform across the entire match

RalfJ (Jan 03 2020 at 17:36, on Zulip):

also see https://github.com/rust-lang/rustfmt/issues/3973 (rustfmt provides no way to format pattern alternatives in a way that all patterns start on the same column, and will destroy manual formatting if you had achieved that), and https://github.com/rust-lang/rustfmt/issues/3995

RalfJ (Jan 03 2020 at 17:37, on Zulip):

(side note, I do think our match style can make it hard to separate the patterns from the arm bodies...)

Yeah, that's pretty much the worst part about it IMO. Also see https://github.com/rust-lang/rustfmt/issues/3995#issuecomment-570557622

centril (Jan 03 2020 at 17:38, on Zulip):

So unform bad formatting is better than sometimes good formatting? I strongly disagree.

@RalfJ pretty much yeah; although "bad style" is likely quite subjective wrt. formatting

RalfJ (Jan 03 2020 at 17:38, on Zulip):

yeah I appreciate everything about this is subjective :/

RalfJ (Jan 03 2020 at 17:39, on Zulip):

that's why I am latching on to uniformity as main topic, because that seems least controversial

RalfJ (Jan 03 2020 at 17:39, on Zulip):

what rustfmt does with large matches is the opposite of uniform

centril (Jan 03 2020 at 17:39, on Zulip):

@RalfJ I would be more comfortable if whatever tweaks you made were in rustfmt.toml though, unless we're talking rustfmt bugs

centril (Jan 03 2020 at 17:39, on Zulip):

(in which case I think bugs should be fixed upstream and then we can ./x.py fmt)

RalfJ (Jan 03 2020 at 17:41, on Zulip):

sure it'd be better if rustfmt could do something reasonable on matches. I dont have the spare capacity to push for that though, I dont even know the process.
more generally I feel like rustfmt could more often be a bit more respectful of the existing style, and not just tear everything apart. I'd be fine with it not doing a perfect job of formatting matches itself, which is hard, but I get mad when it destroys my carefully formatted matches. (I dont use rustfmt on my own projects, and that's the main reason.)

centril (Jan 03 2020 at 18:43, on Zulip):

Maybe there's an existing flag?

oli (Jan 03 2020 at 20:41, on Zulip):

That flag is called #[rustfmt::skip] :upside_down:

centril (Jan 03 2020 at 20:43, on Zulip):

@oli in rustfmt.toml, not files

Last update: Jan 21 2020 at 09:05UTC