Stream: t-compiler

Topic: weekly meeting 2020-01-16 #54818


pnkfelix (Jan 16 2020 at 14:24, on Zulip):

Hi @T-compiler/meeting ; the triage meeting will be starting in 36 minutes

pnkfelix (Jan 16 2020 at 14:24, on Zulip):

pre-triage took place last night in a parallel topic

pnkfelix (Jan 16 2020 at 14:25, on Zulip):

today we are scheduled to hear from @WG-nll and @WG-parallel-rustc

simulacrum (Jan 16 2020 at 14:25, on Zulip):

I can give the update from parallel most likely (though current status is a bit unclear there)

pnkfelix (Jan 16 2020 at 14:28, on Zulip):

also i have made a hackmd for the agenda today

pnkfelix (Jan 16 2020 at 14:31, on Zulip):

I suspect WG-nll doesn't have anything to report but let me ping @Matthew Jasper just in case I'm wrong. (I do know there is at least one open bug (#68090) that I looked at during pre-triage last night,

simulacrum (Jan 16 2020 at 14:38, on Zulip):

I have filled in a blob of text for parallel in the agenda, feel free to copy/paste if I'm not around

pnkfelix (Jan 16 2020 at 15:02, on Zulip):

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

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

I suspect WG-nll doesn't have anything to report but let me ping Matthew Jasper just in case I'm wrong. (I do know there is at least one open bug (#68090) that I looked at during pre-triage last night,

we hvae a few things

pnkfelix (Jan 16 2020 at 15:02, on Zulip):

We'll start with five minutes for ...

pnkfelix (Jan 16 2020 at 15:02, on Zulip):

Announcements

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

(No one who works on Rust was affected)

pnkfelix (Jan 16 2020 at 15:04, on Zulip):

sstangl was let go, though. (Works on cranelift)

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

I was going to say, although sstangl was :( :(

centril (Jan 16 2020 at 15:05, on Zulip):

but the cranelift backend for Rust seems unaffected?

eddyb (Jan 16 2020 at 15:05, on Zulip):

but the cranelift backend for Rust seems unaffected?

mostly because it's entirely 3rd party AFAIK

eddyb (Jan 16 2020 at 15:05, on Zulip):

(for better or worse...)

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

@nikomatsakis how are the propopals looking for the planning meeting?

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

I haven't looked, tbh, I've been quite busy

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

proposals: https://github.com/rust-lang/compiler-team/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Ameeting-proposal++-label%3Ameeting-scheduled

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

I don't see anything new (I stand corrected)

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

(parser library-ification compiler-team#237 was opened 6 days ago)

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

I was thinking about maybe opening some sort of proposal for some kind of "how are things going" sort of check-in, but I couldn't quite narrow it down :)

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

I just think it's good for us to chat every once in a while ..

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

Well if anyone has a topic they want to put forth, this is the best time to write up a proposal

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

okay, with that, lets move on with the agenda: hackmd

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

first, beta nominations

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

there are two

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

beta-nom 1/2: "Do not ICE on unicode next point" #68084

Esteban Küber (Jan 16 2020 at 15:09, on Zulip):

(For the Unicode one, there's a tiny change that can be backported instead of the whole thing)

pnkfelix (Jan 16 2020 at 15:10, on Zulip):

@Esteban Küber is there already an isolated commit for that?

pnkfelix (Jan 16 2020 at 15:10, on Zulip):

perhaps fcd850fc5db2501d14b2e0cbfac8aa890d700e55

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

omg i didn't know commit hash's were linkified. so cool.

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

doesn't look like there's an isolated commit?

Esteban Küber (Jan 16 2020 at 15:11, on Zulip):

No, sadly I didn't have the foresight of leaving it in its own commit because I didn't realize it would be enough of a fix beforehand

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

is the one I linked not the right one?

simulacrum (Jan 16 2020 at 15:12, on Zulip):

If you intend to backport a specific commit, please leave a comment pointing to a hash of that commit, ideally verified to backport cleanly

Esteban Küber (Jan 16 2020 at 15:12, on Zulip):

No, there's a comment in the or to the relevant part of the diff

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

ah this you mean then? https://github.com/rust-lang/rust/pull/68084/files#r365393957

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

presumably we can squash all commits and backport that?

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

@centril why ... would that be any better ?

Esteban Küber (Jan 16 2020 at 15:13, on Zulip):

The only reason I bring it up is due to the possibility of the full or not meeting cleanly

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

well we're getting in the weeds

Esteban Küber (Jan 16 2020 at 15:14, on Zulip):

If it does, there's no issue, just add a comment to ping me if it doesn't merge cleanly and I can help make a minified berdion

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

It seems like people are generally in favor of backporting this. We don't need to synchronously debate methodology

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

beta-nom 2/2: "expect fn after const unsafe / const extern" #68073

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

definitely looks low risk

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

beta-accepted

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

next, stable nominations

pnkfelix (Jan 16 2020 at 15:17, on Zulip):

its actually the same pair of PR's.

pnkfelix (Jan 16 2020 at 15:17, on Zulip):

stable-nom 1/2: "Do not ICE on unicode next point" #68084

pnkfelix (Jan 16 2020 at 15:18, on Zulip):

We should probably try to be clear about whether we are talking about backporting the whole PR or just the hypothetical one line change

pnkfelix (Jan 16 2020 at 15:18, on Zulip):

I have no problem with just the one line change for stable-backport

pnkfelix (Jan 16 2020 at 15:19, on Zulip):

the PR as a whole ... seems a bit more aggressive, and if we can avoid that, we probably should, no?

pnkfelix (Jan 16 2020 at 15:19, on Zulip):

does anyone disagree? Anyone want to argue for backporting the PR as a whole?

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

Agreed

pnkfelix (Jan 16 2020 at 15:19, on Zulip):

okay that's good enough for me

pnkfelix (Jan 16 2020 at 15:19, on Zulip):

stable-accepted for one line change

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

stable-nom 2/2: "expect fn after const unsafe / const extern" #68073

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

yeah this again looks super low risk, good good

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

stable-accepted

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

okay, next, for waiting on team, we still have "PowerPC C ZST ABI fixes" #64259

pnkfelix (Jan 16 2020 at 15:23, on Zulip):

is @eddyb here?

eddyb (Jan 16 2020 at 15:23, on Zulip):

oh noes

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

oh man, I remember this PR

eddyb (Jan 16 2020 at 15:23, on Zulip):

how is this not resolved yet :(

eddyb (Jan 16 2020 at 15:23, on Zulip):

did I somehow promise to do something and forgot?

pnkfelix (Jan 16 2020 at 15:23, on Zulip):

well we've got, you know, a lot of stuff going on. :)

pnkfelix (Jan 16 2020 at 15:23, on Zulip):

I don't think this is your fault at all @eddyb

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

last I remember we were going to make the PR mildly less aggressive and land?

eddyb (Jan 16 2020 at 15:24, on Zulip):

I don't think this is your fault at all eddyb

I did, you know, block it :P

pnkfelix (Jan 16 2020 at 15:24, on Zulip):

we sort of started a side channel zulip discussion here

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

(I'm probably out of date, it looks like there are also a lot of comments on the issue itself that I don't think I read)

pnkfelix (Jan 16 2020 at 15:25, on Zulip):

last I remember we were going to make the PR mildly less aggressive and land?

did we ever tell the PR author that? or were we doing to adapt the PR ourselves to make it less aggressive?

pnkfelix (Jan 16 2020 at 15:25, on Zulip):

well anyway its something to think about. But I don't think its ultra-high priority ...

pnkfelix (Jan 16 2020 at 15:25, on Zulip):

@eddyb do you want me to assign it to myself?

eddyb (Jan 16 2020 at 15:26, on Zulip):

sure, I don't mind that

pnkfelix (Jan 16 2020 at 15:26, on Zulip):

or do you want to continue having responsibility/privilege of blocking it ? :)

pnkfelix (Jan 16 2020 at 15:26, on Zulip):

okay I'll swipe it then.

eddyb (Jan 16 2020 at 15:26, on Zulip):

I can go and try to make that PR (it should be like a two-line change, after all), but there's a risk I'll forget again

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

did we ever tell the PR author that? or were we doing to adapt the PR ourselves to make it less aggressive?

I don't know but at this point I'd be in favor of just pushing a commit and landing it

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

(I'd push a commit to the existing PR, probably, but the main thing is to send a nice message to the author)

eddyb (Jan 16 2020 at 15:27, on Zulip):

I would not touch the original PR itself, feels like it could be misinterpreted

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

Well lets maybe just try to be nice to the author by some means

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

some people would take offense at having their work re-appropriated in a different PR

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

It's hard to predict, yes. I think it's fine either way.

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

while others, as you note, would take offense at having their own PR re-appropriated via 3rd party commits

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

I guess I would say do this:

eddyb (Jan 16 2020 at 15:29, on Zulip):

what I think should land is much smaller than the original PR, as opposed to being a tweak to it, so that's part of why I want to leave the PR alone

pnkfelix (Jan 16 2020 at 15:29, on Zulip):

anyway lets push things forward (in terms of this meeting)

centril (Jan 16 2020 at 15:29, on Zulip):

some people would take offense at having their work re-appropriated in a different PR

my experience is that this is unlikely to be the case

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

(typically, I find that people are happy if you revive their old work)

eddyb (Jan 16 2020 at 15:30, on Zulip):

it wouldn't be a commit on top of the PR, it would be a tiny commit replacing the PR, though

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

seems fine

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

maybe just alter the final point :)

pnkfelix (Jan 16 2020 at 15:30, on Zulip):

okay, so, nominated issues

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

there are a lot on that list

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

anyway I think the author won't care that much, just open a separate PR and cc them and be nice about it

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

but there are three I have singled out to cover first:

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

nom 1: “SystemV ABI Mismatch on x86 with a repr(C) enum for extern “C”/FFI functions.” #68190

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

#46123 added support for a specified layout of certain non-C-like enums

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

and the problem seems to be with whether the resulting layout+ABI is compatible with SystemV (on x86_64)

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

do we believe the problem is SysV ABIs being incorrectly implemented?

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

anyway I wanted to bring it up because I didn't know how to prioritize this yesterday

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

it sounds like it

eddyb (Jan 16 2020 at 15:34, on Zulip):

ughhhhh

varkor (Jan 16 2020 at 15:34, on Zulip):

anyway I think the author won't care that much, just open a separate PR and cc them and be nice about it

you can always add the author as a git Co-author so they still feel they contributed to the new PR

eddyb (Jan 16 2020 at 15:35, on Zulip):

this is getting into "I really wish ABIs wouldn't try to be clever around unions" territory

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

you can understand it though, right?

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

like, I can easily see people designing the ABI striving to put things in registers whenever possible

eddyb (Jan 16 2020 at 15:35, on Zulip):

it doesn't make me any happier :P

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

anyway

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

so there are two questions

pnkfelix (Jan 16 2020 at 15:36, on Zulip):

Do we agree this is P-high ?

pnkfelix (Jan 16 2020 at 15:36, on Zulip):

I honestly don't know what tier SystemV is

pnkfelix (Jan 16 2020 at 15:36, on Zulip):

I'm glad @nikomatsakis doesn't seem to know either

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

I have no idea either =)

pnkfelix (Jan 16 2020 at 15:36, on Zulip):

well, glad/scared

eddyb (Jan 16 2020 at 15:36, on Zulip):

SysV is the ABI linux uses :P

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

sounds important then :)

pnkfelix (Jan 16 2020 at 15:36, on Zulip):

okay that answers that then

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

P-high.

eddyb (Jan 16 2020 at 15:37, on Zulip):

I think more accurately, it's the x64 non-windows ABI

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

do we want to talk about who is going to investgiate this?

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

it sounds like the diagnosis is .. fairly clear, but I'm not sure @eddyb how easy you think it will be to fix

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

@eddyb what about OS X ?

eddyb (Jan 16 2020 at 15:37, on Zulip):

feels weird to think about SysV running on x64, but I assume it must've happened for everyone (other than Microsoft) to copy the ABI

eddyb (Jan 16 2020 at 15:38, on Zulip):

@pnkfelix SysV. we don't implement any x64 ABI other than sysv and win64

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

@eddyb do you think you have bandwidth to look at this?

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

@pnkfelix can you elaborate on the t-lang component?

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

fwiw we do have a page about tiers here

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

(but I think we should take some notes on "Questions we should be able to quickly answer" and make sure they are covered well on the page)

eddyb (Jan 16 2020 at 15:38, on Zulip):

@pnkfelix I'm not sure I do but this sounds important enough, and the hard part will be choosing a solution

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

can you elaborate on the t-lang component?

I don't personally think there is one

pnkfelix (Jan 16 2020 at 15:39, on Zulip):

pnkfelix can you elaborate on the t-lang component?

The T-lang comment was based on my (potentially mis)impression that this was something with #[repr(...)] that could be resolved at a language level

pnkfelix (Jan 16 2020 at 15:39, on Zulip):

but I'm happy to remove the T-lang label

eddyb (Jan 16 2020 at 15:39, on Zulip):

hang on a second...

eddyb (Jan 16 2020 at 15:39, on Zulip):

lmao https://github.com/rust-lang/rust/blob/master/src/librustc_target/abi/call/x86_64.rs#L67

eddyb (Jan 16 2020 at 15:40, on Zulip):

@pnkfelix okay, this is a silly situation where nobody changed the code when we spec'd the behavior

eddyb (Jan 16 2020 at 15:40, on Zulip):

so it still does the naive thing

pnkfelix (Jan 16 2020 at 15:40, on Zulip):

lmao https://github.com/rust-lang/rust/blob/master/src/librustc_target/abi/call/x86_64.rs#L67

Okay then that's enough for me to decide @eddyb is the right person to drive resolution here

pnkfelix (Jan 16 2020 at 15:40, on Zulip):

if only via mentorship

eddyb (Jan 16 2020 at 15:40, on Zulip):

this also means every ABI should be checked for handling enums as unions...

centril (Jan 16 2020 at 15:41, on Zulip):

let's move on?

nagisa (Jan 16 2020 at 15:41, on Zulip):

don’t we have codegen tests for those?

pnkfelix (Jan 16 2020 at 15:41, on Zulip):

yep, lets move on

eddyb (Jan 16 2020 at 15:41, on Zulip):

@nagisa apparently nothing that could be passed in registers :/ (or if it's only a codegen test and not a real FFI test, the expected LLVM IR is wrong)

pnkfelix (Jan 16 2020 at 15:41, on Zulip):

nom 2. "Project fails to link when using dylibs and the -Zshare-generics flag" #67276

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

oh maybe this is resolved now/soon

oli (Jan 16 2020 at 15:42, on Zulip):

has a PR since 3 hours

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

I left nominated ... why did I ...

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

let's make it p-high

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

it's a regression and there's a probable fix, so not much harm in that

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

okay

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

nom 3. "Recent nightly doesn’t support array length from indirectly referenced trait constant" #67743

oli (Jan 16 2020 at 15:43, on Zulip):

has a PR since 30 mins

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

I nominated it because its blocking ...

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

/me looks

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

heh

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

okay then

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

well there are all the other nominated issues. but there are nominated PR's, lets maybe focus on those

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

nominated PRs

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

(thank you to whomever filled in that part of the hackmd)

pnkfelix (Jan 16 2020 at 15:45, on Zulip):

nom PR 1/4: "Added tvOS as targets" #68191

pnkfelix (Jan 16 2020 at 15:45, on Zulip):

what is our stability story for targets?

nagisa (Jan 16 2020 at 15:45, on Zulip):

not sure why it is nominated. We either add the targets if the implementation is good enough or we don’t.

nagisa (Jan 16 2020 at 15:45, on Zulip):

we've been very accepting of tier 3 target additions

pnkfelix (Jan 16 2020 at 15:45, on Zulip):

i.e. is there a mechanism for adding targets unstably?

centril (Jan 16 2020 at 15:45, on Zulip):

@Esteban Küber elaborate?

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

i.e. is there a mechanism for adding targets unstably?

we just add them, and are free to remove them at any time

nagisa (Jan 16 2020 at 15:46, on Zulip):

@pnkfelix there is no stability mechanism like APIs have, but tier3 targets are effectively unstable

pnkfelix (Jan 16 2020 at 15:46, on Zulip):

but they still end up in stable channel?

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

I'm going to start tagging questions in a hackmd for "questions we have about tiers", but yes, this is what we have done traditionally

pnkfelix (Jan 16 2020 at 15:46, on Zulip):

(am I wrong for having a gut reaction to that?)

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

not even tier 1 targets are stable

pnkfelix (Jan 16 2020 at 15:47, on Zulip):

okay well if its what we do, its what we do.

simulacrum (Jan 16 2020 at 15:47, on Zulip):

Use isn't possible because you need libcore equivalent

simulacrum (Jan 16 2020 at 15:47, on Zulip):

Or so I assume

Esteban Küber (Jan 16 2020 at 15:47, on Zulip):

I didn't feel comfortable approving on my own

pnkfelix (Jan 16 2020 at 15:47, on Zulip):

I guess we're in the weeds. And this doesn't need further discussion as a team?

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

(and I mean that in a practical sense because we're demoting a tier 1 target)

centril (Jan 16 2020 at 15:48, on Zulip):

I've reassigned the PR to @nagisa

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

I guess if people are interested or have expertise, they can go comment directly on the PR or allocate a zulip topic

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

nom PR 2/4: "Change opt-level from 2 back to 3" #67878

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

(hackmd for questions that arise about tiers)

eddyb (Jan 16 2020 at 15:49, on Zulip):

@pnkfelix btw earlier I was looking for this issue, which keeps growing in the number of random things we get wrong in ABIs, to some extent or another https://github.com/rust-lang/rust/issues/65111

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

re #67878: there's still some active investigation going on.

simulacrum (Jan 16 2020 at 15:49, on Zulip):

Mainly needs an answer about whether we care about the size increase

centril (Jan 16 2020 at 15:49, on Zulip):

I think x86 tier 1 targets should come first personally

centril (Jan 16 2020 at 15:49, on Zulip):

since that's most users

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

so this would benefit more users than it would harm

nagisa (Jan 16 2020 at 15:50, on Zulip):

Size increase will likely come from more inlining

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

(so my conclusion is let's r+)

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

I think I agree with @simulacrum that this is the important Q to answer: " is it spread out across all of libcore/std or a few functions getting significantly larger?"

nagisa (Jan 16 2020 at 15:50, on Zulip):

While embedded definitely cares about it, I think there’s something to say about them having their own tools to override this.

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

Seems probable. To be clear, the situation was something like:

simulacrum (Jan 16 2020 at 15:50, on Zulip):

Yes

simulacrum (Jan 16 2020 at 15:51, on Zulip):

We can probably also optimize only on x86, I guess

pnkfelix (Jan 16 2020 at 15:51, on Zulip):

that's an interesting approach

mw (Jan 16 2020 at 15:51, on Zulip):

one could make the argument that embedded platforms should have an -Copt-level=s libstd anyway?

nagisa (Jan 16 2020 at 15:51, on Zulip):

How many embedded targets we distribute libstd for? I believe its just thumb?

pnkfelix (Jan 16 2020 at 15:51, on Zulip):

especially since that target might get more testing within LLVM, right?

simulacrum (Jan 16 2020 at 15:51, on Zulip):

Thumb and llvm

simulacrum (Jan 16 2020 at 15:51, on Zulip):

Er, wasm

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

(and thus we might trust opt-level=3 more there than other less tested targets)

centril (Jan 16 2020 at 15:52, on Zulip):

although that makes test suites and stuff more fragile ostensibly if we diverge

eddyb (Jan 16 2020 at 15:52, on Zulip):

@mw I wonder how well that works (opt-level=s/z, that is). I've tried it out on a large WASM project and it made things slightly worse, instead

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

Anyway

nagisa (Jan 16 2020 at 15:52, on Zulip):

sounds definitely like a better approach to override those targets to opt-level-s as @mw proposes.

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

@simulacrum do you think the PR author will be happy to do the investigation you requested?

mw (Jan 16 2020 at 15:52, on Zulip):

yes, whatever produces the smallest libstd, anyway

simulacrum (Jan 16 2020 at 15:53, on Zulip):

@pnkfelix Not sure. I would not have the time myself.

I do lean towards just landing it

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

I think that having distinct optimization levels for targets sounds reasonable.

mw (Jan 16 2020 at 15:53, on Zulip):

It's basically a variation of @simulacrum's suggestion

simulacrum (Jan 16 2020 at 15:53, on Zulip):

(and we can explore minimizing size via different opt-levels for some targets at a later point)

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

compiletest is going to be so happy with this =P

pnkfelix (Jan 16 2020 at 15:53, on Zulip):

pnkfelix Not sure. I would not have the time myself.

I do lean towards just landing it

We could just land and let people who care do the investigation in parallel

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

But I also think we could land it

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

Yes, basically what @pnkfelix just said

pnkfelix (Jan 16 2020 at 15:53, on Zulip):

i.e. I suspect this code size need not block movement

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

land it and if people complain, then we try to reduce

simulacrum (Jan 16 2020 at 15:53, on Zulip):

or, e.g., I could imagine we make opt-level=3 only apply to the compiler at least :)

pnkfelix (Jan 16 2020 at 15:53, on Zulip):

any objections to just landing?

oli (Jan 16 2020 at 15:54, on Zulip):

6 minutes :alarm_clock:

centril (Jan 16 2020 at 15:54, on Zulip):

seems like we're just landing it

pnkfelix (Jan 16 2020 at 15:54, on Zulip):

okay lets assume that's happening

pnkfelix (Jan 16 2020 at 15:54, on Zulip):

PR nom 3/4: "Fix some of the rustfmt fallout in Miri" #67833

simulacrum (Jan 16 2020 at 15:54, on Zulip):

I will write up relevant commentary

pnkfelix (Jan 16 2020 at 15:54, on Zulip):

that one was left over I think

oli (Jan 16 2020 at 15:54, on Zulip):

TLDR: do we accept #[rustfmt::skip] PRs just like we did accept tidy bailouts?

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

though I was hoping to move forward with a suggestion I had made to @RalfJ on another workaround

oli (Jan 16 2020 at 15:55, on Zulip):

(and open issues on rustfmt, or point to existing ones)

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

I'm personally fine with accepting them if they link to open issues

centril (Jan 16 2020 at 15:55, on Zulip):

/me would rather use #[rustfmt::skip] than to use Felix's suggestion :P

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

but I would also be fine with saying we won't objecrt.

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

/me would rather use #[rustfmt::skip] than to use Felix's suggestion :P

you mean my more recent suggestion?

centril (Jan 16 2020 at 15:55, on Zulip):

I think we shouldn't do this

oli (Jan 16 2020 at 15:56, on Zulip):

We can always revert and nix all the #[rustfmt::skip] attributes

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

(of a flag to preserve brace style?)

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

I just kind of don't care this much

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

But I think "land rustfmt::skip with a link to an issue" is a reasonable compromise

centril (Jan 16 2020 at 15:56, on Zulip):

(@pnkfelix this one: let val; ...; val = expr)

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

we should be using this dogfooding to provide feedback, I think

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

(pnkfelix this one: let val; ...; val = expr)

oh yeah that one is getting GC'ed like the garbage it is

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

okay then lets just say we won't accept this PR then

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

less churn

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

I think filing issues for outright bugs is fine, but I would like us not to have skips

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

nom PR 4/4: "windows-gnu: prefer system crt libraries if they are available" #67429

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

heck if I know what status is here

mati865 (Jan 16 2020 at 15:57, on Zulip):

Waiting for the review I guess?

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

@Matthew Jasper do you want to hand this off to someone else?

mati865 (Jan 16 2020 at 15:58, on Zulip):

It was supposed to be discussed 2 weeks ago on the meeting ^^

nagisa (Jan 16 2020 at 15:58, on Zulip):

SGTM, altohugh I feel like the alternative of including headers could also be a reasonable solution

nagisa (Jan 16 2020 at 15:59, on Zulip):

also why do we even keep distributing our own copy if we just gonna use system ones anyway?

centril (Jan 16 2020 at 15:59, on Zulip):

looks like this needs reviewer reassignment in any case?

centril (Jan 16 2020 at 15:59, on Zulip):

@nagisa do you want r?

mati865 (Jan 16 2020 at 15:59, on Zulip):

SGTM, altohugh I feel like the alternative of including headers could also be a reasonable solution

I think that would make using system libraries (like libpng, or zlib) impossible.

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

It was supposed to be discussed 2 weeks ago on the meeting ^^

we don't get to every nominated issue. And also the nominated PR's are... not always handled well...

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

okay then lets just say we won't accept this PR then

(I'm not entirely comfortable with this outcome yet, for the record, but I'll leave a comment on PR, dont' want to continue debating now)

nikomatsakis (Jan 16 2020 at 16:00, on Zulip):

okay then lets just say we won't accept this PR then

(I'm not entirely comfortable with this outcome yet, for the record, but I'll leave a comment on PR, dont' want to continue debating now)

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

well time is up. :sad:

nagisa (Jan 16 2020 at 16:00, on Zulip):

@centril no, I don’t windows much

mati865 (Jan 16 2020 at 16:00, on Zulip):

It was supposed to be discussed 2 weeks ago on the meeting ^^

we don't get to every nominated issue. And also the nominated PR's are... not always handled well...

I think it was missed because had no T-compiler label.

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

@nagisa ok hmm; who would be appropriate here? Alex?

nagisa (Jan 16 2020 at 16:00, on Zulip):

Probably.

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

I doubt matthew wants to review this

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

it can wait another week

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

WG checkins

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

reassigned for now

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

after meeting is over, so much fun

oli (Jan 16 2020 at 16:02, on Zulip):

i gotta run :running: :wave:

pnkfelix (Jan 16 2020 at 16:02, on Zulip):

you can see WG checkins here: https://hackmd.io/ruw4k37lSJ6RDVOFfhdQ7Q?both#WG-checkins

pnkfelix (Jan 16 2020 at 16:02, on Zulip):

sorry for mismanaging time once again

pnkfelix (Jan 16 2020 at 16:02, on Zulip):

and thank you to everyone in @T-compiler/meeting for attending!!

Josh Triplett (Jan 23 2020 at 18:04, on Zulip):

@nikomatsakis I only just now caught up to this mention. (Also, I'm a little behind dealing with the target tier RFC, but I still intend to go back and incorporate feedback and post a new version.)

Josh Triplett (Jan 23 2020 at 18:04, on Zulip):

Regarding the sysv ABI, yes, it's a high priority as it's the ABI for non-Windows platforms on x86, so it affects tier 1 targets.

Josh Triplett (Jan 23 2020 at 18:05, on Zulip):

It's absolutely P-high.

Josh Triplett (Jan 23 2020 at 18:10, on Zulip):

Reading the issue, I think the assessment of the bug is accurate.

Josh Triplett (Jan 23 2020 at 18:11, on Zulip):

And yeah, some of the historical cleverness of ABIs may not be warranted today, but we have to match it precisely nonetheless.

pnkfelix (Jan 23 2020 at 19:09, on Zulip):

(for reference, the above was responding to a ping regarding issue #68190 )

Josh Triplett (Jan 23 2020 at 20:25, on Zulip):

Right. I should have quoted the context I was replying to.

Last update: Feb 25 2020 at 04:25UTC