Stream: t-compiler/meetings

Topic: [weekly meeting] 2020-06-11 #54818


Santiago Pastorino (Jun 10 2020 at 20:40, on Zulip):

Hi @T-compiler/meeting; the triage meeting will be starting in ~ 17 hours 20 minutes

Santiago Pastorino (Jun 10 2020 at 20:42, on Zulip):

The @WG-prioritization have done pre-triage in #t-compiler/wg-prioritization

Santiago Pastorino (Jun 10 2020 at 20:43, on Zulip):

@WG-prioritization have prepared the meeting agenda

Santiago Pastorino (Jun 10 2020 at 20:43, on Zulip):

We will have checkins from @WG-parallel-rustc and @WG-polonius

Santiago Pastorino (Jun 10 2020 at 20:44, on Zulip):

about @WG-parallel-rustc do we want to mark it as inactive on compiler-team cc @nikomatsakis @simulacrum

Santiago Pastorino (Jun 10 2020 at 20:45, on Zulip):

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

lqd (Jun 10 2020 at 20:48, on Zulip):

@Santiago Pastorino no there's not much to report this time (I didn't even realize that much time had passed since the last check-in :)

simulacrum (Jun 10 2020 at 20:57, on Zulip):

yeah we should mark parallel as inactive

Santiago Pastorino (Jun 11 2020 at 03:34, on Zulip):

given that parallel is inactive, next in list if Polymorphization, @davidtwco do you have something you want to share about it?

Santiago Pastorino (Jun 11 2020 at 03:37, on Zulip):

btw compiler-team#308, inactivated parallel and reactivated rfc 2229

davidtwco (Jun 11 2020 at 07:06, on Zulip):

I don’t have much to say - I’ve been rebasing the pull request for polymorphisation but have yet to spend more time on it than that. I’ll do some digging to better understand the impact that CGU partitioning is having on the performance and anything else I can think of.

Santiago Pastorino (Jun 11 2020 at 13:28, on Zulip):

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

Santiago Pastorino (Jun 11 2020 at 13:28, on Zulip):

Check out the meeting agenda

pnkfelix (Jun 11 2020 at 14:01, on Zulip):

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

pnkfelix (Jun 11 2020 at 14:01, on Zulip):

we will start off with 5 minutes for ...

Announcements

pnkfelix (Jun 11 2020 at 14:02, on Zulip):
pnkfelix (Jun 11 2020 at 14:03, on Zulip):

Note that I think there's an open question there about whether to add a src/ directory in each of those newly moved crates

pnkfelix (Jun 11 2020 at 14:04, on Zulip):

(the motivation being to have them match the "standard" crate layout. The main objection that I'm aware of is that doing so introduces an extra click on interfaces like github, which can be a real drag.)

pnkfelix (Jun 11 2020 at 14:04, on Zulip):
pnkfelix (Jun 11 2020 at 14:05, on Zulip):
pnkfelix (Jun 11 2020 at 14:05, on Zulip):
pnkfelix (Jun 11 2020 at 14:05, on Zulip):

/me squints at compiler-team#277. I really need to look at that one.

pnkfelix (Jun 11 2020 at 14:06, on Zulip):
pnkfelix (Jun 11 2020 at 14:07, on Zulip):

WG checkins

@WG-parallel-rustc is inactive.

@WG-polonius has nothing to share this time.

nikomatsakis (Jun 11 2020 at 14:07, on Zulip):

Ah, I hadn't noticed compiler-team#277, I need to look at that too

nikomatsakis (Jun 11 2020 at 14:07, on Zulip):

(sorry @cjgillot!)

eddyb (Jun 11 2020 at 14:07, on Zulip):

IIRC it should be more salsa-like ;)

nikomatsakis (Jun 11 2020 at 14:08, on Zulip):

yeah, i'm in favor of moving in that general direction

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

Great, let's talk about that over here: https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Decentralize.20queries.20compiler-team.23277/near/194545129

pnkfelix (Jun 11 2020 at 14:09, on Zulip):

but first ... beta-noms!

pnkfelix (Jun 11 2020 at 14:09, on Zulip):

Beta-nominations

T-compiler

pnkfelix (Jun 11 2020 at 14:09, on Zulip):

(why ... is there a box around that ...)

pnkfelix (Jun 11 2020 at 14:09, on Zulip):

link

