Stream: t-compiler

Topic: weekly meeting 2020-04-23 #54818


Santiago Pastorino (Apr 22 2020 at 18:01, on Zulip):

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

Santiago Pastorino (Apr 22 2020 at 18:02, on Zulip):

The @WG-prioritization will be doing pre-triage in #t-compiler/wg-prioritization > pre-meeting triage 2020-04-23 #54818

Santiago Pastorino (Apr 22 2020 at 18:03, on Zulip):

we are supposed to have checkins from @WG-parallel-rustc and @WG-polonius

Santiago Pastorino (Apr 22 2020 at 18:04, on Zulip):

@simulacrum @nikomatsakis I don't think there's stuff going on about parallel, right?

simulacrum (Apr 22 2020 at 18:04, on Zulip):

not right this minute

Santiago Pastorino (Apr 22 2020 at 18:04, on Zulip):

@lqd is there something to share about polonius?

lqd (Apr 22 2020 at 18:05, on Zulip):

@Santiago Pastorino I very likely won't be able to attend the meeting, but I can provide an update :)

lqd (Apr 22 2020 at 18:06, on Zulip):

I'll prepare that now

Santiago Pastorino (Apr 22 2020 at 18:08, on Zulip):

we are preparing the agenda here

lqd (Apr 22 2020 at 19:19, on Zulip):

@Santiago Pastorino here's the update we have for you :)

The Polonius WG has many threads of ongoing work but our strategy is still to first achieve completeness/correctness to match rustc's
existing NLL analyses.

