Stream: t-compiler

Topic: weekly meeting 2019-10-17 #54818


pnkfelix (Oct 17 2019 at 12:19, on Zulip):

Hi @T-compiler/meeting ; the triage meeting will be starting in 1 hour 41 minutes

pnkfelix (Oct 17 2019 at 12:19, on Zulip):

I will be doing pre-triage in a parallel topic

pnkfelix (Oct 17 2019 at 12:20, on Zulip):

WG-checkins this week are from WG-meta and WG-mir-opt

pnkfelix (Oct 17 2019 at 12:20, on Zulip):

:question: For @T-compiler/WG-meta : would either @davidtwco or @Santiago Pastorino be willing to present an update?

pnkfelix (Oct 17 2019 at 12:21, on Zulip):

:question: for @WG-mir-opt : is @oli around? And would they be willing to present an update?

oli (Oct 17 2019 at 12:22, on Zulip):

I am around, I'll prep an update

pnkfelix (Oct 17 2019 at 12:41, on Zulip):

:question: for @T-compiler : do we have a good subteam to whom to delegate issue #65391 ("rust-lld since 1.38 overlaps .text with .rodata for embedded arm target")? Who is best to poke at what I presume is a rust-lld bug?

nikomatsakis (Oct 17 2019 at 12:46, on Zulip):

@pnkfelix is this specific to arm? if so, I have a contact I can forward it to

pnkfelix (Oct 17 2019 at 12:47, on Zulip):

pnkfelix is this specific to arm? if so, I have a contact I can forward it to

not 100% clear if its solely on arm

pnkfelix (Oct 17 2019 at 12:47, on Zulip):

but that was where it was observed

pnkfelix (Oct 17 2019 at 12:47, on Zulip):

to be honest I don't know where/when we use rust-lld

nikomatsakis (Oct 17 2019 at 12:55, on Zulip):

ok well I sent an e-mail -- there is someone at Arm who was interested in hearing about things. I'm going to see if I can get them added to Zulip or Github or something.

nikomatsakis (Oct 17 2019 at 12:55, on Zulip):

Maybe they've got some idea of someone who would know exactly what's going on, who knows.

Santiago Pastorino (Oct 17 2019 at 13:30, on Zulip):

I can present an update for meta, when that will happen? at the end of the meeting, right?

pnkfelix (Oct 17 2019 at 13:30, on Zulip):

@Santiago Pastorino right

Santiago Pastorino (Oct 17 2019 at 13:30, on Zulip):

:+1:

pnkfelix (Oct 17 2019 at 13:31, on Zulip):

:question: for @T-compiler/meeting : as a dev procedure matter, if an issue has been "fixed" by some PR, but someone discovers a variant of the original MCVE that triggers the same bug, should they: (1.) reopen the original issue and post a comment, or (2.) reopen the original issue and add the new example to the description, or (3.) open a fresh issue (and if possible, link to original closed issue, but leave it closed)

pnkfelix (Oct 17 2019 at 13:31, on Zulip):

/me eagerly awaits the votes

nagisa (Oct 17 2019 at 13:32, on Zulip):

Addendum to 3, if they are able to find the original, linking to it is great.

pnkfelix (Oct 17 2019 at 13:32, on Zulip):

oh yeah, I'll add that

pnkfelix (Oct 17 2019 at 13:33, on Zulip):

the good thing is that its relatively easy to "correct" 1 or 2 by upgrading them to 3

centril (Oct 17 2019 at 13:34, on Zulip):

I think most issue reporters won't know or care about whatever policy we have tho

centril (Oct 17 2019 at 13:34, on Zulip):

(they'll likely do 3.)

pnkfelix (Oct 17 2019 at 13:35, on Zulip):

I mostly want to know if I should avoid upgrading 1/2 to 3

pnkfelix (Oct 17 2019 at 13:35, on Zulip):

but it seems like the votes so far that people will not mind such action

pnkfelix (Oct 17 2019 at 13:38, on Zulip):

:construction_worker: @nikomatsakis if ARM folks are looking to help out, we could use a hand on "Segfault compiling libc on armv7-unknown-linux-gnueabihf" #62896

pnkfelix (Oct 17 2019 at 13:48, on Zulip):

:construction_worker: If you are a Windows GNU developer (aka mingw, I think), we could use help looking into this bug: " couldn't load codegen backend on windows-gnu" #61561

pnkfelix (Oct 17 2019 at 14:04, on Zulip):

Hi @T-compiler/meeting

pnkfelix (Oct 17 2019 at 14:04, on Zulip):

we're starting now. We'll dedicate five minutes to announcements

pnkfelix (Oct 17 2019 at 14:05, on Zulip):

:exclamation: we have a design meeting tomorrow about our debuginfo strategy

nikomatsakis (Oct 17 2019 at 14:05, on Zulip):
nikomatsakis (Oct 17 2019 at 14:06, on Zulip):
nikomatsakis (Oct 17 2019 at 14:07, on Zulip):
centril (Oct 17 2019 at 14:08, on Zulip):

@nikomatsakis n.b. tho that lazy normalization for constants interacts with provided defaults (associated_type_defaults) so we need to ensure that the RFCs rules apply before allowing more code

nikomatsakis (Oct 17 2019 at 14:08, on Zulip):

hmm, interesting ok :) -- let's discuss offline

