Stream: t-compiler/meetings

Topic: [weekly meeting] 2020-10-08 #54818


Santiago Pastorino (Oct 07 2020 at 19:58, on Zulip):

Hi @T-compiler/meeting; the triage meeting will happen tomorrow at

Santiago Pastorino (Oct 07 2020 at 19:59, on Zulip):

WG-prioritization has done pre-triage in #t-compiler/wg-prioritization/alerts

Santiago Pastorino (Oct 07 2020 at 19:59, on Zulip):

@WG-prioritization has prepared the meeting agenda

Santiago Pastorino (Oct 07 2020 at 19:59, on Zulip):

We will have just one checkin this time from @WG-traits

Santiago Pastorino (Oct 07 2020 at 20:00, on Zulip):

@nikomatsakis do you have something you want to share about WG-traits?

Jack Huey (Oct 08 2020 at 00:05, on Zulip):

@Santiago Pastorino I will fill in some checkin text

Santiago Pastorino (Oct 08 2020 at 13:29, on Zulip):

Hi @T-compiler/meeting, triage meeting will be starting in ~ 30 minutes

Santiago Pastorino (Oct 08 2020 at 13:29, on Zulip):

Check out the meeting agenda

pnkfelix (Oct 08 2020 at 14:03, on Zulip):

sorry all, my web browser is going super slow for some reason

pnkfelix (Oct 08 2020 at 14:04, on Zulip):

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

pnkfelix (Oct 08 2020 at 14:04, on Zulip):

we will start off with 5 minutes for ...

Announcements

simulacrum (Oct 08 2020 at 14:04, on Zulip):
pnkfelix (Oct 08 2020 at 14:04, on Zulip):
pnkfelix (Oct 08 2020 at 14:05, on Zulip):
pnkfelix (Oct 08 2020 at 14:05, on Zulip):
pnkfelix (Oct 08 2020 at 14:05, on Zulip):
pnkfelix (Oct 08 2020 at 14:05, on Zulip):
pnkfelix (Oct 08 2020 at 14:06, on Zulip):
pnkfelix (Oct 08 2020 at 14:06, on Zulip):

WG checkins

@WG-traits checkin by @jackh726:

pnkfelix (Oct 08 2020 at 14:06, on Zulip):

We started sprint 4 of the year on Sept. 15.
rustc PRs:

pnkfelix (Oct 08 2020 at 14:07, on Zulip):

Chalk PRs:

pnkfelix (Oct 08 2020 at 14:08, on Zulip):

/me squints and wonders why Zulip keeps temporarily rendering the markdown before reverting to asterisks...

pnkfelix (Oct 08 2020 at 14:08, on Zulip):

ah, adding an extra newline fixed it.

pnkfelix (Oct 08 2020 at 14:09, on Zulip):

Some changes on the horizon:

pnkfelix (Oct 08 2020 at 14:09, on Zulip):

Also, about half of rustc tests pass in compare-mode=chalk; we're working on triaging these and making more pass.

pnkfelix (Oct 08 2020 at 14:10, on Zulip):

any more announcements?

pnkfelix (Oct 08 2020 at 14:11, on Zulip):

lets move along to beta nominations.

pnkfelix (Oct 08 2020 at 14:11, on Zulip):

Beta-nominations

T-compiler

pnkfelix (Oct 08 2020 at 14:11, on Zulip):

oops

pnkfelix (Oct 08 2020 at 14:11, on Zulip):
Wesley Wiser (Oct 08 2020 at 14:12, on Zulip):

We've had some bugs in this MIR opt recently and we'd just like to let it get some more exposure on nightly before it moves along the release train.

Santiago Pastorino (Oct 08 2020 at 14:12, on Zulip):

@Wesley Wiser I guess you meant to backport this one so the optimization doesn't turn on?

Wesley Wiser (Oct 08 2020 at 14:12, on Zulip):