pnkfelix (Jun 11 2020 at 14:09, on Zulip):

hmm

pnkfelix (Jun 11 2020 at 14:09, on Zulip):

I'll have to puzzle that out another time

pnkfelix (Jun 11 2020 at 14:10, on Zulip):

beta-nom 1/4: "normalize adt fields during structural match checking" #72897

- Beta fix for this P-critical issue

nagisa (Jun 11 2020 at 14:10, on Zulip):

a monospace link

pnkfelix (Jun 11 2020 at 14:11, on Zulip):

(that's very interesting. Is that standard UI elsewhere?)

pnkfelix (Jun 11 2020 at 14:11, on Zulip):

okay lets backport #72897

pnkfelix (Jun 11 2020 at 14:12, on Zulip):

beta-nom 2/4: "Revert pr 71840" #72989

- Beta fix for this P-critical issue by reverting this PR

eddyb (Jun 11 2020 at 14:12, on Zulip):

*presumably* **anything** __works__ (EDIT: nevermind...)

pnkfelix (Jun 11 2020 at 14:14, on Zulip):

okay, #72989 is beta-approved

pnkfelix (Jun 11 2020 at 14:14, on Zulip):

beta-nom 3/4: - "Fix link error with #[thread_local] introduced by #71192" #73065

- This PR is nominated but is not merged yet

Santiago Pastorino (Jun 11 2020 at 14:14, on Zulip):

@pnkfelix I've added this one but I don't think we should vote ?

Santiago Pastorino (Jun 11 2020 at 14:14, on Zulip):

is not merged yet

pnkfelix (Jun 11 2020 at 14:15, on Zulip):

I'm trying to remember the precedent here

nikomatsakis (Jun 11 2020 at 14:15, on Zulip):

Seems safe enough to me, modulo the fact that it's not merged yet

pnkfelix (Jun 11 2020 at 14:15, on Zulip):

I guess when its this early in the release cycle

nikomatsakis (Jun 11 2020 at 14:15, on Zulip):

I think we often wait to vote until it gets merged

pnkfelix (Jun 11 2020 at 14:15, on Zulip):

we can leave it nominated for next week

pnkfelix (Jun 11 2020 at 14:15, on Zulip):

yeah, its only when we're getting close to a release that we'll "vote early"

pnkfelix (Jun 11 2020 at 14:15, on Zulip):

okay moving on then

Santiago Pastorino (Jun 11 2020 at 14:15, on Zulip):

nikomatsakis said:

I think we often wait to vote until it gets merged

I'd say given that we are early we should wait, just in case the code in the PR changes or something happens :)

pnkfelix (Jun 11 2020 at 14:16, on Zulip):

beta-nom 4/4: "Revert #71956" #73153

- This fixes on beta this P-critical issue by reverting this PR

pnkfelix (Jun 11 2020 at 14:16, on Zulip):

gotta love those double drops

pnkfelix (Jun 11 2020 at 14:16, on Zulip):

:drop: :drop:

pnkfelix (Jun 11 2020 at 14:17, on Zulip):

okay beta-approved then.

pnkfelix (Jun 11 2020 at 14:17, on Zulip):

No beta nominations this time for libs-impl and T-rustdoc.

pnkfelix (Jun 11 2020 at 14:18, on Zulip):

(oh yeah, did I already mention that we're going to be in charge of beta-approvals for T-rustdoc? I don't remember if that was discussed/announced more broadly than amongst @WG-prioritization ...)

pnkfelix (Jun 11 2020 at 14:18, on Zulip):

Stable-nominations

No stable nominations this time for T-compiler, libs-impl and T-rustdoc.

Santiago Pastorino (Jun 11 2020 at 14:18, on Zulip):

yeah, we've discussed that and that's why we're adding those

pnkfelix (Jun 11 2020 at 14:18, on Zulip):
simulacrum (Jun 11 2020 at 14:19, on Zulip):

there's also the cargo PR (linked from that one)

simulacrum (Jun 11 2020 at 14:19, on Zulip):

none of these are really T-compiler (backtrace is sort of T-libs-impl)

pnkfelix (Jun 11 2020 at 14:19, on Zulip):

PR #73238 is a collection of version bumps of crates (rustfmt and backtrace-sys) as well as a cargo PR

pnkfelix (Jun 11 2020 at 14:19, on Zulip):

so yeah, that's more a general awareness thing

pnkfelix (Jun 11 2020 at 14:20, on Zulip):

next up

pnkfelix (Jun 11 2020 at 14:20, on Zulip):

PR's S-waiting-on-team

T-compiler S-waiting-on-team

pnkfelix (Jun 11 2020 at 14:20, on Zulip):
nikomatsakis (Jun 11 2020 at 14:20, on Zulip):

it seemed like there was some significant questions raised here

pnkfelix (Jun 11 2020 at 14:21, on Zulip):

here is associated zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/--extern-location.20to.20specify.20where.20an.20--ex.20compiler-team.23303/near/200014262

pnkfelix (Jun 11 2020 at 14:22, on Zulip):

@Santiago Pastorino what is best entity to talk to about automatically adding such links to the MCP issues? @T-compiler/WG-meta ?

pnkfelix (Jun 11 2020 at 14:23, on Zulip):

in any case, there's nothing to actually do here right now, besides seeing if anyone wants to second the proposal (which was filed 4 days ago, so its still relatively young)

nikomatsakis (Jun 11 2020 at 14:24, on Zulip):

I believe @simulacrum said that it was hard to get the link for some reason

pnkfelix (Jun 11 2020 at 14:24, on Zulip):

okay. Maybe I'll try to look more into this later

simulacrum (Jun 11 2020 at 14:24, on Zulip):

yeah I've been unable to track down a way to get zulip to give it to us

simulacrum (Jun 11 2020 at 14:24, on Zulip):

(I should probably bug zulip devs)

pnkfelix (Jun 11 2020 at 14:24, on Zulip):

I would have thought if there exist zulip bots, then one of those could do it

pnkfelix (Jun 11 2020 at 14:24, on Zulip):

but then again, I also discovered this morning that the Zulip app provides no way to get a URL for a topic or message in a topic

pnkfelix (Jun 11 2020 at 14:25, on Zulip):

the mobile app, that is, on IOS at least

pnkfelix (Jun 11 2020 at 14:25, on Zulip):

(speaking of things to bug Zulip devs about...)

pnkfelix (Jun 11 2020 at 14:25, on Zulip):

anyway, next PR S-waiting-on-team ...

pnkfelix (Jun 11 2020 at 14:25, on Zulip):
nikomatsakis (Jun 11 2020 at 14:26, on Zulip):

that can probably be un-nominated

Santiago Pastorino (Jun 11 2020 at 14:26, on Zulip):

we could talk after the meeting, maybe we can do something manually

nikomatsakis (Jun 11 2020 at 14:26, on Zulip):

the MCP is seconded'd

pnkfelix (Jun 11 2020 at 14:26, on Zulip):

yeah its been seconded

pnkfelix (Jun 11 2020 at 14:26, on Zulip):

though its still technically waiting-on-team, no?

pnkfelix (Jun 11 2020 at 14:26, on Zulip):

oh but yes, the I-nominated can be removed I think

LeSeulArtichaut (Jun 11 2020 at 14:26, on Zulip):

Should it be waiting-on-fcp instead?

pnkfelix (Jun 11 2020 at 14:27, on Zulip):

I think it can be left as waiting-on-team until the MCP is done?

pnkfelix (Jun 11 2020 at 14:27, on Zulip):

I guess it depends on what waiting-on-fcp is meant to denote

pnkfelix (Jun 11 2020 at 14:27, on Zulip):

I would have interpreted waiting-on-fcp as being about an fcp on the PR or issue itself

pnkfelix (Jun 11 2020 at 14:28, on Zulip):

and so I'd worry about it being confusing for on-lookers

pnkfelix (Jun 11 2020 at 14:28, on Zulip):

in any case, I think we can move along here

pnkfelix (Jun 11 2020 at 14:28, on Zulip):

Issues of Note

Short Summary

There is 1 less P-critical issues and 2 more P-high issue in comparison with last week.

pnkfelix (Jun 11 2020 at 14:29, on Zulip):

I think one of the two P-high issues is actually a downgrade of the P-critical issue to P-high; does that sound accurate @Santiago Pastorino ?

pnkfelix (Jun 11 2020 at 14:29, on Zulip):

(is it useful to keep track of that separately? Or is it just noise?)

Santiago Pastorino (Jun 11 2020 at 14:29, on Zulip):

pnkfelix said:

I think one of the two P-high issues is actually a downgrade of the P-critical issue to P-high; does that sound accurate Santiago Pastorino ?

yes

nikomatsakis (Jun 11 2020 at 14:30, on Zulip):

The P-criticial issue:

Double Drop on Rust beta #73137

pnkfelix (Jun 11 2020 at 14:30, on Zulip):

P-critical

Santiago Pastorino (Jun 11 2020 at 14:30, on Zulip):

pnkfelix said:

(is it useful to keep track of that separately? Or is it just noise?)

unsure ...

nikomatsakis (Jun 11 2020 at 14:30, on Zulip):

sounds vaguely like the thing that @ecstatic-morse fixed via revert?

nikomatsakis (Jun 11 2020 at 14:30, on Zulip):

(oh, I see in the comments that indeed that is correct)

pnkfelix (Jun 11 2020 at 14:30, on Zulip):

yes, I think it specifically is discussed in the following items in the agenda

pnkfelix (Jun 11 2020 at 14:31, on Zulip):

the P-critical issue that was downgraded to P-high is different, its the one that I made a revert PR for

pnkfelix (Jun 11 2020 at 14:31, on Zulip):

we'll see them both right now. :slight_smile:

pnkfelix (Jun 11 2020 at 14:31, on Zulip):
pnkfelix (Jun 11 2020 at 14:32, on Zulip):

hmm, so if both of those are still marked as P-critical, maybe my understanding above was incorrect

Santiago Pastorino (Jun 11 2020 at 14:32, on Zulip):

I guess we should just change them to P-high and continue but if we want to keep track of those maybe we need some way to do that?

pnkfelix (Jun 11 2020 at 14:32, on Zulip):

well

pnkfelix (Jun 11 2020 at 14:33, on Zulip):

there's one reason to leave them at P-critical

pnkfelix (Jun 11 2020 at 14:33, on Zulip):

if the revert PR's haven't been backported yet

pnkfelix (Jun 11 2020 at 14:33, on Zulip):

and they are stable-to-beta regressions at this point

pnkfelix (Jun 11 2020 at 14:33, on Zulip):

(which I think they both are, even though #72470 is not marked as such)

Santiago Pastorino (Jun 11 2020 at 14:33, on Zulip):

well yeah, but those should be beta/stable nominated so they are tracked

pnkfelix (Jun 11 2020 at 14:34, on Zulip):

I guess its open-to-debate about whether its worth leaving such things at P-critical

simulacrum (Jun 11 2020 at 14:34, on Zulip):

IMO we should aggressively de-P-critical

pnkfelix (Jun 11 2020 at 14:35, on Zulip):

(I think it makes sense, in terms of ensuring we pay attention to potential release blockers.)

pnkfelix (Jun 11 2020 at 14:35, on Zulip):

I would certainly de-P-critical after the beta-backports land

pnkfelix (Jun 11 2020 at 14:35, on Zulip):

for cases like #72470 which might remain open but demoted in priority, at least

Santiago Pastorino (Jun 11 2020 at 14:35, on Zulip):

shouldn't we mark the PRs then as beta/stable-nominated and mark those as P-critical ?

Santiago Pastorino (Jun 11 2020 at 14:36, on Zulip):

I guess that would be easier to understand

pnkfelix (Jun 11 2020 at 14:36, on Zulip):

hmm

simulacrum (Jun 11 2020 at 14:36, on Zulip):

beta backports... don't really make sense as being prioritized

simulacrum (Jun 11 2020 at 14:36, on Zulip):

like, they'll happen eventually but they do so in a rollup generally which includes everything accepted at that time

pnkfelix (Jun 11 2020 at 14:36, on Zulip):

@simulacrum you mean because we generalize don't prioritize any PR's formally?

simulacrum (Jun 11 2020 at 14:36, on Zulip):

well, sure, but in this case even more so

pnkfelix (Jun 11 2020 at 14:36, on Zulip):

oh you just mean in terms of workflow, there's no need?

simulacrum (Jun 11 2020 at 14:37, on Zulip):

since there's not even "review" that needs to happen

Santiago Pastorino (Jun 11 2020 at 14:37, on Zulip):

simulacrum said:

like, they'll happen eventually but they do so in a rollup generally which includes everything accepted at that time

yep, that's also why I would just change the priority, because we will get to those anyway

pnkfelix (Jun 11 2020 at 14:37, on Zulip):

As long as the bugs get fixed in time, I don't care

Santiago Pastorino (Jun 11 2020 at 14:37, on Zulip):

agreed :+1:, I'm also fine with whatever :)

pnkfelix (Jun 11 2020 at 14:37, on Zulip):

I can definitely understand a concern that we might let the set of P-critical bugs blow up

pnkfelix (Jun 11 2020 at 14:37, on Zulip):

and then we end up in the same situation we were in with P-high

pnkfelix (Jun 11 2020 at 14:38, on Zulip):

so sure, these P-critical things are well-in-hand

pnkfelix (Jun 11 2020 at 14:38, on Zulip):

and therefore probably can be safely deprioritized at this point

pnkfelix (Jun 11 2020 at 14:38, on Zulip):

in any csae

pnkfelix (Jun 11 2020 at 14:38, on Zulip):

there's one last P-critical bug to discuss

pnkfelix (Jun 11 2020 at 14:38, on Zulip):
pnkfelix (Jun 11 2020 at 14:39, on Zulip):

hmm. Do we not run miri on the output of mir-optimized form?

pnkfelix (Jun 11 2020 at 14:40, on Zulip):

just curious, if this bug was injected by a MIR optimization, why it didn't replicate under miri

Wesley Wiser (Jun 11 2020 at 14:40, on Zulip):

This is caused by a MIR-opt we switched on in the last dev-cycle that just hit beta. I'm planning to submit a beta-backport PR that switches this off again within the next 24hours while also pursuing the real fix on nightly.

pnkfelix (Jun 11 2020 at 14:40, on Zulip):

(is it a deliberate design choice that miri is meant to run on the initially generated MIR, not optimized MIR?)

Wesley Wiser (Jun 11 2020 at 14:40, on Zulip):

It's a mis-optimization of the MIR and miri consumes optimized MIR so it doesn't catch it I guess?

pnkfelix (Jun 11 2020 at 14:41, on Zulip):

also, should I subscribe RalfJ to this stream? :)

lcnr (Jun 11 2020 at 14:41, on Zulip):

Doesn't miri run on unoptimized mir to detect undefined behavior

lcnr (Jun 11 2020 at 14:41, on Zulip):

which might get removed by mir optimizations?

Wesley Wiser (Jun 11 2020 at 14:41, on Zulip):

Oh sorry

pnkfelix (Jun 11 2020 at 14:41, on Zulip):

Wesley Wiser said:

It's a mis-optimization of the MIR and miri consumes optimized MIR so it doesn't catch it I guess?

but that's my point: if its a result of a mir-optimization being incorrect, then I would have thought miri would catch it?

Wesley Wiser (Jun 11 2020 at 14:42, on Zulip):

Yeah, not sure

pnkfelix (Jun 11 2020 at 14:42, on Zulip):

UI

pnkfelix (Jun 11 2020 at 14:42, on Zulip):

I like @lcnr 's explanation

pnkfelix (Jun 11 2020 at 14:42, on Zulip):

anyway thanks @Wesley Wiser for looking into this!

pnkfelix (Jun 11 2020 at 14:43, on Zulip):

Unassigned P-high regressions

No unassigned P-high regressions this time.

pnkfelix (Jun 11 2020 at 14:43, on Zulip):

Performance logs

Triage done by njn

Regressions:

Improvements:

nikomatsakis (Jun 11 2020 at 14:44, on Zulip):

hmm

nikomatsakis (Jun 11 2020 at 14:45, on Zulip):

how much was the perf regr from the rollup?

nikomatsakis (Jun 11 2020 at 14:45, on Zulip):

found the link

Wesley Wiser (Jun 11 2020 at 14:45, on Zulip):

(It's the (instructions) link above :slight_smile: )

nikomatsakis (Jun 11 2020 at 14:45, on Zulip):

ah :)

nikomatsakis (Jun 11 2020 at 14:45, on Zulip):

I interpreted that as "here are some instructions for how to reproduce" or something

pnkfelix (Jun 11 2020 at 14:46, on Zulip):

cranelift-codegen-opt observed -4.7%

pnkfelix (Jun 11 2020 at 14:46, on Zulip):

based on working hypothesis, it could be because of my revert PR #72989

pnkfelix (Jun 11 2020 at 14:47, on Zulip):

since the PR it reverts, (PR #71840), had some small-sounding optimizations in it

pnkfelix (Jun 11 2020 at 14:48, on Zulip):

PR #71840 itself did have a perf run associated with it

pnkfelix (Jun 11 2020 at 14:48, on Zulip):

let me see if that had a similar gain on cranelift-codegen-opt

pnkfelix (Jun 11 2020 at 14:48, on Zulip):

it did not

pnkfelix (Jun 11 2020 at 14:48, on Zulip):

hmm

pnkfelix (Jun 11 2020 at 14:49, on Zulip):

well

pnkfelix (Jun 11 2020 at 14:49, on Zulip):

I don't think we should revert the revert

nikomatsakis (Jun 11 2020 at 14:49, on Zulip):

Yeah

pnkfelix (Jun 11 2020 at 14:49, on Zulip):

this performance hit doesn't justify reinjecting the bug

nikomatsakis (Jun 11 2020 at 14:49, on Zulip):

We don't know that's the cause, also?

pnkfelix (Jun 11 2020 at 14:50, on Zulip):

but it may motivate investigating: 1. Is this the cause, and 2. if so, is there a way to fix PR #71840 to be non-buggy and re-land it...

pnkfelix (Jun 11 2020 at 14:50, on Zulip):

but also, the perf hit here... doesn't seem that bad?

pnkfelix (Jun 11 2020 at 14:51, on Zulip):

@Nicholas Nethercote themself said that script-servo-opt should be ignored as too noisy in its runs. So cranelift-codegen-opt seems like the main crate that was hit

nikomatsakis (Jun 11 2020 at 14:51, on Zulip):

it's not that bad

pnkfelix (Jun 11 2020 at 14:51, on Zulip):

I think we should let this be for now

pnkfelix (Jun 11 2020 at 14:51, on Zulip):

next up

pnkfelix (Jun 11 2020 at 14:52, on Zulip):

Nominated Issues

T-compiler I-nominated

pnkfelix (Jun 11 2020 at 14:52, on Zulip):

nom 1/3: "Backtraces don't work during ICE" #71060

pnkfelix (Jun 11 2020 at 14:53, on Zulip):

From alex's comment:

Ok I've whipped up https://github.com/rust-lang/backtrace-rs/pull/345 which I believe works at least for the gimli-symbolize feature. This does not affect libstd and transitively means it, with no other changes, will continue to not help the compiler itself (e.g. ICEs). Fixing ICEs can be done a few different ways:

pnkfelix (Jun 11 2020 at 14:53, on Zulip):

should we consider making compiler use backtrace crate itself?

pnkfelix (Jun 11 2020 at 14:54, on Zulip):

or should we make the stdlib backtrace functionality more robust?

pnkfelix (Jun 11 2020 at 14:54, on Zulip):

back when we weren't libs-impl, I would have said "obviously we should do the option of making the compiler use backtrace crate"

pnkfelix (Jun 11 2020 at 14:54, on Zulip):

but now I guess the decision is more nuanced.

simulacrum (Jun 11 2020 at 14:54, on Zulip):

hm do we care that much about specifically ICE backtraces working on windows-gnu? Is that a common platform to have "unique" ICEs on?

simulacrum (Jun 11 2020 at 14:55, on Zulip):

but IIRC the std-using-backtrace is somewhat hard, so I wouldn't block on that personally

pnkfelix (Jun 11 2020 at 14:56, on Zulip):

I would guess that given the platforms uncommonness, its all the more important to have working backtraces, because that helps us (maybe?) diagnose bugs without replicating them locally?

simulacrum (Jun 11 2020 at 14:56, on Zulip):

hm perhaps

nikomatsakis (Jun 11 2020 at 14:56, on Zulip):

there seems to be a fair amount of conversation on rust-lang/backtrace-rs#328

pnkfelix (Jun 11 2020 at 14:56, on Zulip):

What do other people think about that assertion, from the viewpoint of maintaining the compiler itself?

simulacrum (Jun 11 2020 at 14:56, on Zulip):

seems like using backtrace in the compiler with gimli should be pretty easy

pnkfelix (Jun 11 2020 at 14:56, on Zulip):

what is gimli ?

nikomatsakis (Jun 11 2020 at 14:56, on Zulip):

I don't really have a strong opinion about this, but I think that having the compiler use backtrace, if it's easy, seems ok as a crutch.

simulacrum (Jun 11 2020 at 14:57, on Zulip):

oh, it's the rust replacement for libbacktrace

Wesley Wiser (Jun 11 2020 at 14:57, on Zulip):

The person who asked for the nomination had this to say:

Reason for nomination:
Rustc ICE backtraces are totally broken on windows-gnu (Tier 1) platform.
This not only makes life harder for people developing Rust using windows-gnu toolchain but also makes backtraces provided by the users completely useless (example here #73114).
Is there anybody who knows enough about Windows unwinding enough to assist here? Or in the other case could you announce something like "call for help"?

pnkfelix (Jun 11 2020 at 14:57, on Zulip):

is this something that our new windows WG can help with?

pnkfelix (Jun 11 2020 at 14:58, on Zulip):

or is it too in the weeds for them?

pnkfelix (Jun 11 2020 at 14:58, on Zulip):

oh I want to make sure we hit the other nominated issues before time is up

Wesley Wiser (Jun 11 2020 at 14:58, on Zulip):

It couldn't hurt to ping them

pnkfelix (Jun 11 2020 at 14:58, on Zulip):
nikomatsakis (Jun 11 2020 at 14:58, on Zulip):

They were already pinged :)

pnkfelix (Jun 11 2020 at 14:58, on Zulip):

ah thanks @nikomatsakis

pnkfelix (Jun 11 2020 at 14:59, on Zulip):

there was already an MCP for #72709

pnkfelix (Jun 11 2020 at 14:59, on Zulip):

oh yeah we in fact said "lets remove the nominated label", didn't we?

pnkfelix (Jun 11 2020 at 14:59, on Zulip):

heh

pnkfelix (Jun 11 2020 at 14:59, on Zulip):

okay

simulacrum (Jun 11 2020 at 14:59, on Zulip):

yeah we should probably just land this

pnkfelix (Jun 11 2020 at 14:59, on Zulip):

last up

pnkfelix (Jun 11 2020 at 14:59, on Zulip):

libs-impl I-nominated

pnkfelix (Jun 11 2020 at 14:59, on Zulip):
nikomatsakis (Jun 11 2020 at 15:00, on Zulip):

seems serious :)

nikomatsakis (Jun 11 2020 at 15:00, on Zulip):

it also seems like this comment kind of nails down the problem, which is some kind of interaction having to do w/ a specialized impl

pnkfelix (Jun 11 2020 at 15:00, on Zulip):

There's discussion on issue #68536 on ways to fix it

pnkfelix (Jun 11 2020 at 15:01, on Zulip):

seems like its "just a bug", which we should indeed try to fix

pnkfelix (Jun 11 2020 at 15:01, on Zulip):

I suspect the hardest thing is to properly evaluate chance of regressions

pnkfelix (Jun 11 2020 at 15:02, on Zulip):

okay so now that's we've touched on those

pnkfelix (Jun 11 2020 at 15:02, on Zulip):

back to #71060 for a sec

pnkfelix (Jun 11 2020 at 15:02, on Zulip):

Does anyone want to take point on this?

pnkfelix (Jun 11 2020 at 15:02, on Zulip):

/me just got Windows dual-booting going yesterday; I might be willing to poke at it

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

but I'm definitely not an expert

pnkfelix (Jun 11 2020 at 15:04, on Zulip):

nikomatsakis said:

I don't really have a strong opinion about this, but I think that having the compiler use backtrace, if it's easy, seems ok as a crutch.

Right now I think I'd opt to do this.

pnkfelix (Jun 11 2020 at 15:04, on Zulip):

if for no other reason than "it seems the simplest thing to do, to make our own lives easier, in the short term."

nikomatsakis (Jun 11 2020 at 15:04, on Zulip):

agreed

pnkfelix (Jun 11 2020 at 15:04, on Zulip):

is this decision worthy of an MCP ?

pnkfelix (Jun 11 2020 at 15:05, on Zulip):

anyway our time is up

pnkfelix (Jun 11 2020 at 15:05, on Zulip):

thank you to everyone in @T-compiler/meeting for attending! This was great!

pnkfelix (Jun 11 2020 at 15:05, on Zulip):

stay safe, stay well! :mask:

Last update: Nov 25 2020 at 02:45UTC