nikomatsakis (Oct 17 2019 at 14:08, on Zulip):
Santiago Pastorino (Oct 17 2019 at 14:09, on Zulip):
centril (Oct 17 2019 at 14:09, on Zulip):

Update re. libsyntax: I'm working on it (https://github.com/rust-lang/rust/pull/65324) slowly but surely

pnkfelix (Oct 17 2019 at 14:09, on Zulip):

regarding ICE-breakers

pnkfelix (Oct 17 2019 at 14:09, on Zulip):

do I need to worry about my choice of P-high/P-medium prioirty assignments?

nikomatsakis (Oct 17 2019 at 14:10, on Zulip):

@pnkfelix I don't think so, but we should discuss how to use it as part of pre-triage etc

pnkfelix (Oct 17 2019 at 14:10, on Zulip):

i.e. is that going to somehow screw things up if I downgrade an ICE from P-high to P-medium because I'm tired of looking at it each week?

Santiago Pastorino (Oct 17 2019 at 14:10, on Zulip):

first PR there's a weird macro that's under discussion and in the other PR I'd need to make some refactors before merging because there's a lot of code duplication

nikomatsakis (Oct 17 2019 at 14:10, on Zulip):

oh, no, in fact, this is specifically meant for things that are not p-high, @pnkfelix -- basically more a way to "call attention" to bugs

pnkfelix (Oct 17 2019 at 14:11, on Zulip):

oh I always keep forgetting that "ICE breakers" is not necessarily about "Internal Compiler Error" bugs (but it can be)

pnkfelix (Oct 17 2019 at 14:12, on Zulip):

this pun is going to kill me

nikomatsakis (Oct 17 2019 at 14:12, on Zulip):

Draft blog post announcing LLVM ICE-breakers

nikomatsakis (Oct 17 2019 at 14:12, on Zulip):

Yeah maybe the name is ultimately unwise for that reason :)

nikomatsakis (Oct 17 2019 at 14:12, on Zulip):

but I can't think of a better one

centril (Oct 17 2019 at 14:13, on Zulip):

wait... ICE-breakers is not about breaking ICEs?

pnkfelix (Oct 17 2019 at 14:13, on Zulip):

/me ponders puns on "blind date"

centril (Oct 17 2019 at 14:13, on Zulip):

confusing...

nikomatsakis (Oct 17 2019 at 14:13, on Zulip):

not just about that

pnkfelix (Oct 17 2019 at 14:13, on Zulip):

From the post: "In fact, very few LLVM bugs cause real ICEs, but the name was too good to pass up."

nagisa (Oct 17 2019 at 14:14, on Zulip):

ain’t every llvm assertion an ICE?

pnkfelix (Oct 17 2019 at 14:14, on Zulip):

not if we have them turned off

centril (Oct 17 2019 at 14:14, on Zulip):

not sure why we coupled LLVM with ICEs...

nikomatsakis (Oct 17 2019 at 14:14, on Zulip):

touche

nagisa (Oct 17 2019 at 14:14, on Zulip):

eeeeh, I could say that a sigsegv is still an ICE :slight_smile:

centril (Oct 17 2019 at 14:14, on Zulip):

but shall we start?

pnkfelix (Oct 17 2019 at 14:15, on Zulip):

yeah okay so that's ten minutes of announcements. Feel free to privmsg me if you want me to allocate time at the end for anything people forgot

pnkfelix (Oct 17 2019 at 14:15, on Zulip):

So, lets see

pnkfelix (Oct 17 2019 at 14:15, on Zulip):

beta-noms

pnkfelix (Oct 17 2019 at 14:16, on Zulip):

there are two

pnkfelix (Oct 17 2019 at 14:16, on Zulip):

beta-nom 1/2: "Add troubleshooting section to PGO chapter in rustc book." #65402

pnkfelix (Oct 17 2019 at 14:16, on Zulip):

...why ...

pnkfelix (Oct 17 2019 at 14:16, on Zulip):

why would we back port an entry in the rustc book ?

pnkfelix (Oct 17 2019 at 14:17, on Zulip):

oh wait

pnkfelix (Oct 17 2019 at 14:17, on Zulip):

I'm confusing rustc book with rustc guide, aren't i

pnkfelix (Oct 17 2019 at 14:17, on Zulip):

this is targetted at rustc users right? Not rustc developers?