Yes, exactly

Santiago Pastorino (Oct 08 2020 at 14:13, on Zulip):

just in case wanted to clarify that :)

pnkfelix (Oct 08 2020 at 14:13, on Zulip):

yeah this seems like an easy backport approved.

pnkfelix (Oct 08 2020 at 14:13, on Zulip):

so, backport approved.

pnkfelix (Oct 08 2020 at 14:13, on Zulip):
pnkfelix (Oct 08 2020 at 14:14, on Zulip):

hmm.

pnkfelix (Oct 08 2020 at 14:15, on Zulip):

I am sitting here musing about this problem

pnkfelix (Oct 08 2020 at 14:15, on Zulip):

about needing to keep the rustfmt up to date with the version of rust that's being deployed

pnkfelix (Oct 08 2020 at 14:15, on Zulip):

the other approach I could imagine would be to make rustfmt more liberal in what it accepts

pnkfelix (Oct 08 2020 at 14:15, on Zulip):

but I'm not in charge of the design of that tool. :)

nikomatsakis (Oct 08 2020 at 14:16, on Zulip):

I'm not sure I understand the problem you're suggesting

nikomatsakis (Oct 08 2020 at 14:16, on Zulip):

i.e., if new syntax is introduced?

pnkfelix (Oct 08 2020 at 14:16, on Zulip):

I'm saying that overall

pnkfelix (Oct 08 2020 at 14:16, on Zulip):

it sounds like the policy suggested here

pnkfelix (Oct 08 2020 at 14:16, on Zulip):

to upgrade rustfmt in time with syntax additions to rustc

pnkfelix (Oct 08 2020 at 14:17, on Zulip):

could potentially lead to us deploying versions of rustfmt that haven't been properly vetted

pnkfelix (Oct 08 2020 at 14:17, on Zulip):

and that it would be safer to not have a tight coupling

pnkfelix (Oct 08 2020 at 14:17, on Zulip):

but

pnkfelix (Oct 08 2020 at 14:17, on Zulip):

I also don't think rustfmt is necessarily a mission critical tool?

simulacrum (Oct 08 2020 at 14:17, on Zulip):

rustfmt is using libsyntax directly, so there's not much that can be done there I imagine

pnkfelix (Oct 08 2020 at 14:17, on Zulip):

except for the fact that certain repositories, like our own, might gate on using rustfmt for certain CI steps

nikomatsakis (Oct 08 2020 at 14:18, on Zulip):

pnkfelix said:

I also don't think rustfmt is necessarily a mission critical tool?

I don't agree with this, actually

pnkfelix (Oct 08 2020 at 14:18, on Zulip):

simulacrum said:

rustfmt is using libsyntax directly, so there's not much that can be done there I imagine

ah. is the failure described here a build failure of rustfmt itself?

nikomatsakis (Oct 08 2020 at 14:18, on Zulip):

I think it's an increasingly core part of people's workflows

nikomatsakis (Oct 08 2020 at 14:18, on Zulip):