Towards that goal, we have:
- landed universal region errors in both polonius and rustc a while back; (and we've kept working on computing these
errors in all of the polonius variants, but that's a piece of work more related to performance than completeness)
- and we are currently working towards one of the last missing pieces, computing move errors:
part of this work has landed in polonius itself
already, but we haven't yet done the rustc counterpart -- polonius will compute move errors, but rustc doesn't
emit those just yet, instead of the ones it computes on its own.
(That also means that this part of the work has not been fully tested yet and we expect to iterate on this)
- after that, some interaction with chalk will be needed to handle subtyping involving higher-ranked types, which is the
last big piece of work remaining (but mostly on the chalk side, rather than polonius)

- We have worked towards fixing the 2 OOM errors happening in rustc tests under `-Z polonius`: the cause is known and we have
a tentative fix for it but no PRs yet as it currently moves the OOMs from rustc to polonius, and that will be taken care of
while finishing up the move errors work.

- On a more administrative note: most of the WG members don't have a lot of time to dedicate to it, so we're trying to
organize differently. The weekly meeting has been postponed in favor of a more periodical model (a small scale All Hands),
where we instead gather for a few mornings/days once every few months to achieve bigger pieces of work together.
We've done one of these already, and were hoping to have another one soon-ish.
lqd (Apr 22 2020 at 19:22, on Zulip):

(if there are any questions though, I'll make sure to reply as I'm finished with work, but of course Niko will be there)

Santiago Pastorino (Apr 23 2020 at 13:41, on Zulip):

Hi @T-compiler/meeting, our meeting starts in 19 minutes, you can check out the agenda here

pnkfelix (Apr 23 2020 at 13:54, on Zulip):

lqd said:

(if there are any questions though, I'll make sure to reply as I'm finished with work, but of course Niko will be there)

(in fact Niko is absent today and tomorrow. but someone will answer your questions ... eventually...)

eddyb (Apr 23 2020 at 13:58, on Zulip):

I've also been kind of absent but I'll try to be here today. PM me for anything urgent, I won't get to GH notifications until next week I don't think

pnkfelix (Apr 23 2020 at 14:02, on Zulip):

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

pnkfelix (Apr 23 2020 at 14:02, on Zulip):

We'll start off with five minutes for ...

pnkfelix (Apr 23 2020 at 14:02, on Zulip):

Announcements

pnkfelix (Apr 23 2020 at 14:02, on Zulip):
pnkfelix (Apr 23 2020 at 14:03, on Zulip):
pnkfelix (Apr 23 2020 at 14:03, on Zulip):
simulacrum (Apr 23 2020 at 14:03, on Zulip):
pnkfelix (Apr 23 2020 at 14:04, on Zulip):
pnkfelix (Apr 23 2020 at 14:05, on Zulip):

If you have feedback or objections on any of the above, or would like to second one or volunteer to be the reviewer, then please leave comments on the relevant issue

pnkfelix (Apr 23 2020 at 14:05, on Zulip):

(or in the associated zulip topic under #t-compiler/major changes )

simulacrum (Apr 23 2020 at 14:05, on Zulip):

(remember @rustbot seconded on the github thread is the way to second)

eddyb (Apr 23 2020 at 14:05, on Zulip):

the only thing I'd like to point out is that we should have a standard naming scheme :P

eddyb (Apr 23 2020 at 14:06, on Zulip):

(RFCs have had this problem for a while, we just don't look at PR titles for them a lot listed like that)

pnkfelix (Apr 23 2020 at 14:06, on Zulip):

time to make a meta MCP!

pnkfelix (Apr 23 2020 at 14:07, on Zulip):

Its certainly something we can try to do for the agenda itself, but it would make sense to also do it consistently on the issue titles themselves

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

okay so lets move along then

pnkfelix (Apr 23 2020 at 14:09, on Zulip):

Normally on a release day we wouldn't have any beta nominations, but today is exceptional in so many respects...

pnkfelix (Apr 23 2020 at 14:09, on Zulip):

namely, we have a beta-nom: - "[beta] fix failing const validation" #71441

pnkfelix (Apr 23 2020 at 14:09, on Zulip):

this is not a backport; it is a revert

pnkfelix (Apr 23 2020 at 14:09, on Zulip):

is @RalfJ here? I'm curious why we don't just go ahead and revert on master too?

pnkfelix (Apr 23 2020 at 14:10, on Zulip):

rather than let beta and master diverge so much?

Santiago Pastorino (Apr 23 2020 at 14:10, on Zulip):

he has mentioned on the issue that a proper fix for master is being cooked

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

but given the time constraints I guess he thought would be safer to revert for beta instead of risking too much ?

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

yeah, but, ... so what?

eddyb (Apr 23 2020 at 14:11, on Zulip):

oh heh this is const-prop again

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

What i mean is: we could still revert on master

eddyb (Apr 23 2020 at 14:11, on Zulip):

this is for post-release beta, right?

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

and reland the original PR along with its fixes

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

@eddyb that's my understanding, yes. As in, not something that is going to end up in the release

eddyb (Apr 23 2020 at 14:12, on Zulip):

then yeah let's land the revert on master then backport it to beta

eddyb (Apr 23 2020 at 14:12, on Zulip):

also it's tiny so it won't hurt anything to do the revert

Santiago Pastorino (Apr 23 2020 at 14:12, on Zulip):

yeah, makes sense

pnkfelix (Apr 23 2020 at 14:12, on Zulip):

I agree with @eddyb here. Without more explicit explanation of why not to revert on master, I think that is the way to go

eddyb (Apr 23 2020 at 14:13, on Zulip):

maybe I should go through const-prop and do an in-depth review, although it would've been helpful to do this before all the ICEs it caused :P

simulacrum (Apr 23 2020 at 14:13, on Zulip):

We can approve the backport today though, right? Doesn't seem like it makes sense to wait on that

eddyb (Apr 23 2020 at 14:13, on Zulip):

but I have to say, if rvalue.needs_subst() { looks very suspicious :P

pnkfelix (Apr 23 2020 at 14:13, on Zulip):

(A troubling aspect to this is that the PR itself is failing for some reason; its suspected to be spurious failures, but @RalfJ mentioned something about how all three builders failed in the reattempt

pnkfelix (Apr 23 2020 at 14:13, on Zulip):

@simulacrum I also think we can approve the backport today too

pnkfelix (Apr 23 2020 at 14:13, on Zulip):

I'm just saying we should land the revert on master as well

simulacrum (Apr 23 2020 at 14:13, on Zulip):

build failure is definitely not related to pr

simulacrum (Apr 23 2020 at 14:14, on Zulip):

yes, I would agree with that (presuming there's not a pr fixing master properly in the same timeframe as we can prepare a revert, I guess)

pnkfelix (Apr 23 2020 at 14:14, on Zulip):

Okay seems like no one present is going to object. I can prepare a revert on master to match what @RalfJ did in PR #71441.

pnkfelix (Apr 23 2020 at 14:14, on Zulip):

lets move on then

pnkfelix (Apr 23 2020 at 14:15, on Zulip):

there are no stable backport nominations

pnkfelix (Apr 23 2020 at 14:15, on Zulip):

There are two T-compiler PR's marked S-waiting-on-team

pnkfelix (Apr 23 2020 at 14:15, on Zulip):

waiting 1/2: "Add Option to Force Unwind Tables" #69984

pnkfelix (Apr 23 2020 at 14:16, on Zulip):

(status: FCP finished, disposition merge.) So this is just a general heads up to everyone

pnkfelix (Apr 23 2020 at 14:16, on Zulip):

waiting 2/2: "Remove -Z no-landing-pads flag" #70175

pnkfelix (Apr 23 2020 at 14:16, on Zulip):

(status: FCP finished, disposition merge.) So the same deal here.

pnkfelix (Apr 23 2020 at 14:16, on Zulip):

And that takes us to what I think will be the bulk of today's meeting: The "Issues of Note"

pnkfelix (Apr 23 2020 at 14:17, on Zulip):

Short Summary

eddyb (Apr 23 2020 at 14:17, on Zulip):

nice

Wesley Wiser (Apr 23 2020 at 14:17, on Zulip):

The P-critical issue has a pr waiting to merge (thanks @oli!)

pnkfelix (Apr 23 2020 at 14:17, on Zulip):

(thank's to @WG-prioritization for putting that summary together, as well as the whole agenda for today)

pnkfelix (Apr 23 2020 at 14:18, on Zulip):

right

pnkfelix (Apr 23 2020 at 14:18, on Zulip):

There is only one thing I think we might discuss regarding the P-critical issue

pnkfelix (Apr 23 2020 at 14:18, on Zulip):

which is in the agenda:

pnkfelix (Apr 23 2020 at 14:18, on Zulip):

- This is P-critical but is not going to be included in 1.43.0. P-critical means that it potentially blocks the release and this time it didn't block it.
- Should this one be beta-nominated after the nightly to beta promotion happens? (If PR #71078 lands before promotion then point is moot.)

pnkfelix (Apr 23 2020 at 14:19, on Zulip):

@simulacrum the nightly to beta promotion has already happened, right? Otherwise we wouldn't have had that previous discussion of @RalfJ 's revert PR?

simulacrum (Apr 23 2020 at 14:19, on Zulip):

yes

eddyb (Apr 23 2020 at 14:20, on Zulip):

this also means stable-to-stable regressions were stable-to-beta days ago?

pnkfelix (Apr 23 2020 at 14:20, on Zulip):

I don't know if we've updated the stable-to-beta regressions to be stable-to-stable already

pnkfelix (Apr 23 2020 at 14:20, on Zulip):

that might only happen after the release itself...?

Santiago Pastorino (Apr 23 2020 at 14:20, on Zulip):

pnkfelix said:

Short Summary

one thing that I wanted to note about this is that we are consistenly taking the P-high count down, which is great :). Keep fixing stuff :).

eddyb (Apr 23 2020 at 14:21, on Zulip):

that is, are the 24 unprioritized ones left over from the past 6 weeks?

eddyb (Apr 23 2020 at 14:21, on Zulip):

I could just open one and see :P

pnkfelix (Apr 23 2020 at 14:21, on Zulip):

pnkfelix said:

that might only happen after the release itself...?

(and I don't think you'd want to update the stable-to-nightly labels to be stable-to-beta until after you've taken care of updating the stable-to-beta ones to be stable-to-stable...)

simulacrum (Apr 23 2020 at 14:22, on Zulip):

we haven't yet automated stable-to* regression label switching, I don't know if we've done that manually. I've never done it in the past but it has presumably "magically" happened thanks to some hardworking triagers

pnkfelix (Apr 23 2020 at 14:22, on Zulip):

eddyb said:

that is, are the 24 unprioritized ones left over from the past 6 weeks?

I think we tend to be pretty good at prioiritizing all stable-to-beta and stable-to-nightly regressions

eddyb (Apr 23 2020 at 14:22, on Zulip):

ah that explains it, thanks!

pnkfelix (Apr 23 2020 at 14:22, on Zulip):

so I was assuming that all the unprioritized stable-to-stable regressions are not recent injections

Santiago Pastorino (Apr 23 2020 at 14:23, on Zulip):

yeah those are not recent, just 4 of them are from this year and just 1 of those T-compiler

pnkfelix (Apr 23 2020 at 14:23, on Zulip):

Anyway, regarding PR #71078, I think my attitude there is that I will beta nominate it, but we do not need to discuss its backport this week

pnkfelix (Apr 23 2020 at 14:24, on Zulip):

that's the only P-critical bug

pnkfelix (Apr 23 2020 at 14:24, on Zulip):

next up:

pnkfelix (Apr 23 2020 at 14:24, on Zulip):

Unassigned P-high regressions

pnkfelix (Apr 23 2020 at 14:25, on Zulip):

injected by PR #70452 according to bisection

pnkfelix (Apr 23 2020 at 14:25, on Zulip):

@eddyb do you want to look at this one?

eddyb (Apr 23 2020 at 14:26, on Zulip):

huh, I would've expected crater to find all such bugs

pnkfelix (Apr 23 2020 at 14:26, on Zulip):

there were a lot of intersecting requirements in the MCVE

Santiago Pastorino (Apr 23 2020 at 14:26, on Zulip):

@eddyb if you need help I can take a look at it and ask you questions if it's fine to you

pnkfelix (Apr 23 2020 at 14:26, on Zulip):

anyway I'll assign to @eddyb for now; if you have too much on your plate, @eddyb , let me know and we can work on reassigning

eddyb (Apr 23 2020 at 14:27, on Zulip):

I have nothing on my plate until I open GH notifications again :P

eddyb (Apr 23 2020 at 14:27, on Zulip):

@Santiago Pastorino thanks, that might be the best way to deal with this quickly

eddyb (Apr 23 2020 at 14:27, on Zulip):

/me goes to write a comment on the issue

pnkfelix (Apr 23 2020 at 14:28, on Zulip):

okay, we have three nominated issues on the agenda

Santiago Pastorino (Apr 23 2020 at 14:28, on Zulip):

eddyb said:

Santiago Pastorino thanks, that might be the best way to deal with this quickly

:+1:, feel free to assign to me then

pnkfelix (Apr 23 2020 at 14:28, on Zulip):

nom 1/3: "unsized_locals fails to uphold alignment requirements" #71416

- We need to discuss about a possible solution for this one.

oli (Apr 23 2020 at 14:29, on Zulip):

cc @RalfJ ^

pnkfelix (Apr 23 2020 at 14:29, on Zulip):

I like this remark from @RalfJ : "Unlike the other unsound features, this is one where we don't even have a plan for how to soundly implement it. Not sure how much I like keeping that around."

Santiago Pastorino (Apr 23 2020 at 14:30, on Zulip):

so, I guess the most interested people in discussing this are @RalfJ and @nikomatsakis but given they are not around I guess we could also leave this nomination up for next meeting and try to have @RalfJ around?

pnkfelix (Apr 23 2020 at 14:31, on Zulip):

and to clarify, I think this is the big issue (from a comment from niko): "part of the challenge here is that the alignment of a dyn Value is totally unknown -- it's not like we can conservatively align to 64 bytes or something."

eddyb (Apr 23 2020 at 14:31, on Zulip):

leaving a comment now

nagisa (Apr 23 2020 at 14:31, on Zulip):

unsized_locals is unstable, right?

pnkfelix (Apr 23 2020 at 14:31, on Zulip):

@nagisa that's right, this is all under a feature gate

pnkfelix (Apr 23 2020 at 14:31, on Zulip):

There is concurrent discussion in the issue of splitting it into two separate feature-gates

pnkfelix (Apr 23 2020 at 14:32, on Zulip):

so that we could distinguish the part we actually know how to implement from the other nonsense

pnkfelix (Apr 23 2020 at 14:32, on Zulip):

@eddyb can you dynamically query a dyn Value for its alignment?

eddyb (Apr 23 2020 at 14:32, on Zulip):

I'm surprised we landed the Box<dyn FnOnce()> change w/o a separate feature gate

pnkfelix (Apr 23 2020 at 14:32, on Zulip):

or is that info not in the vtable?

eddyb (Apr 23 2020 at 14:32, on Zulip):

@pnkfelix ofc, IIRC you even implemented the correct field offset logic that uses dynamic alignment :P

eddyb (Apr 23 2020 at 14:32, on Zulip):

but also, align_of_val is a thing

pnkfelix (Apr 23 2020 at 14:33, on Zulip):

hell if I remember that

oli (Apr 23 2020 at 14:33, on Zulip):

pnkfelix said:

can you dynamically query a dyn Value for its alignment?

yes, but the LLVM alloca can't take dynamic alignment

pnkfelix (Apr 23 2020 at 14:33, on Zulip):

so its not like we can't fall back on using that, right?

nagisa (Apr 23 2020 at 14:33, on Zulip):

eddyb said:

I'm surprised we landed the Box<dyn FnOnce()> change w/o a separate feature gate

If you captured a highly aligned variable, wouldn’t the bug in question make it potentially misaligned?

pnkfelix (Apr 23 2020 at 14:33, on Zulip):

right, we cannot use a fast alloca path

eddyb (Apr 23 2020 at 14:33, on Zulip):

anyway left a comment

eddyb (Apr 23 2020 at 14:33, on Zulip):

@nagisa there are 0 memcpys of the dyn FnOnce() left now

pnkfelix (Apr 23 2020 at 14:33, on Zulip):

okay, @eddyb left a comment that basically got to what I was thinking of but couldn't express directly

oli (Apr 23 2020 at 14:33, on Zulip):

oh, but we can alloca a size + align allocation and manually align

eddyb (Apr 23 2020 at 14:34, on Zulip):

that's literally what I wrote in my comment, yes :P

pnkfelix (Apr 23 2020 at 14:34, on Zulip):

well, literally off by one

oli (Apr 23 2020 at 14:34, on Zulip):

XD

pnkfelix (Apr 23 2020 at 14:34, on Zulip):

:lol:

pnkfelix (Apr 23 2020 at 14:34, on Zulip):

anyway that's great, glad to get some attention on this

pnkfelix (Apr 23 2020 at 14:35, on Zulip):

(I do think it would make sense to divide up the feature gate here, so that we separate the more experimental stuff from the more established stuff)

pnkfelix (Apr 23 2020 at 14:35, on Zulip):

but I also think we can move along

nagisa (Apr 23 2020 at 14:35, on Zulip):

I could make the assert fail in stable

pnkfelix (Apr 23 2020 at 14:35, on Zulip):

nom 2/3: "Debuginfo tests are not running" #47163

- According to @jonas-schievink, we have not been able to run these tests for over 2 years. There are some PRs by @tromey. It's not clear if #71428 fixes this problem entirely or partially.

nagisa (Apr 23 2020 at 14:35, on Zulip):

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d6f0aa4af7af2fa82670dcf0958b5199

eddyb (Apr 23 2020 at 14:36, on Zulip):

oh noes not the debuginfo tests

pnkfelix (Apr 23 2020 at 14:36, on Zulip):

ah @nagisa what did you do

pnkfelix (Apr 23 2020 at 14:36, on Zulip):

/me looks

eddyb (Apr 23 2020 at 14:36, on Zulip):

@nagisa but it's fixed on nightly

nagisa (Apr 23 2020 at 14:37, on Zulip):

Ah good then, never mind me then

pnkfelix (Apr 23 2020 at 14:37, on Zulip):

oh right /me looks at first line of #71416 again, sees reference to PR #71170

pnkfelix (Apr 23 2020 at 14:37, on Zulip):

so, back to debuginfo tests

eddyb (Apr 23 2020 at 14:38, on Zulip):

@nagisa the problems remaining are that the sound thing is not under its own stricter feature-gate (so that core/alloc/std can be kept away from the general feature) and that the general feature is still unsound

eddyb (Apr 23 2020 at 14:39, on Zulip):

so I run both gdb and lldb debuginfo tests locally

eddyb (Apr 23 2020 at 14:39, on Zulip):

my build command removes one of the tests which crashes lldb

nagisa (Apr 23 2020 at 14:39, on Zulip):

I never managed to run gdb/lldb tests locally

eddyb (Apr 23 2020 at 14:40, on Zulip):

the gdb tests were broken for a long time I believe, until my system gdb was new enough, or something else happened

eddyb (Apr 23 2020 at 14:40, on Zulip):

I use locally-built lldb (i.e. via config.toml) which means I have to run a patchelf command to fix a relative RPATH in a python .so, which is broken for some reason, every single time lldb gets rebuilt

pnkfelix (Apr 23 2020 at 14:41, on Zulip):

@eddyb what does this imply for trying to run these debuginfo tests on CI?

eddyb (Apr 23 2020 at 14:41, on Zulip):

I made sure all of this worked locally for MIR debuginfo work, since I didn't trust myself to not break debuginfo :P

pnkfelix (Apr 23 2020 at 14:41, on Zulip):

(which is what I assume is the real point of issue #47163)

eddyb (Apr 23 2020 at 14:42, on Zulip):

if we don't build lldb on CI already, we would need to. we should see what slowdown that imposes

eddyb (Apr 23 2020 at 14:42, on Zulip):

cc @simulacrum @Pietro Albini

nagisa (Apr 23 2020 at 14:42, on Zulip):

The debuginfo tests work and run on CI, this is how most of us get those tests actually run if we end up changing something and don’t test it locally.

eddyb (Apr 23 2020 at 14:42, on Zulip):

for GDB, we need to make sure we can get a compatible version

eddyb (Apr 23 2020 at 14:42, on Zulip):

@nagisa wait so what is the issue about?

eddyb (Apr 23 2020 at 14:42, on Zulip):

anymore, I mean

eddyb (Apr 23 2020 at 14:42, on Zulip):

as opposed to when it was originally opened

nagisa (Apr 23 2020 at 14:42, on Zulip):

about being able to run them locally, no?

nagisa (Apr 23 2020 at 14:43, on Zulip):

ah, tromey is saying that we have ignored/commented out tests

pnkfelix (Apr 23 2020 at 14:43, on Zulip):

Hmm I thought it was about the tests that had been disabled

nagisa (Apr 23 2020 at 14:43, on Zulip):

but if they don’t work on CI, they can’t work locally either, no?

pnkfelix (Apr 23 2020 at 14:43, on Zulip):

maybe there are two distinct issues that we need to follow up and perhaps should file distinct tickets for

simulacrum (Apr 23 2020 at 14:43, on Zulip):

I personally feel like this is mostly an issue of someone figuring out what needs to be installed for the tests to work -- I think a more interesting question here might be "what should we support?"

eddyb (Apr 23 2020 at 14:43, on Zulip):

some of the builders are running ancient CentOS or something

simulacrum (Apr 23 2020 at 14:44, on Zulip):

only the dist builders run ancient CentOS, test builders should be on recent-ish ubuntu lts I think (and we can bump that without major issues)

pnkfelix (Apr 23 2020 at 14:44, on Zulip):

since tromey posed this question, lets maybe quickly look at it here: What version(s) of gdb do we need to support? And how should we go about doing so?

eddyb (Apr 23 2020 at 14:44, on Zulip):

I think the problem was that the output changes

pnkfelix (Apr 23 2020 at 14:44, on Zulip):

Realistically we can only "support" versions that we have available on CI

pnkfelix (Apr 23 2020 at 14:45, on Zulip):

@eddyb okay, but we could hypothetically deal with that, right?

nagisa (Apr 23 2020 at 14:45, on Zulip):

One limiting factor for the range of versions we support is the dwarf version (4) we emit

pnkfelix (Apr 23 2020 at 14:45, on Zulip):

I mean, we already have to deal with lldb vs gdb output, right?

eddyb (Apr 23 2020 at 14:45, on Zulip):

yeah but when that was brought up before, nobody seemed to want to have even more outputs

pnkfelix (Apr 23 2020 at 14:45, on Zulip):

fair

eddyb (Apr 23 2020 at 14:45, on Zulip):

maybe if we made them like UI tests and blessable

simulacrum (Apr 23 2020 at 14:45, on Zulip):

I think it's mostly a matter of being pretty annoying to update locally even if they're blessable

simulacrum (Apr 23 2020 at 14:46, on Zulip):

(since you need to go get lots of gdb versions)

simulacrum (Apr 23 2020 at 14:46, on Zulip):

and e.g. on macos gdb installation is a pain since you need to sign it

pnkfelix (Apr 23 2020 at 14:46, on Zulip):

yeah I used to build it locally and it was indeed a pain

eddyb (Apr 23 2020 at 14:46, on Zulip):

they rarely ever change, though. hmpf

eddyb (Apr 23 2020 at 14:46, on Zulip):

yeah I don't know

pnkfelix (Apr 23 2020 at 14:46, on Zulip):

so realistically then

simulacrum (Apr 23 2020 at 14:46, on Zulip):

I'm not sure what is in the wild either

pnkfelix (Apr 23 2020 at 14:47, on Zulip):

what should we do?

eddyb (Apr 23 2020 at 14:47, on Zulip):

anyway, I don't get failures with GDB 9.1 locally but I don't know which tests run via GDB

simulacrum (Apr 23 2020 at 14:47, on Zulip):

e.g. maybe we can just say "We only test whatever is in latest ubuntu lts"

eddyb (Apr 23 2020 at 14:47, on Zulip):

i.e. I might just be succeeding because of ignored tests and not realizing

pnkfelix (Apr 23 2020 at 14:47, on Zulip):

would it be possible

pnkfelix (Apr 23 2020 at 14:47, on Zulip):

to test other versions of gdb

eddyb (Apr 23 2020 at 14:47, on Zulip):

one way to find out would probably be to make -Cdebuginfo do nothing in rustc :P

pnkfelix (Apr 23 2020 at 14:47, on Zulip):

without inspecting the output?

pnkfelix (Apr 23 2020 at 14:47, on Zulip):

maybe that's nuts

eddyb (Apr 23 2020 at 14:48, on Zulip):

no, it's not, you'd just e.g. build field access expressions

pnkfelix (Apr 23 2020 at 14:48, on Zulip):

I guess I'm just thinking of something like making sure that the debugger doesn't crash before the program gets to the expected point(s)

eddyb (Apr 23 2020 at 14:48, on Zulip):

heh have we ever crashed debuggers :P?

nagisa (Apr 23 2020 at 14:48, on Zulip):

Maybe the concept of having debugger tests (as opposed to debug info tests) is flawed in the first placE?

pnkfelix (Apr 23 2020 at 14:48, on Zulip):

@eddyb can you say more of what you are thinking?

eddyb (Apr 23 2020 at 14:48, on Zulip):

@pnkfelix so the problem is how e.g. tuples are pretty-printed by the debugger

pnkfelix (Apr 23 2020 at 14:49, on Zulip):

in terms of how it would help to build field access expressions? Woludjthat normalize the output?

eddyb (Apr 23 2020 at 14:49, on Zulip):

you can just print each field instead of the whole tuple

eddyb (Apr 23 2020 at 14:49, on Zulip):

(in the debugger)

pnkfelix (Apr 23 2020 at 14:49, on Zulip):

yes okay, you are indeed suggesting normalization of the output

pnkfelix (Apr 23 2020 at 14:49, on Zulip):

I'd be cool with that, personally

pnkfelix (Apr 23 2020 at 14:49, on Zulip):

and then the testing of the pretty-printing of more complicated types would be restricted to just one version of GDB ?

pnkfelix (Apr 23 2020 at 14:49, on Zulip):

this sounds like a MCP, to be honest

eddyb (Apr 23 2020 at 14:50, on Zulip):

what @nagisa is proposing makes a lot more sense, OTOH

pnkfelix (Apr 23 2020 at 14:50, on Zulip):

nagisa said:

Maybe the concept of having debugger tests (as opposed to debug info tests) is flawed in the first placE?

So you think the answer may instead me to use some tool (perhaps homegrown) to inspect the DWARF we generate?

eddyb (Apr 23 2020 at 14:51, on Zulip):

LLVM has a tool, for example

pnkfelix (Apr 23 2020 at 14:51, on Zulip):

I'm okay with that idea too. I think it would also be a MCP, but a worthwhile one

eddyb (Apr 23 2020 at 14:51, on Zulip):

having looked at the DWARF standard in the past few months, I'm much more in favor of that approach

pnkfelix (Apr 23 2020 at 14:51, on Zulip):

Okay, this was productive, but lets move on to the last nominated issue

eddyb (Apr 23 2020 at 14:51, on Zulip):

we'd want to normalize addresses somehow but that's about it

pnkfelix (Apr 23 2020 at 14:51, on Zulip):

nom 3/3 "Rename mir::Rvalue to Op." #70928

- We discussed this one last week. It would be good to mention that the discussion keeps going and Zulip may be a good place for it.

eddyb (Apr 23 2020 at 14:52, on Zulip):

I haven't seen most of the recent discussion

pnkfelix (Apr 23 2020 at 14:52, on Zulip):

So yeah, I kind of want to close this PR, but the discussion is moving forward

pnkfelix (Apr 23 2020 at 14:52, on Zulip):

I just don't think github is a great place for this kind of discussion ...

pnkfelix (Apr 23 2020 at 14:52, on Zulip):

(I'm happy to be overruled)

eddyb (Apr 23 2020 at 14:52, on Zulip):

GitHub Discussions, OTOH

pnkfelix (Apr 23 2020 at 14:53, on Zulip):

My personal suggestion was to open a Zulip topic right now, post a link to the Zulip discussion, and then close the PR

pnkfelix (Apr 23 2020 at 14:53, on Zulip):

but if people would prefer e.g. internals.rlo

pnkfelix (Apr 23 2020 at 14:53, on Zulip):

I'm open to that

eddyb (Apr 23 2020 at 14:53, on Zulip):

anyway closing the PR is fine especially since we'd want to do the rename from scratch anyway when we pick an alternative

pnkfelix (Apr 23 2020 at 14:54, on Zulip):

Right; the main thing is, as you (@eddyb ) pointed out long ago, is that we would need to decide where to hold the bikeshed

pnkfelix (Apr 23 2020 at 14:54, on Zulip):

yet another option would be to post this as an MCP

pnkfelix (Apr 23 2020 at 14:54, on Zulip):

but I suspect that is overkill?

Esteban Küber (Apr 23 2020 at 14:54, on Zulip):

Meta-bikeshed discussion

pnkfelix (Apr 23 2020 at 14:54, on Zulip):

I'll just open a Zulip

eddyb (Apr 23 2020 at 14:55, on Zulip):

maybe ping everyone who had an opinion on-thread?

pnkfelix (Apr 23 2020 at 14:55, on Zulip):

fresh thread: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/To.20what.20to.20rename.20mir.3A.3ARvalue.20.2370928/near/195072985

eddyb (Apr 23 2020 at 14:55, on Zulip):

(I'm mostly saying that because w/o a ping I'll likely never see that thread again :P)

pnkfelix (Apr 23 2020 at 14:55, on Zulip):

eddyb said:

maybe ping everyone who had an opinion on-thread?

will do after I close the PR

pnkfelix (Apr 23 2020 at 14:56, on Zulip):

okay so that's all the nom's

pnkfelix (Apr 23 2020 at 14:56, on Zulip):

we had two WG checkins scheduled

pnkfelix (Apr 23 2020 at 14:56, on Zulip):

WG-parallel-rustc says there are no updates

pnkfelix (Apr 23 2020 at 14:56, on Zulip):

and WG-polonius shared an update up above

pnkfelix (Apr 23 2020 at 14:58, on Zulip):

So that's all, folks! Thank you so much to everyone in @T-compiler/meeting for attending! you are awesome. Stay healthy, stay safe!

bjorn3 (Apr 23 2020 at 20:15, on Zulip):

nagisa said:

Maybe the concept of having debugger tests (as opposed to debug info tests) is flawed in the first placE?

I disagree. I just had an instance today where the debuginfo generated by cg_clif looked plausible, but it violated the DWARF spec in such a way that gdb ignored it. (missing some mandatory attributes) Using a debugger test detects this, while using a debug info test, it is hard for reviewers to know that there is a problem. Debug info tests can be used to complement debugger tests though.

https://github.com/bjorn3/rustc_codegen_cranelift/pull/978

RalfJ (Apr 24 2020 at 13:08, on Zulip):

pnkfelix said:

is RalfJ here? I'm curious why we don't just go ahead and revert on master too?

hm, good question. I thought we'd get a fix on master quickly.

@pnkfelix looks like you are taking care of that?

pnkfelix (Apr 24 2020 at 13:31, on Zulip):

@RalfJ yeah that's my plan. I didn't follow through yesterday (childcare stuff got in way), but hope to do so today.

RalfJ (Apr 24 2020 at 13:55, on Zulip):

great, thanks!

Last update: Jun 04 2020 at 18:20UTC