nikomatsakis (Oct 17 2019 at 14:17, on Zulip):

(perhaps we should rename rustc-guide)

nikomatsakis (Oct 17 2019 at 14:17, on Zulip):

rustc deveopers guide, something like that

pnkfelix (Oct 17 2019 at 14:17, on Zulip):

okay well

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

sorry i forgot to add the vote emojis

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

I guess it seems there is like zero harm in doing this

centril (Oct 17 2019 at 14:19, on Zulip):

accepted?

pnkfelix (Oct 17 2019 at 14:19, on Zulip):

and @mw said they were nominating for backport when they posted, so @Alex Crichton was aware of that intent

pnkfelix (Oct 17 2019 at 14:19, on Zulip):

so yeah, I guess beta-accepted

pnkfelix (Oct 17 2019 at 14:19, on Zulip):

just ... weird ...

nikomatsakis (Oct 17 2019 at 14:19, on Zulip):

( opened an issue "rename to rustc-dev-guide" rustc-guide#470 )

centril (Oct 17 2019 at 14:20, on Zulip):

aww, that will invalidate my Firefox history :D

pnkfelix (Oct 17 2019 at 14:20, on Zulip):

beta-nom 2/2: "Optimize try_expand_impl_trait_type" #65293

centril (Oct 17 2019 at 14:21, on Zulip):

why is this beta nominated?

pnkfelix (Oct 17 2019 at 14:21, on Zulip):

because of async, I infer

centril (Oct 17 2019 at 14:21, on Zulip):

ah there's a regression

nikomatsakis (Oct 17 2019 at 14:21, on Zulip):

well, a quasi-regression

nikomatsakis (Oct 17 2019 at 14:21, on Zulip):

since async wasn't usable

nikomatsakis (Oct 17 2019 at 14:22, on Zulip):

I could go either way on this, but I think it's low risk, and it can be a massive compilation time win

nagisa (Oct 17 2019 at 14:22, on Zulip):

I also nominated https://github.com/rust-lang/rust/pull/65172 just now for a similar reason.

pnkfelix (Oct 17 2019 at 14:22, on Zulip):

does the optimization in question only end up applying to Async types?

pnkfelix (Oct 17 2019 at 14:22, on Zulip):

or does it just happen to correlate with types that tend to be generated as part of async code?

nikomatsakis (Oct 17 2019 at 14:22, on Zulip):

hmm actualy no

nikomatsakis (Oct 17 2019 at 14:22, on Zulip):

good point

nikomatsakis (Oct 17 2019 at 14:23, on Zulip):

I think it applies to any impl trait type

pnkfelix (Oct 17 2019 at 14:23, on Zulip):

I don't know if that makes me more or less inclined to backport

pnkfelix (Oct 17 2019 at 14:24, on Zulip):

but I guess no one is objecting

pnkfelix (Oct 17 2019 at 14:24, on Zulip):

so okay, accepted for backport

centril (Oct 17 2019 at 14:24, on Zulip):

I guess I wonder if we are sure-sure it is safe?

pnkfelix (Oct 17 2019 at 14:25, on Zulip):

I guess I wonder if we are sure-sure it is safe?

is that like "the true-true" ?

centril (Oct 17 2019 at 14:25, on Zulip):

it's extra sure :slight_smile:

nikomatsakis (Oct 17 2019 at 14:25, on Zulip):

iirc, we are searching through the type tree, and this just avoids re-searching the same types over and over

centril (Oct 17 2019 at 14:26, on Zulip):

ok let's :back: then

pnkfelix (Oct 17 2019 at 14:26, on Zulip):

sure, okay

pnkfelix (Oct 17 2019 at 14:26, on Zulip):

beta-nom 3/2 ( :wink: @nagisa ): " use precalculated dominators in explain_borrow" #65172

nagisa (Oct 17 2019 at 14:27, on Zulip):

I nominated this because this is similar to before in that without this PR we spend hours… doing stuff

nagisa (Oct 17 2019 at 14:27, on Zulip):

in this case generating borrow errors.

pnkfelix (Oct 17 2019 at 14:27, on Zulip):

oh my

pnkfelix (Oct 17 2019 at 14:27, on Zulip):

talk about small diffs

nikomatsakis (Oct 17 2019 at 14:27, on Zulip):

lol

pnkfelix (Oct 17 2019 at 14:28, on Zulip):

okay sure accepted for beta backport

pnkfelix (Oct 17 2019 at 14:29, on Zulip):

next up

pnkfelix (Oct 17 2019 at 14:29, on Zulip):

stable-noms

pnkfelix (Oct 17 2019 at 14:29, on Zulip):

zero stable-noms!

pnkfelix (Oct 17 2019 at 14:30, on Zulip):

We won't go over the list of stable-to-beta and stable-to-nightly regressions here

pnkfelix (Oct 17 2019 at 14:30, on Zulip):

(you can see what I got through during pre-triage in that topic)

pnkfelix (Oct 17 2019 at 14:31, on Zulip):

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

pnkfelix (Oct 17 2019 at 14:31, on Zulip):

hopefuly this will be quick

pnkfelix (Oct 17 2019 at 14:32, on Zulip):

waiting-on-team aka WOT: "Remove rust optimize" #65408

pnkfelix (Oct 17 2019 at 14:32, on Zulip):

I nominated this.

pnkfelix (Oct 17 2019 at 14:32, on Zulip):

the basic question is this: The rustc config.toml has a optimize = true default setting

pnkfelix (Oct 17 2019 at 14:32, on Zulip):

but on some targets, if you set it to false, the build fails

pnkfelix (Oct 17 2019 at 14:32, on Zulip):

(#65352)

pnkfelix (Oct 17 2019 at 14:33, on Zulip):

so the PR author suggested "why don't we just remove this option's documentation from the config.toml

nagisa (Oct 17 2019 at 14:33, on Zulip):

I’m not against, it is infesible to build rustc without optimisations enabled for more reasons than that it just fails.

pnkfelix (Oct 17 2019 at 14:33, on Zulip):

You can see on the comments on #65408 that I'm torn about this

nikomatsakis (Oct 17 2019 at 14:33, on Zulip):

wait

nikomatsakis (Oct 17 2019 at 14:34, on Zulip):

huh, I'm surprised anyone would consider this :)

pnkfelix (Oct 17 2019 at 14:34, on Zulip):

the main reason I'm torn is: If you just remove this documentation, then are people going to be surprised that setting debug = true does not disable optimizations?

nikomatsakis (Oct 17 2019 at 14:34, on Zulip):

though it's true I never set the flag to false :)

pnkfelix (Oct 17 2019 at 14:35, on Zulip):

anyway i'll repost in the form of a vote

pnkfelix (Oct 17 2019 at 14:35, on Zulip):

WOT: "Remove rust optimize" #65408

nikomatsakis (Oct 17 2019 at 14:35, on Zulip):

I guess I do feel these are all advanced options and we should just say like "it is strongly recommended to set this to true; on some architectures we can' build without it"

nikomatsakis (Oct 17 2019 at 14:35, on Zulip):

but I can leave a comment

centril (Oct 17 2019 at 14:35, on Zulip):

Seems like dead code in practice? I'm in favor of removing dead code ^^

pnkfelix (Oct 17 2019 at 14:36, on Zulip):

I used to set it to false on occasion

pnkfelix (Oct 17 2019 at 14:36, on Zulip):

but its been years

nagisa (Oct 17 2019 at 14:36, on Zulip):

In my experience people who set this option to false do so by mistake (and then spend waiting days for rustc to bootstrap)

nagisa (Oct 17 2019 at 14:36, on Zulip):

There have been a couple of cases of this happening.

pnkfelix (Oct 17 2019 at 14:36, on Zulip):

@nagisa has that happened recently? Even with the big warning sign we added?

nagisa (Oct 17 2019 at 14:36, on Zulip):

Not recently no, last instance I remember was > year ago.

pnkfelix (Oct 17 2019 at 14:37, on Zulip):

okay

pnkfelix (Oct 17 2019 at 14:37, on Zulip):

anyway, maybe lets let people put any further thoughts onto the PR itself as comments

pnkfelix (Oct 17 2019 at 14:37, on Zulip):

(I won't veto it landing)

pnkfelix (Oct 17 2019 at 14:37, on Zulip):

(but I might be more inclined to take an approach like what @nikomatsakis suggests...)

pnkfelix (Oct 17 2019 at 14:38, on Zulip):

WOT: "Mention keyword closing policy" #65007

pnkfelix (Oct 17 2019 at 14:38, on Zulip):

oh I didn't know we weren't suppose to put those into commit messages

centril (Oct 17 2019 at 14:38, on Zulip):

I think it's sometimes useful to mention issues in commits

centril (Oct 17 2019 at 14:38, on Zulip):

@pnkfelix I don't think that has been established yet :slight_smile:

centril (Oct 17 2019 at 14:39, on Zulip):

for example, while working on a PR I might note an issue number in the commit message so that I remember it

pnkfelix (Oct 17 2019 at 14:39, on Zulip):

There is a difference between linking an issue and writing "fix #NNN"

centril (Oct 17 2019 at 14:39, on Zulip):

also note that rollups do these automatically

pnkfelix (Oct 17 2019 at 14:39, on Zulip):

the text that I see only says, I think, to avoid the latter?

pnkfelix (Oct 17 2019 at 14:40, on Zulip):

anyway if we actually want to enforce if, we probably should do so with tidy or something, no?

centril (Oct 17 2019 at 14:40, on Zulip):

it seems the purpose of the proposal is to "keep things tidy"

pnkfelix (Oct 17 2019 at 14:40, on Zulip):

seems silly to make it a policy that few of the devs would be aware of ...

centril (Oct 17 2019 at 14:40, on Zulip):

and then closing keywords or just mentions won't make a difference (also see: rollups do this automatically...)

centril (Oct 17 2019 at 14:40, on Zulip):

agree; I think we shouldn't legislate here

nikomatsakis (Oct 17 2019 at 14:41, on Zulip):

I'm of two minds. The main advantage I see to having things in the PR is that I often find myself editing the PR heading to remove "Fixes #123" or whatever (or to add it!), depending on whether I think the PR truly fixes the entire issue

nikomatsakis (Oct 17 2019 at 14:41, on Zulip):

But mostly I don't care and don't think it matters that much what we say here :)

pnkfelix (Oct 17 2019 at 14:41, on Zulip):

also, isn't it weird that this PR says it fixes #59233

nikomatsakis (Oct 17 2019 at 14:41, on Zulip):

( Also, putting #123 in commit messages can lead to a lot of "comment spam" on issues sometimes, where the commit is cited again and again. )

pnkfelix (Oct 17 2019 at 14:41, on Zulip):

when that issue is about avoiding merge commits

pnkfelix (Oct 17 2019 at 14:41, on Zulip):

and yet the text here makes no mention of merge commits ?

centril (Oct 17 2019 at 14:42, on Zulip):

@nikomatsakis that mostly comes from rollups tho

pnkfelix (Oct 17 2019 at 14:42, on Zulip):

oh I see, it was going to be closed, but then someone asked to keep it open due to this closing-keyword issue

nikomatsakis (Oct 17 2019 at 14:42, on Zulip):

precisely example of the phenomenon I am talking about, perhaps :)

nagisa (Oct 17 2019 at 14:43, on Zulip):

The only thing I wish people did not put into commit messages are r? @mention.

nikomatsakis (Oct 17 2019 at 14:43, on Zulip):

I see the original reasoning is referring to what I am talking about:

I think we should encourage contributors close issues by keywords in PR descriptions only.
Because otherwise the commit could be rebased many times, and each time it creates a reference to
the want-to-close issue.

pnkfelix (Oct 17 2019 at 14:43, on Zulip):

The only thing I wish people did not put into commit messages are r? @mention.

seems like thats an even more important policy to establish

oli (Oct 17 2019 at 14:43, on Zulip):

well.. bors does that because it copies the main post of a PR

centril (Oct 17 2019 at 14:43, on Zulip):

(Re. rollups: If you write Fixes #12345 in the PR description it generates a ping because it translates into the commit message.)

centril (Oct 17 2019 at 14:44, on Zulip):

Yeah, and I don't think that should change

pnkfelix (Oct 17 2019 at 14:44, on Zulip):

Nonetheless I think the point here is about policy for human-written messages, not the rollup-generated nor bors-generated ones

centril (Oct 17 2019 at 14:44, on Zulip):

it's useful to have links in that commit message

pnkfelix (Oct 17 2019 at 14:44, on Zulip):

the rollup and bors generated messages represent the final state of the PR description at merge time, right?

centril (Oct 17 2019 at 14:44, on Zulip):

@pnkfelix assuming it lands :slight_smile:

pnkfelix (Oct 17 2019 at 14:44, on Zulip):

while human written commit messages are often outdated w.r.t. their actual real effects on the issues DB

centril (Oct 17 2019 at 14:45, on Zulip):

(which often does not happen)

pnkfelix (Oct 17 2019 at 14:45, on Zulip):

My point is that I think it is reasonable to say that we want a policy like this for the human authored messages

nikomatsakis (Oct 17 2019 at 14:45, on Zulip):

I feel like we're spending a lot of time for text next to nobody reads:)

pnkfelix (Oct 17 2019 at 14:45, on Zulip):

the bors and rollups can follow a different policy that does not have to be a superset of the rules

pnkfelix (Oct 17 2019 at 14:46, on Zulip):

/me used to be famous for their commit messages that no one would read

centril (Oct 17 2019 at 14:46, on Zulip):

What is the policy exactly? no "Fixed #1234" but "Some random thing about #1234" is fine?

pnkfelix (Oct 17 2019 at 14:46, on Zulip):

I think the point @nikomatsakis was making above was that even "random thing about #1234" is not good

centril (Oct 17 2019 at 14:46, on Zulip):

@pnkfelix fwiw, I've find your messages from the past useful!

pnkfelix (Oct 17 2019 at 14:47, on Zulip):

okay well

pnkfelix (Oct 17 2019 at 14:47, on Zulip):

it seems like we should maybe discuss this on ticket?

pnkfelix (Oct 17 2019 at 14:47, on Zulip):

we can skip the Zoxc PR marked waiting-on-team

centril (Oct 17 2019 at 14:47, on Zulip):

fair

pnkfelix (Oct 17 2019 at 14:48, on Zulip):

for the nominated issues

pnkfelix (Oct 17 2019 at 14:48, on Zulip):

we have 4

pnkfelix (Oct 17 2019 at 14:48, on Zulip):

and I'm skipping the first one filed an hour ago

pnkfelix (Oct 17 2019 at 14:48, on Zulip):

nom: "Deferred ICEs (i.e. delay_span_bug) are not preserved by incremental." #65401

pnkfelix (Oct 17 2019 at 14:49, on Zulip):

I think @centril nominated this for prioiritzation

pnkfelix (Oct 17 2019 at 14:49, on Zulip):

I left it nominated though

pnkfelix (Oct 17 2019 at 14:49, on Zulip):

because the associated PR

pnkfelix (Oct 17 2019 at 14:49, on Zulip):

has an interesting problem

pnkfelix (Oct 17 2019 at 14:49, on Zulip):

PR #65470

pnkfelix (Oct 17 2019 at 14:49, on Zulip):

wants to know

pnkfelix (Oct 17 2019 at 14:49, on Zulip):

"how do I write a regression test for this?"

centril (Oct 17 2019 at 14:49, on Zulip):

I assumed @mw would follow up on that

pnkfelix (Oct 17 2019 at 14:49, on Zulip):

we don't expose anything analogous to #[rustc_error]

pnkfelix (Oct 17 2019 at 14:50, on Zulip):

for generating an ICE or delay_span_bug in a controlled manner

pnkfelix (Oct 17 2019 at 14:50, on Zulip):

any opinions or objections to suggesting that approach (solely for test authoring) ?

pnkfelix (Oct 17 2019 at 14:50, on Zulip):

or is that overkill?

oli (Oct 17 2019 at 14:51, on Zulip):

we have -Ztreat-err-as-bug

pnkfelix (Oct 17 2019 at 14:51, on Zulip):

(the only other approaches I can imagine are either 2. have no tests at all, or 3. use some pre-exisiting ICE and then update it each time the compiler gets fixed)

pnkfelix (Oct 17 2019 at 14:51, on Zulip):

ooooh

oli (Oct 17 2019 at 14:51, on Zulip):

we even have tests for the ICE it produces

pnkfelix (Oct 17 2019 at 14:51, on Zulip):

@oli that won't do a delay_span_bug though, right?

nikomatsakis (Oct 17 2019 at 14:51, on Zulip):

any opinions or objections to suggesting that approach (solely for test authoring) ?

I have no objection to that

oli (Oct 17 2019 at 14:51, on Zulip):

ah no

pnkfelix (Oct 17 2019 at 14:51, on Zulip):

we kind of need delay_span_bug here, I think, if I understand correctly

oli (Oct 17 2019 at 14:51, on Zulip):

right

pnkfelix (Oct 17 2019 at 14:51, on Zulip):

actually let me put up the tally.:)

centril (Oct 17 2019 at 14:51, on Zulip):

-Ztreat-err-as-bug ignores delay_span_bug making it into a true error?

oli (Oct 17 2019 at 14:51, on Zulip):

-Ztreat-warn-as-delay-span-bug

pnkfelix (Oct 17 2019 at 14:51, on Zulip):

any opinions or objections to suggesting that approach (solely for test authoring) ?

pnkfelix (Oct 17 2019 at 14:52, on Zulip):

-Ztreat-warn-as-delay-span-bug

heh heh heh

pnkfelix (Oct 17 2019 at 14:53, on Zulip):

-Ztreat-err-as-bug ignores delay_span_bug making it into a true error?

oh good point, I'd have to go review what happens in that scenario

pnkfelix (Oct 17 2019 at 14:53, on Zulip):

okay well I'll take point on this then

nikomatsakis (Oct 17 2019 at 14:53, on Zulip):

-Ztreat-err-as-bug ignores delay_span_bug making it into a true error?

(please don't alter this behavior, it's quite useful)

pnkfelix (Oct 17 2019 at 14:54, on Zulip):

nom: "rust-lld since 1.38 overlaps .text with .rodata for embedded arm target" #65391

nagisa (Oct 17 2019 at 14:55, on Zulip):

I still haven’t seen anything that would suggest there are no issues with the person’s linker script or some such.

pnkfelix (Oct 17 2019 at 14:55, on Zulip):

I nominated this because I wanted to know if there was a subteam we could push this off onto

pnkfelix (Oct 17 2019 at 14:55, on Zulip):

don't we have an embedded WG?

nikomatsakis (Oct 17 2019 at 14:56, on Zulip):

heh, we do, we could ping 'em

Mateusz Mikuła (Oct 17 2019 at 14:56, on Zulip):

nom: "rust-lld since 1.38 overlaps .text with .rodata for embedded arm target" #65391

Isn't that related to LLVM 9 upgrade?

nagisa (Oct 17 2019 at 14:56, on Zulip):

Yes.

centril (Oct 17 2019 at 14:56, on Zulip):

https://github.com/rust-embedded/wg/

pnkfelix (Oct 17 2019 at 14:57, on Zulip):

is that same as github's rust-lang/wg-embedded-resources?

pnkfelix (Oct 17 2019 at 14:57, on Zulip):

oh no

pnkfelix (Oct 17 2019 at 14:57, on Zulip):

very low on time

pnkfelix (Oct 17 2019 at 14:57, on Zulip):

sorry

pnkfelix (Oct 17 2019 at 14:57, on Zulip):

um

nikomatsakis (Oct 17 2019 at 14:57, on Zulip):

I pinged embedded folks

nikomatsakis (Oct 17 2019 at 14:57, on Zulip):

(the leads)

pnkfelix (Oct 17 2019 at 14:57, on Zulip):

well we were basically done with triage tstuff

pnkfelix (Oct 17 2019 at 14:57, on Zulip):

so WG checkings

oli (Oct 17 2019 at 14:58, on Zulip):

WG-mir-opt

pnkfelix (Oct 17 2019 at 14:58, on Zulip):

thanks @oli

pnkfelix (Oct 17 2019 at 14:58, on Zulip):

@Santiago Pastorino you said you could speak for WG-mega ?

pnkfelix (Oct 17 2019 at 14:58, on Zulip):

um I mean WG-meta

Santiago Pastorino (Oct 17 2019 at 14:59, on Zulip):

WG-mega sounds great btw ;)

Santiago Pastorino (Oct 17 2019 at 14:59, on Zulip):

Wg-meta

Inside Rust blog

As you've probably seen we now have an Inside Rust blog.
As the announcement says it's a great place for people to follow what's going on with Rust, so if you have any idea that may be worth blogging about please do so :). We can write about project updates, design discussions, technical aspects or any other thing you consider appropriate.