( but I also think we should table this discussion, probably, as I doubt we're going to make changes )

pnkfelix (Oct 08 2020 at 14:18, on Zulip):

sure, that's true; I think my comment about CI integration alludes to that.

simulacrum (Oct 08 2020 at 14:19, on Zulip):

yes, tabling seems good. rustfmt will build just isn't able to run on new code

pnkfelix (Oct 08 2020 at 14:19, on Zulip):

anyway if it is a mission critical tool, that may provide all the more reason to look into a more decoupled architecture. Maybe.

pnkfelix (Oct 08 2020 at 14:19, on Zulip):

but yeah, we shouldn't have this conversation now.

pnkfelix (Oct 08 2020 at 14:19, on Zulip):

backport approved, in any case.

pnkfelix (Oct 08 2020 at 14:20, on Zulip):

libs-impl

T-rustdoc

pnkfelix (Oct 08 2020 at 14:20, on Zulip):

Stable-nominations

T-compiler

libs-impl

T-rustdoc

pnkfelix (Oct 08 2020 at 14:20, on Zulip):

(always a good thing to have zero stable nominations on release day!)

pnkfelix (Oct 08 2020 at 14:20, on Zulip):

PRs S-waiting-on-team

T-compiler

libs-impl

pnkfelix (Oct 08 2020 at 14:20, on Zulip):

Issues of Note

Short Summary

pnkfelix (Oct 08 2020 at 14:21, on Zulip):

P-critical

T-compiler

pnkfelix (Oct 08 2020 at 14:21, on Zulip):
pnkfelix (Oct 08 2020 at 14:22, on Zulip):

(we should cherry pick the different LLVM patch, right?)

pnkfelix (Oct 08 2020 at 14:22, on Zulip):

cc @Aaron Hill

pnkfelix (Oct 08 2020 at 14:22, on Zulip):

lets keep going; i think this sounds like it is under control.

pnkfelix (Oct 08 2020 at 14:23, on Zulip):

oh but before we move along

pnkfelix (Oct 08 2020 at 14:23, on Zulip):

I'd like to try to link to any zulip stream that is relevant to each particular issue

pnkfelix (Oct 08 2020 at 14:23, on Zulip):

to drive follow-up discussion there (and allow review of past discussion)

pnkfelix (Oct 08 2020 at 14:24, on Zulip):

nope I couldn't find any such zulip stream, apart from the one in the wg-prioritization related streams.

Santiago Pastorino (Oct 08 2020 at 14:24, on Zulip):

pnkfelix said:

(we should cherry pick the different LLVM patch, right?)

what do you mean by a different patch?

pnkfelix (Oct 08 2020 at 14:25, on Zulip):
Santiago Pastorino (Oct 08 2020 at 14:25, on Zulip):

ahh right, that one :)

Santiago Pastorino (Oct 08 2020 at 14:25, on Zulip):

so the one that is merged on LLVM

Santiago Pastorino (Oct 08 2020 at 14:25, on Zulip):

by different the text meant, different to the one we had that was originally provided by @Aaron Hill

pnkfelix (Oct 08 2020 at 14:25, on Zulip):

I'm assuming we haven't landed the first (unaccepted) patch that was autored by @Aaron Hill

Santiago Pastorino (Oct 08 2020 at 14:25, on Zulip):

I guess we didn't

pnkfelix (Oct 08 2020 at 14:26, on Zulip):

so if we're going to pick between them, I'd say pick the one that the LLVM dev's approved.

Santiago Pastorino (Oct 08 2020 at 14:26, on Zulip):

right, that's also what I meant

pnkfelix (Oct 08 2020 at 14:26, on Zulip):

anyway I suggest any follow-up discussion could go into #t-compiler/wg-llvm

pnkfelix (Oct 08 2020 at 14:26, on Zulip):

next

pnkfelix (Oct 08 2020 at 14:26, on Zulip):
Santiago Pastorino (Oct 08 2020 at 14:27, on Zulip):

potentially the same thing happens here, we may need to backport that patch

pnkfelix (Oct 08 2020 at 14:27, on Zulip):

Yes, so here again, I'd suggest we cherry-pick the LLVM patch

pnkfelix (Oct 08 2020 at 14:27, on Zulip):

and also that follow-up discussion can/should take place on #t-compiler/wg-llvm

pnkfelix (Oct 08 2020 at 14:28, on Zulip):

/me is wondering if, as a matter of policy, we should just open such new topics if they don't already exist, during the meeting itself?

pnkfelix (Oct 08 2020 at 14:28, on Zulip):

I guess I'd rather wait for actual conversation to happen

nikomatsakis (Oct 08 2020 at 14:28, on Zulip):

yeah

pnkfelix (Oct 08 2020 at 14:29, on Zulip):