ICE breaker group & LLVM ICE breaker group

As you are probably aware we were helping to form a set of ICE breakers groups :). More info on what ICE-Breaker group is about here. Basically they aim to be an easy to join and low commitment group that can work on isolated and middle priority issues.

In particular we formed the LLVM ICE breaker group, more info here. With the goal of determining if a bug is a result of us generating invalid LLVM IR or LLVM misoptimizing.

Santiago Pastorino (Oct 17 2019 at 14:59, on Zulip):

@nikomatsakis if you want to amend something, do it live :)

pnkfelix (Oct 17 2019 at 14:59, on Zulip):

are there thoughts on what the next ICE breaker group(s) may be?

nikomatsakis (Oct 17 2019 at 14:59, on Zulip):

nope, that sounds about right

pnkfelix (Oct 17 2019 at 14:59, on Zulip):

or are you waiting to see how this one goes first?

nikomatsakis (Oct 17 2019 at 14:59, on Zulip):

I was going to ask for suggestions on that

nikomatsakis (Oct 17 2019 at 15:00, on Zulip):

the other thing is that I'm trying to move to forge.rust-lang.org as the consolidated place for documenting procedural things

nikomatsakis (Oct 17 2019 at 15:00, on Zulip):

so some of the "policy docs" from the compiler-team repo might move there...

Santiago Pastorino (Oct 17 2019 at 15:00, on Zulip):

I think it could be nice to see how one group work and improve it but unsure what @nikomatsakis was thinking :)

pnkfelix (Oct 17 2019 at 15:00, on Zulip):

before we do run out of time

pnkfelix (Oct 17 2019 at 15:00, on Zulip):

there was one last nominated issue

pnkfelix (Oct 17 2019 at 15:00, on Zulip):

that we should discuss

pnkfelix (Oct 17 2019 at 15:00, on Zulip):

nom: "linking of libtest failed" #64872

pnkfelix (Oct 17 2019 at 15:00, on Zulip):

specifically

pnkfelix (Oct 17 2019 at 15:01, on Zulip):

this is suspected to be a regression due to PR #64324 (which fixed #64319)

pnkfelix (Oct 17 2019 at 15:01, on Zulip):

(note well: I have not verified that suspicion)

pnkfelix (Oct 17 2019 at 15:01, on Zulip):

my question is this: in terms of evaluating relative risk

pnkfelix (Oct 17 2019 at 15:01, on Zulip):

are we better off immediately reverting PR #64324 (and thus reintroducing #64319)

pnkfelix (Oct 17 2019 at 15:02, on Zulip):

or just letting #64872 stand (and hope it gets resolved in some reasonable manner, eventually, without reverting #64324)