(the only advantage to opening them ahead of time is the ability to immediately link them here, in the chat, which means it gets archived and potentially put into meeting notes.)

nikomatsakis (Oct 08 2020 at 14:29, on Zulip):

it'd be kind of nice if there were an easy to find topic for every issue or something but I guess that trying to open them with a bit would be .. unwise

pnkfelix (Oct 08 2020 at 14:29, on Zulip):

yeah. Its not hard to search

nikomatsakis (Oct 08 2020 at 14:29, on Zulip):

I worry about things where a topic gets organically created and then later there's a bot one or something

pnkfelix (Oct 08 2020 at 14:29, on Zulip):

especially if people put the issue number into the topic.

nikomatsakis (Oct 08 2020 at 14:29, on Zulip):

still, it'd be nice if we were better about linking between the two

pnkfelix (Oct 08 2020 at 14:30, on Zulip):

next

pnkfelix (Oct 08 2020 at 14:30, on Zulip):
Matthew Jasper (Oct 08 2020 at 14:30, on Zulip):

The next 3 are all regressions from #73905

pnkfelix (Oct 08 2020 at 14:31, on Zulip):

shall we discuss them all in tandem?

pnkfelix (Oct 08 2020 at 14:31, on Zulip):

let me post them all then

pnkfelix (Oct 08 2020 at 14:31, on Zulip):
Matthew Jasper (Oct 08 2020 at 14:32, on Zulip):

The type inference regression is expected, the method (operator) is actually ambiguous between two equally valid choices.

pnkfelix (Oct 08 2020 at 14:32, on Zulip):

@Matthew Jasper I take it you are well aware of all of these then. :smile:

nikomatsakis (Oct 08 2020 at 14:32, on Zulip):

hmm

Matthew Jasper (Oct 08 2020 at 14:33, on Zulip):

I have a good idea on what's happening with #77656 and I'm trying to find the best way to fix it. #77653 doesn't have a small repro ATM so I don't really know what's going on there.

pnkfelix (Oct 08 2020 at 14:34, on Zulip):

There is this question on rust#77638:

Can someone help me understand this? This fixed the problem:

diff pub fn checked_add<Dur: Duration>(self, duration: Dur) -> Option<Self> where Dur: FixedPoint, - Clock::T: TryFrom<Dur::T> + Clock::T: TryFrom<Dur::T> + ops::Div<Output=Clock::T>

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=55f8795c91867fec5550107d789a60f8

But that bound seems redundant because Clock::T: TimeInt and TimeInt: ops::Div<Output = Self>. Is the Self just any TimeInt and not necessarily the specific type?

nikomatsakis (Oct 08 2020 at 14:34, on Zulip):

This may be because of the code that gives preference to where clauses?

pnkfelix (Oct 08 2020 at 14:34, on Zulip):

/me is sad: zulip doesn't seem to support diff as a codeblock type?

nikomatsakis (Oct 08 2020 at 14:34, on Zulip):

yes it does...?

nikomatsakis (Oct 08 2020 at 14:34, on Zulip):
- foo
+ bar
LeSeulArtichaut (Oct 08 2020 at 14:34, on Zulip):

I though it does

Wesley Wiser (Oct 08 2020 at 14:35, on Zulip):

It might be because the code block is within a quotation.

pnkfelix (Oct 08 2020 at 14:35, on Zulip):

okay we'll file that with zulip

pnkfelix (Oct 08 2020 at 14:35, on Zulip):

anyway

nikomatsakis (Oct 08 2020 at 14:36, on Zulip):

@Matthew Jasper -- do you feel that #77638 is "working as intended"

nikomatsakis (Oct 08 2020 at 14:36, on Zulip):

It'd be nice to minimize the example more I think

pnkfelix (Oct 08 2020 at 14:37, on Zulip):

Div<Output = Self> does sound different from Div<Output=Clock::T>, at first glance to me ...

nikomatsakis (Oct 08 2020 at 14:37, on Zulip):

the playground link is good but it still has a lot of traits and things

nikomatsakis (Oct 08 2020 at 14:37, on Zulip):

I doubt they are all needed

pnkfelix (Oct 08 2020 at 14:37, on Zulip):

yep

pnkfelix (Oct 08 2020 at 14:37, on Zulip):

okay we don't need to get bogged down in this now

pnkfelix (Oct 08 2020 at 14:38, on Zulip):

the important thing is that @Matthew Jasper does seem like they're aware of this

nikomatsakis (Oct 08 2020 at 14:38, on Zulip):

I guess the question is whether @Matthew Jasper would like help in working on them

pnkfelix (Oct 08 2020 at 14:38, on Zulip):

true

pnkfelix (Oct 08 2020 at 14:39, on Zulip):

it does sound like @Matthew Jasper might want help reducing #77656 #77653 to an MCVE

Matthew Jasper (Oct 08 2020 at 14:39, on Zulip):

I think #77638 is indeed "working as intended" . There's already someone working on minimising #77653, which is the only thing that I would want help with at the moment.

pnkfelix (Oct 08 2020 at 14:40, on Zulip):

okay great

pnkfelix (Oct 08 2020 at 14:40, on Zulip):

it would be good to get feedback to the person who posted the question regarding #77638

Matthew Jasper (Oct 08 2020 at 14:40, on Zulip):

The #77656 example is already fine.

pnkfelix (Oct 08 2020 at 14:40, on Zulip):

if anyone wants to take a shot at that; that's a task that someone besides @Matthew Jasper could pick up, if they like

pnkfelix (Oct 08 2020 at 14:41, on Zulip):

that's all the P-critical T-compiler bugs

pnkfelix (Oct 08 2020 at 14:41, on Zulip):

libs-impl

T-rustdoc

pnkfelix (Oct 08 2020 at 14:41, on Zulip):

P-high regressions

P-high beta regressions

pnkfelix (Oct 08 2020 at 14:41, on Zulip):
nikomatsakis (Oct 08 2020 at 14:42, on Zulip):

Matthew Jasper said:

I think #77638 is indeed "working as intended" . There's already someone working on minimising #77653, which is the only thing that I would want help with at the moment.

(I don't want to talk about more in this meeting, but I'd like to understand why and have a canonical example/write-up. That is plausibly something I could try to do just for my own edification.) (EDIT: oh and I see @lqd actually had a more minimal example I missed)

pnkfelix (Oct 08 2020 at 14:43, on Zulip):

rust#76980 is getting very active investigation, even as we speak

pnkfelix (Oct 08 2020 at 14:44, on Zulip):

I'm not sure there's much for us to discuss here regarding #76980

pnkfelix (Oct 08 2020 at 14:44, on Zulip):

Unassigned P-high nightly regressions

pnkfelix (Oct 08 2020 at 14:45, on Zulip):

Performance logs

A quiet week. One rather large regression on a synthetic benchmark and a few
small improvements.

#77023 is an interesting case. It encoded an invariant about slice lengths as an assume intrinsic inside len function. It seems to have caused a small compile-time slowdown, but there was no improvement in check build performance (a proxy for generated code quality). In fact, the LLVM documentation specifically advises against overuse of the assume intrinsic in cases where the invariant is unlikely to be of much help to the optimizer. That seems to be the case here.

pnkfelix (Oct 08 2020 at 14:45, on Zulip):

Triage done by @ecstaticmorse.
Revision range: 6369a98ebdee8ce01510f5d4307ddb771c8cb0e5..ea7e131435a960d154e9a5d6a9297039574ffd7d

1 Regressions, 2 Improvements, 1 Mixed

1 of them in rollups

pnkfelix (Oct 08 2020 at 14:45, on Zulip):

Regressions

#77381 Rollup of 12 pull requests