pnkfelix (Oct 17 2019 at 15:02, on Zulip):

my inclination, given that #64324 #64319 arises when you mix optimization levels amongst crates

pnkfelix (Oct 17 2019 at 15:02, on Zulip):

while #64872 arises without such mixing

pnkfelix (Oct 17 2019 at 15:02, on Zulip):

is that I think we should probably consider reverting PR #64324

pnkfelix (Oct 17 2019 at 15:03, on Zulip):

Any thoughts?

pnkfelix (Oct 17 2019 at 15:04, on Zulip):

(see also @mw 's semi-recent "vision for Rust 2020: Kill dylib")

nikomatsakis (Oct 17 2019 at 15:04, on Zulip):

hmm

centril (Oct 17 2019 at 15:04, on Zulip):

My first thought is that it would be a shame to reduce progress on "Project Kill dylib"

nikomatsakis (Oct 17 2019 at 15:04, on Zulip):

do we have any idea who will do that follow-up work?

centril (Oct 17 2019 at 15:04, on Zulip):

+ the PR had perf improvements we'd be reverting

pnkfelix (Oct 17 2019 at 15:05, on Zulip):

do we have any idea who will do that follow-up work?

the work of dealing with fallout after the hypothesized revert, you mean?

Vadim Petrochenkov (Oct 17 2019 at 15:05, on Zulip):

@mw 's semi-recent "vision for Rust 2020: Kill dylib"

Source?

pnkfelix (Oct 17 2019 at 15:05, on Zulip):

or the work of trying to investigate #64872 if we do not revert?

centril (Oct 17 2019 at 15:05, on Zulip):

@Vadim Petrochenkov previous meeting or the one before that I think

pnkfelix (Oct 17 2019 at 15:06, on Zulip):

@mw 's semi-recent "vision for Rust 2020: Kill dylib"

Source?

I'll see if I can find it. I think it was during a recent design meeting.

centril (Oct 17 2019 at 15:06, on Zulip):

(it would also be a shame to not make progress on cranelift)

pnkfelix (Oct 17 2019 at 15:06, on Zulip):

@mw 's semi-recent "vision for Rust 2020: Kill dylib"

Source?

found it: https://zulip-archive.rust-lang.org/131828tcompiler/10812designmeeting20190927.html#176752386

Vadim Petrochenkov (Oct 17 2019 at 15:07, on Zulip):

Thanks!

nikomatsakis (Oct 17 2019 at 15:07, on Zulip):

Any thoughts?

I thnk your logic makes sense, @pnkfelix; I'm mildly worried we'll revert but neither @Alex Crichton nor @mw have time to follow up -- although that applies equally if we don't revert

pnkfelix (Oct 17 2019 at 15:07, on Zulip):

how much time do we have before the decision really needs to be made?

pnkfelix (Oct 17 2019 at 15:07, on Zulip):

/me goes to find rust forge's release schedule

nikomatsakis (Oct 17 2019 at 15:07, on Zulip):

I also don't quite understand the conditions in which #64872 triggers

pnkfelix (Oct 17 2019 at 15:07, on Zulip):

we've got some time

pnkfelix (Oct 17 2019 at 15:08, on Zulip):

yeah I am still narrowing #64872 down

pnkfelix (Oct 17 2019 at 15:08, on Zulip):

just started that today

pnkfelix (Oct 17 2019 at 15:08, on Zulip):

so maybe I can spend this week looking at that

pnkfelix (Oct 17 2019 at 15:08, on Zulip):

and we can revisit this question at next weeks' triage meeting?

pnkfelix (Oct 17 2019 at 15:09, on Zulip):

Sound good?

nikomatsakis (Oct 17 2019 at 15:09, on Zulip):

seems good

pnkfelix (Oct 17 2019 at 15:09, on Zulip):

In any case, I've kept everyone here over time

pnkfelix (Oct 17 2019 at 15:09, on Zulip):

thanks to everyone in @T-compiler/meeting for coming!

Vadim Petrochenkov (Oct 17 2019 at 15:10, on Zulip):

One more announcement: I'll be minimally available in the next 3 months at least due to starting a new job next week.
I already changed jobs twice while working on Rust and it never stopped me entirely, but every time it brings some uncertainty.
I still hope to do reviews, and hope to finish the crate loader refactorings that are supposed to close known issues in that area (#64450, #56935, #55103, #56590).

nikomatsakis (Oct 17 2019 at 15:12, on Zulip):

I hope the new job works out great @Vadim Petrochenkov! Congratulations. :)

Mateusz Mikuła (Oct 17 2019 at 15:13, on Zulip):

:construction_worker: If you are a Windows GNU developer (aka mingw, I think), we could use help looking into this bug: " couldn't load codegen backend on windows-gnu" #61561

Didn't want to disrupt meeting but I can run builds if somebody has an idea about it.

centril (Oct 17 2019 at 15:14, on Zulip):

@Vadim Petrochenkov Congratz! -- (I'll try to send only the most important libsyntax PRs for you to review ^^)

Last update: Nov 20 2019 at 02:00UTC