pnkfelix (Oct 08 2020 at 14:46, on Zulip):

Improvements

#77257 Optimize IntRange::from_pat, then shrink ParamEnv

#77466 Re-land PR #71840 (Rework MIR drop tree lowering) #77466

pnkfelix (Oct 08 2020 at 14:46, on Zulip):

Mixed

#77023 Hint the maximum length permitted by invariant of slices

pnkfelix (Oct 08 2020 at 14:46, on Zulip):

Nags requiring follow up

nikomatsakis (Oct 08 2020 at 14:47, on Zulip):

what was the motivation for #77023? I guess i'll read the PR

pnkfelix (Oct 08 2020 at 14:47, on Zulip):

"The additional value range assertions allow some further elision of code branches, including overflow checks, especially in the presence of artithmetic on the indices."

nikomatsakis (Oct 08 2020 at 14:47, on Zulip):

in other words, from the paragraph above it sounds like maybe it's not actually helping and should be reverted

nikomatsakis (Oct 08 2020 at 14:47, on Zulip):

but I guess maybe there are specific examples where it helps?

pnkfelix (Oct 08 2020 at 14:48, on Zulip):

you mean this one: "This may have a performance impact, adding more code to a common method but allowing more optimization. I'm not quite sure, is the Rust side of const-prop strong enough to elide the irrelevant match branches?" ?

nikomatsakis (Oct 08 2020 at 14:48, on Zulip):

I see there are examples in the PR I guess

nikomatsakis (Oct 08 2020 at 14:48, on Zulip):

I meant:

nikomatsakis (Oct 08 2020 at 14:48, on Zulip):

pnkfelix said:

#77023 is an interesting case. It encoded an invariant about slice lengths as an assume intrinsic inside len function. It seems to have caused a small compile-time slowdown, but there was no improvement in check build performance (a proxy for generated code quality). In fact, the LLVM documentation specifically advises against overuse of the assume intrinsic in cases where the invariant is unlikely to be of much help to the optimizer. That seems to be the case here.

nikomatsakis (Oct 08 2020 at 14:48, on Zulip):

it seems like it's a code size optimization

nikomatsakis (Oct 08 2020 at 14:49, on Zulip):

allowing us to avoid panics from checked_add

nikomatsakis (Oct 08 2020 at 14:49, on Zulip):

in some cases

pnkfelix (Oct 08 2020 at 14:50, on Zulip):

okay so it sounds like we should revert this then.

pnkfelix (Oct 08 2020 at 14:51, on Zulip):

I'm going to assume we won't see push-back from @HeroicKatora , given that they themselves were unsure what the performance impact of this would be.

pnkfelix (Oct 08 2020 at 14:52, on Zulip):

(ah, I see; I think the original description on the PR reflects an earlier version of the code that didn't use the assume intrinsic, and I think that produced an even worse regression, based on the comments I see on the PR itself.)

pnkfelix (Oct 08 2020 at 14:52, on Zulip):

and also: it seems to me like there was a perf run on the first version of this, but not the second? @simulacrum does that sound right to you?

simulacrum (Oct 08 2020 at 14:52, on Zulip):

hm, perhaps

pnkfelix (Oct 08 2020 at 14:53, on Zulip):

("right" as in, did I accurately describe teh events?)

simulacrum (Oct 08 2020 at 14:53, on Zulip):

I will be honest that I sort of assumed this had good perf effects

simulacrum (Oct 08 2020 at 14:53, on Zulip):

I am fine with a revert though

pnkfelix (Oct 08 2020 at 14:53, on Zulip):

I can understand that assumption. :)

pnkfelix (Oct 08 2020 at 14:53, on Zulip):

okay lets revert it.

pnkfelix (Oct 08 2020 at 14:53, on Zulip):

Nominated Issues

T-compiler

pnkfelix (Oct 08 2020 at 14:53, on Zulip):
pnkfelix (Oct 08 2020 at 14:55, on Zulip):

do people have an opinion here?

nikomatsakis (Oct 08 2020 at 14:55, on Zulip):

pnkfelix said:

okay lets revert it.

(sorry, I was a bit distracted; I'm not sure if revert makes sense, personally)

nikomatsakis (Oct 08 2020 at 14:55, on Zulip):

I gues I'd want to dig a bit deeper into which things reverted and how strong the motivation in favor is

pnkfelix (Oct 08 2020 at 14:55, on Zulip):

@nikomatsakis because the regressions aren't that bad?

nikomatsakis (Oct 08 2020 at 14:55, on Zulip):

though I do feel the examples don't feel super persuasive

nikomatsakis (Oct 08 2020 at 14:56, on Zulip):

like it seems to be specific to "checked adds" of lengths, but I guess that's something that probably happens not infrequently?

nikomatsakis (Oct 08 2020 at 14:56, on Zulip):

I have to look more closely at what regressed and how much, I'm basically wondering if it's just synthetic things

pnkfelix (Oct 08 2020 at 14:56, on Zulip):

according to @ecstatic-morse 's summary

pnkfelix (Oct 08 2020 at 14:56, on Zulip):

its only synthetic stuff that improved

pnkfelix (Oct 08 2020 at 14:56, on Zulip):

and there were slowdowns across the board otherwise

nikomatsakis (Oct 08 2020 at 14:57, on Zulip):

ok, then I'm convinced I think

pnkfelix (Oct 08 2020 at 14:57, on Zulip):

its based on that summary that I figured we should revert

nikomatsakis (Oct 08 2020 at 14:57, on Zulip):

sorry

pnkfelix (Oct 08 2020 at 14:57, on Zulip):

as for rust#77586

pnkfelix (Oct 08 2020 at 14:57, on Zulip):

should we bubble this up to T-lang?

pnkfelix (Oct 08 2020 at 14:58, on Zulip):

I suspect its T-lang's call, not T-compiler's.

pnkfelix (Oct 08 2020 at 14:58, on Zulip):

what do you think, @nikomatsakis ?

nikomatsakis (Oct 08 2020 at 14:58, on Zulip):

/me looking

nikomatsakis (Oct 08 2020 at 14:58, on Zulip):

I was getting a :coffee:

pnkfelix (Oct 08 2020 at 14:58, on Zulip):

I'm going to tag it T-lang and move on

nikomatsakis (Oct 08 2020 at 14:59, on Zulip):

seems fair but we're probably going to want @Vadim Petrochenkov's input :)

nikomatsakis (Oct 08 2020 at 14:59, on Zulip):

ok I See it's already there

pnkfelix (Oct 08 2020 at 14:59, on Zulip):

sure but they wrote their input on the

pnkfelix (Oct 08 2020 at 14:59, on Zulip):

yes

nikomatsakis (Oct 08 2020 at 14:59, on Zulip):

yep t-lang

nikomatsakis (Oct 08 2020 at 14:59, on Zulip):

(side note: we should probably assign someone to prep before triage meeting to explain)

pnkfelix (Oct 08 2020 at 14:59, on Zulip):

libs-impl

pnkfelix (Oct 08 2020 at 15:00, on Zulip):

@nikomatsakis yeah I can do that I think.

pnkfelix (Oct 08 2020 at 15:00, on Zulip):

that is, I can prep

pnkfelix (Oct 08 2020 at 15:01, on Zulip):

oy, if only we had a Tier1 big-endian target

nikomatsakis (Oct 08 2020 at 15:01, on Zulip):

(have another mtg, have to go)

pnkfelix (Oct 08 2020 at 15:01, on Zulip):

that would "solve" so many problems

pnkfelix (Oct 08 2020 at 15:01, on Zulip):

(or rather, force us to solve them up front. :smile: )

pnkfelix (Oct 08 2020 at 15:02, on Zulip):

How are we going to address rust#77410

Wesley Wiser (Oct 08 2020 at 15:02, on Zulip):

It sounds to me like we need to report this upstream to gimili/backtrace/addr2line

Wesley Wiser (Oct 08 2020 at 15:03, on Zulip):

I'm assuming that hasn't happened since there's no linked bugs

pnkfelix (Oct 08 2020 at 15:04, on Zulip):

well we are out of time

pnkfelix (Oct 08 2020 at 15:04, on Zulip):

and honestly I'm not sure what exactly we can discuss there, besides seeing if anyone wants to take on the duty of investigating further and posting bugs upstream

pnkfelix (Oct 08 2020 at 15:05, on Zulip):

If someone does that, great. If no one does, then we'll just leave this nominated for discussion at next week's meeting.

pnkfelix (Oct 08 2020 at 15:05, on Zulip):

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

Santiago Pastorino (Oct 08 2020 at 15:06, on Zulip):

next week we will have checkins from @WG-async-foundations (cc @tmandry and @nikomatsakis) and @WG-diagnostics (cc @Esteban K├╝ber)

Santiago Pastorino (Oct 08 2020 at 15:07, on Zulip):

letting you all know with time so you can prepare your checkins if you have something to share

nagisa (Oct 08 2020 at 15:07, on Zulip):

I could try running some test suite on sparc, but in my memory running rustc on big endian platforms is a fairly clunky experience in the first place, sadly.

Santiago Pastorino (Oct 08 2020 at 15:07, on Zulip):

next week's agenda will be prepared here

apiraino (Oct 08 2020 at 15:11, on Zulip):

nagisa said:

I could try running some test suite on sparc, but in my memory running rustc on big endian platforms is a fairly clunky experience in the first place, sadly.

@nagisa perhaps we can reach out for someone (if any) closer to these Tier2 arch?

nagisa (Oct 08 2020 at 15:13, on Zulip):

I don't believe we have any T2 big endian targets. Aarch64 supports running big endian code but see https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.20meeting.5D.202020-10-01.20.2354818/near/211995359

cuviper (Oct 08 2020 at 15:33, on Zulip):

@nagisa these are all tier-2 big-endian: mips, mips64, powerpc, powerpc64, s390x, sparc64

nagisa (Oct 08 2020 at 15:33, on Zulip):

oh, welp.

nagisa (Oct 08 2020 at 15:34, on Zulip):

they definitely feel like t3 sometimes ^^

nagisa (Oct 08 2020 at 15:34, on Zulip):

I also misinterpreted the original message.

cuviper (Oct 08 2020 at 15:36, on Zulip):

tier-2 is a wide spectrum...

nagisa (Oct 08 2020 at 15:37, on Zulip):

Also @cuviper as far as mips and ppc are concerned, they are as hard to come by running in be mode as aarch64. ppc perhaps to a lesser extent but I personally haven't seen any ppc8 or later machines running big endian in my life.

nagisa (Oct 08 2020 at 15:38, on Zulip):

sparc being be only helps as you can be sure that once its sparc its also gonna be bigendian.

cuviper (Oct 08 2020 at 15:38, on Zulip):

RHEL7 is the last to support powerpc64 -- Fedora and RHEL8+ only support powerpc64le

cuviper (Oct 08 2020 at 15:39, on Zulip):

but s390x is here to stay

nagisa (Oct 08 2020 at 15:39, on Zulip):

yep, I don't have access to s390x. Wouldn't mind if IBM gave me some tho ^^

cuviper (Oct 08 2020 at 15:40, on Zulip):

even here at Red Hat (IBM subsidiary), s390x is in short supply

cuviper (Oct 08 2020 at 15:42, on Zulip):

mainframe computing is in a world of its own -- but at least it can still run Linux :)

Last update: Nov 25 2020 at 01:45UTC