Stream: t-compiler

Topic: design meeting 2019-10-18


pnkfelix (Oct 18 2019 at 13:49, on Zulip):

Just a reminder to @T-compiler/meeting : we will be starting this week's design meeting in this topic area in about 11 minutes

simulacrum (Oct 18 2019 at 13:50, on Zulip):

Do we have a link to agenda handy?

pnkfelix (Oct 18 2019 at 13:50, on Zulip):

This weeks topic is debuginfo, or more generally: What resources can we devote to supporting the debugging experience? If those resources are insufficient, can/should we move debuginfo support extensions out-of-tree

pnkfelix (Oct 18 2019 at 13:51, on Zulip):

compiler-team#186 was the proposal for this meeting

pnkfelix (Oct 18 2019 at 13:51, on Zulip):

the closest thing we have to an agenda is the gist linked there: https://gist.github.com/pnkfelix/a9f86000840701d8474daadcef43e0e0

centril (Oct 18 2019 at 13:51, on Zulip):

@pnkfelix maybe we can fit more than one topic in the meeting slot? debuginfo might not take so much time (famous last words)

pnkfelix (Oct 18 2019 at 13:52, on Zulip):

I have mixed feelings about adding new topics on the fly; in theory, people may want advance notice if a topic is going to be discussed.

pnkfelix (Oct 18 2019 at 13:52, on Zulip):

but I suppose there is nothing stopping us from having informal chats in whatever time remains

pnkfelix (Oct 18 2019 at 13:53, on Zulip):

I just want to be wary of making decisions about other topics during a just-in-time scheduled discussion

centril (Oct 18 2019 at 13:53, on Zulip):

@pnkfelix fair point, maybe we can pick some topic that requires less read-up time?

simulacrum (Oct 18 2019 at 13:53, on Zulip):

I think we should prefer to not formally add them and certainly not ahead of time

simulacrum (Oct 18 2019 at 13:53, on Zulip):

Debuginfo sounds like a complex topic that we have no good answers for, too :)

pnkfelix (Oct 18 2019 at 13:53, on Zulip):

I think we should prefer to not formally add them and certainly not ahead of time

I'm sorry, is this a statement in favor of more JIT-scheduling of topics?

pnkfelix (Oct 18 2019 at 13:54, on Zulip):

(because that's how it parses in my brain.)

centril (Oct 18 2019 at 13:54, on Zulip):

I think Mark is saying the opposite :slight_smile:

centril (Oct 18 2019 at 13:55, on Zulip):

I believe we want to mostly discuss maintainership of debuginfo tho today?

simulacrum (Oct 18 2019 at 13:55, on Zulip):

I'm saying that if we are to discuss other things today we should do so when we get there

simulacrum (Oct 18 2019 at 13:55, on Zulip):

Not decide now what we may or may not discuss

centril (Oct 18 2019 at 13:55, on Zulip):

@simulacrum seems obviously right :P

simulacrum (Oct 18 2019 at 13:55, on Zulip):

Not decide now what we may or may not discuss

simulacrum (Oct 18 2019 at 13:55, on Zulip):

And in either case not make decisions

simulacrum (Oct 18 2019 at 13:55, on Zulip):

Not decide now what we may or may not discuss

simulacrum (Oct 18 2019 at 13:55, on Zulip):

And in either case not make decisions

simulacrum (Oct 18 2019 at 13:56, on Zulip):

Gah zulip why

centril (Oct 18 2019 at 13:56, on Zulip):

(imo the point of design meetings is mostly to just have a lot of compiler devs present so we can think more collaboratively about a larger change)

Wesley Wiser (Oct 18 2019 at 13:59, on Zulip):

I think it's also important that people have time to prepare for the discussion. Otherwise we just end up with most of the team watching the stream as a few people familiar with the topic talk.

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

okay so lets get started

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

as noted in the gist, there are two points raised there that can sort of act as drivers for the conversation today

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

namely, we have both bugs and Pull Requests related to debuginfo, but its not clear if we have anyone qualified (or at least willing to claim qualification, and/or time/resources available) to fix the bugs and/or review the PR's.

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

So the most obvious question to ask: What if I'm wrong? Do we have anyone here who feels like they could be the "debuginfo expert" ?

oli (Oct 18 2019 at 14:04, on Zulip):

I wouldn't even know who to ask :frown:

centril (Oct 18 2019 at 14:04, on Zulip):

https://github.com/rust-lang/rust/issues/64343 in particular is causing me pain when doing local testing of rollups and other things

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

I would start by asking @mw , myself

centril (Oct 18 2019 at 14:05, on Zulip):

from my end, if we removed it, that would suffice (larger changes are not something I'm going to push for)

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

(is @mw here today?)

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

@centril sure, I can understand that. But I do think there's a broader question here that its useful to talk about

centril (Oct 18 2019 at 14:06, on Zulip):

@pnkfelix don't disagree :slight_smile:

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

okay well given the sound of crickets in response to my question above, I'm going to assume we don't have any local debuginfo experts

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

So my next question is: Would it be reasonable to move debuginfo support out of tree?

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

(i think of this as being similar to what we did with things like Emacs support, where we made a separate rust-mode.el repo)

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

But I am not 100% certain that the pro's there would outweigh the con's.

Wesley Wiser (Oct 18 2019 at 14:08, on Zulip):

Could you maybe expand a bit on what that would mean? Would it just be the testing of debuginfo that gets moved out? Or generating debuginfo entirely?

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

In particular: I assume the debugger support is tied in some way to the details of internal representations of things like Vec and &[T]

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

Could you maybe expand a bit on what that would mean? Would it just be the testing of debuginfo that gets moved out? Or generating debuginfo entirely?

Ah, good point. there may be separate details here that I should make explicitly seprate

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

My understanding is that we support debuggers in a couple of different ways

centril (Oct 18 2019 at 14:10, on Zulip):

hasn't @eddyb worked on debuginfo somewhat?

pnkfelix (Oct 18 2019 at 14:10, on Zulip):
  1. we have symbol tables in our object files, 2. we generate DWARF files on the side, and 3. we have debugger support scripts (written I think in Python) that you load up from gdb or lldb to get better experience interacting with Rust code
pnkfelix (Oct 18 2019 at 14:11, on Zulip):

I think (1.) and (2.) are tightly coupled to the compiler. I do not know how one would support them out of tree.

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

so I guess the main thing I was thinking could move out of tree was (3.)

eddyb (Oct 18 2019 at 14:12, on Zulip):

hi, sorry, got distracted for a bit

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

the unit tests in src/test/debuginfo, I assume, are exercising the combined effect of (1+2+3)

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

(I guess I should check that claim though.)

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

@eddyb please do correct any mis-statements I may have made so far

eddyb (Oct 18 2019 at 14:16, on Zulip):
  1. I'm always confused when people use "symbol" anywhere near debuginfo, because I think of "symbol names" as "linking identifiers"
  2. we emit LLVM's API for DWARF, which can actually lower into CodeView for windows .pdb. we should figure out a more general API to allow cranelift support as well but what we have in-tree will likely remain there

    • note that it's not tested explicitly, we should maybe fix that! @mw had some ideas
  3. sure, we could move the gdb/lldb scripts out of tree if we need to

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

Yeah, in my messages above, I have been mixing "debugger UX" with "debuginfo" in a pretty confusing manner

eddyb (Oct 18 2019 at 14:18, on Zulip):

inside the compiler, "debuginfo" refers to what ultimately ends up as DWARF/CodeView, AFAIK

eddyb (Oct 18 2019 at 14:18, on Zulip):

but "debuginfo" as a team/WG/general concern should include debuggers yeah

eddyb (Oct 18 2019 at 14:18, on Zulip):

I guess you could have a "debugging WG/team" which wouldn't need to focus only on traditional debuginfo etc.

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

but in order to make a WG, we need to have people to populate it

eddyb (Oct 18 2019 at 14:19, on Zulip):

some history: all of our debuginfo code was written by @mw

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

(and those people need to actually have time available, etc)

eddyb (Oct 18 2019 at 14:19, on Zulip):

(at least initially, people have touched it over the years but it still is mainly @mw as far as I'm aware)

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

yeah its sort of bad that @mw is not here today; I had thought they said they were going to be available

eddyb (Oct 18 2019 at 14:21, on Zulip):

one thing I've been trying to do since last year, and I almost have ready now, is starting to shape something less ad-hoc at the MIR level, so that we can lower it into codegen backend debuginfo the same way we do for code

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

@eddyb can you elaborate further on this?

Wesley Wiser (Oct 18 2019 at 14:21, on Zulip):

mw's status says "out sick"

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

@Wesley Wiser ah, thanks for checking that

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

@eddyb in particular: I don't want/need details about the particular design you are envisaging

eddyb (Oct 18 2019 at 14:22, on Zulip):

oh speaking of which, there are two sides to debuginfo: program metadata (functions, types, etc.) and intra-function debuginfo (e.g. file/line/col info, where are user variables stored, etc.), mostly the latter would make sense to do anything for at the MIR level

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

but rather, what are the goals, like the advantages you are expecting?

eddyb (Oct 18 2019 at 14:23, on Zulip):

'sec, I was getting a link to the PR https://github.com/rust-lang/rust/pull/56231

eddyb (Oct 18 2019 at 14:23, on Zulip):

the main advantage IMO is that we can transform the resulting MIR-level debuginfo and preserve the information

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

hmmmmm

eddyb (Oct 18 2019 at 14:23, on Zulip):

right now closure and generator debuginfo, for example, has a hardcoded shape and MIR inlining just can't work on them

eddyb (Oct 18 2019 at 14:24, on Zulip):

because suddenly your closure value is no longer in the first argument or whatever

eddyb (Oct 18 2019 at 14:24, on Zulip):

or if we want multiple user variables to be backed by the same MIR local (we could add a Vec<Name> to LocalDecl but that feels silly)

eddyb (Oct 18 2019 at 14:25, on Zulip):

in general, I think we can design "what we want the debugger can see" at a higher level and never do any transform that would break it

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

okay

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

the revisions you're talking about doing, @eddyb , is this work that you see landing in the near-ish future, like next few months?

eddyb (Oct 18 2019 at 14:26, on Zulip):

as a principle of "bestest-effort" as opposed to LLVM's "optimizations may drop debuginfo on the floor if they can't do any better"

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

like, P #56231 was opened nearly a year ago

eddyb (Oct 18 2019 at 14:26, on Zulip):

it was in limbo for almost a year and I almost finished it last month, I was hoping to land it really soon

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

okay that's great

eddyb (Oct 18 2019 at 14:27, on Zulip):

it blocks two MIR optimizations (SROA and NRVO) which have been mostly implemented since last year but not landed

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

(I can indeed see that work has been ongoing on it, and it was blocked for a while, or at least subsumed/subverted by PR #56278)

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

In any case

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

it seems like these points are related to how we implement rustc's built-in support for debuginfo

eddyb (Oct 18 2019 at 14:28, on Zulip):

you brought up one thing which I forgot to address, the Vec<T> layout assumption in the debugger scripts

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

yep. I don't know whether we should be worrying about that or not

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

it strikes me as one of the main reasons to leave the debugger-scripts in tree

eddyb (Oct 18 2019 at 14:29, on Zulip):

there is one thing we could do but I'm not sure what's the best way to implement it

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

just because of the coupling there

eddyb (Oct 18 2019 at 14:29, on Zulip):

which is to move that stuff into a trait impl (or even expose fmt::Debug itself somehow)

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

but ... @eddyb , do you know off hand if we can (and do) encode a Rust version into the debug info we generate?

eddyb (Oct 18 2019 at 14:30, on Zulip):

we do

eddyb (Oct 18 2019 at 14:30, on Zulip):

it's an useragent

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

i.e., is there something that the debugger scripts could sniff, and then it would have its own table mapping rust-version to Vec<T> layout info.

eddyb (Oct 18 2019 at 14:30, on Zulip):

https://github.com/rust-lang/rust/blob/518deda77feb4957bfd311b6cb50baa7ef9ca6a2/src/librustc_codegen_llvm/debuginfo/metadata.rs#L920-L925

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

(its not as elegant as finding some way to provide the layout info via some other channel, but it seems like something simple that would work...)

eddyb (Oct 18 2019 at 14:31, on Zulip):

(gdb has a bug that requires us to say that we're "clang but really rustc")

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

i.e., is there something that the debugger scripts could sniff, and then it would have its own table mapping rust-version to Vec<T> layout info.

Does this sound correct to you, @eddyb ?

eddyb (Oct 18 2019 at 14:31, on Zulip):

@pnkfelix I mean, first off, you don't even need to assume the layout, since type debuginfo has it anyway

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

well I guess I meant how its meant to interpret the fields it finds

eddyb (Oct 18 2019 at 14:32, on Zulip):

you need to assume what a pointer means

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

I don't know enough about debuginfo to know if we encode the interpretation in some manner. I assume it does not

eddyb (Oct 18 2019 at 14:32, on Zulip):

that's in general the annoying problem with type debuginfo, and unlike enum variants which we did get a DWARF feature for, idk if there is something for "what's behind a pointer"

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

okay so by "layout info" i really meant "how to interpret the fields (ptr, len, cap)"

eddyb (Oct 18 2019 at 14:34, on Zulip):

DWARF can execute a sort of bytecode to compute values at runtime, you'd "just" need to be able to use that for the length of an array or something

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

interesting. okay.

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

not necessarily something we want to support ourselves in tree

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

but maybe we would

eddyb (Oct 18 2019 at 14:34, on Zulip):

but as it stands we might be able to encode something in the type debuginfo of Vec specifically, via an unstable trait it implements

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

the whole point of this meeting is that we don't have the development resources to play interesting DWARF games, I think

eddyb (Oct 18 2019 at 14:35, on Zulip):

maybe via crafting v0 symbol names to reach a debug helper in the debugger script

eddyb (Oct 18 2019 at 14:35, on Zulip):

@pnkfelix we don't have the resources to propose something upstream

eddyb (Oct 18 2019 at 14:35, on Zulip):

and we might not have the expertise to know what's even in the standard

eddyb (Oct 18 2019 at 14:36, on Zulip):

that I agree with

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

... i ... don't think I was suggesting upstream-proposals as an alternative ...

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

let me bring this back to a concrete example

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

this issue: "debuginfo/pretty-uninitialized-vec fails with Cannot access memory at address 0x7fffff7fe000" #64343

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

I suspect an expert could resolve that quickly

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

I also suspect that even a novice (to rustc-development) might be able to resolve it if they dedicated a day or three to it

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

(that suspicion is based on this comment)

eddyb (Oct 18 2019 at 14:38, on Zulip):

there's another thing: while I (and a few others) know a couple things about debuginfo inside rustc, I at least know basically nothing about how the debugger scripts work

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

Right!

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

that's the point

eddyb (Oct 18 2019 at 14:39, on Zulip):

I would prefer if they did significantly less work themselves

eddyb (Oct 18 2019 at 14:39, on Zulip):

and instead we handled most of it through traits and codegen

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

is there a path where we could move just the debugger scripts out of tree, along with their unit tests?

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

and then if people want to try their hand at fixing them on their own, they would be able to do so in an isolated fashion?

eddyb (Oct 18 2019 at 14:40, on Zulip):

uhhhhhhh I don't know what that would accomplish

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

if nothing else, it would get this unit test from blocking T-release

eddyb (Oct 18 2019 at 14:40, on Zulip):

they can do that without that part, I don't see where a barrier might be

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

@eddyb basically that test file prevents me from doing ./x.py test

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

and stops way earlier than I need it to

eddyb (Oct 18 2019 at 14:41, on Zulip):

my build command deletes every time a different debuginfo test because LLVM crashes during codegen

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

you see we are all stepping around this roadblock in different ways

eddyb (Oct 18 2019 at 14:42, on Zulip):

and then there's that time when we found that we weren't even running the debuginfo tests on CI for a while

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

wait maybe I misunderstand your "deletes every time" comment

eddyb (Oct 18 2019 at 14:42, on Zulip):

I don't even know if we re-enabled all of them by now

Wesley Wiser (Oct 18 2019 at 14:42, on Zulip):

It sounds to me like people are saying the debuginfo tests are effectively unmaintained because everyone has their own way of ignoring the failures

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

are you deleting tests by accident due to a crash?

eddyb (Oct 18 2019 at 14:42, on Zulip):

no, intentionally, so that I can run debuginfo tests

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

or are you deleting them on purpose to work around a crash

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

okay

eddyb (Oct 18 2019 at 14:43, on Zulip):

running those tests is important

eddyb (Oct 18 2019 at 14:43, on Zulip):

as a first step you might want to split the tests into debuginfo and debugger-pretty or something

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

yes: we definitely need to keep testing our DWARF debuginfo generation in-tree

eddyb (Oct 18 2019 at 14:44, on Zulip):

most of them are important codegen tests, and in fact one idea @mw had was to add explicit codegen tests for the LLVM annotations instead of puppetting a debugger

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

by the way, is there any reason that we don't have a bisection for #64343 ?

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

(other than "bisecting local builds takes a long time" ?)

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

I'm assuming that test worked at some point ...

eddyb (Oct 18 2019 at 14:47, on Zulip):

did we bisect it to a nightly?

eddyb (Oct 18 2019 at 14:47, on Zulip):

I hate that compiletest has a hostile CLI

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

(personally I don't really like gdb and don't want to learn it)

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

there's no bisection data on the ticket

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

I'll mark it needs-bisect

eddyb (Oct 18 2019 at 14:47, on Zulip):

need to pass a bajillion flags to get it to do anything

eddyb (Oct 18 2019 at 14:47, on Zulip):

@centril all you'd need is to run compiletest on that file with the right twenty flags :P

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

and for me the size of the command line is too long for my shell

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

so I end up having to put the command into a shell script just to run it

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

its pretty great

eddyb (Oct 18 2019 at 14:48, on Zulip):

multiline prompts :P

eddyb (Oct 18 2019 at 14:48, on Zulip):

anyway my point is you don't actually need to build rustc to run these tests

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

okay

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

(and my point is that it was weird we hadn't bisected it at all yet)

eddyb (Oct 18 2019 at 14:48, on Zulip):

@simulacrum's ideas of using a recent build for stage0 instead of beta would probably make this much easier

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

okay well I think we have at least some (small?) action items for issues with debuginfo/debugger-ux tests

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

let me bring up the other driving point

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

PR "WIP: Implement new gdb/lldb pretty-printers" #60826

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

basically we have completely stalled on this PR

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

the PR itself fails the tests

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

we don't have local experts able/willing to help the author fix their PR

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

this is the sort of thing that was prompting me to suggest moving the debugger-support scripts out of tree

eddyb (Oct 18 2019 at 14:52, on Zulip):

and we probably shouldn't even do that PR if we can come up with a better way to handle pretty-printers

centril (Oct 18 2019 at 14:52, on Zulip):

@pnkfelix can I make a suggestion to just put // ignore for now on this specific test?

centril (Oct 18 2019 at 14:52, on Zulip):

(to solve the immediate problem first)

eddyb (Oct 18 2019 at 14:52, on Zulip):

the only thing you'd be forced to do by moving out of tree is to wrap compiletest. which you can do in-tree

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

and we probably shouldn't even do that PR if we can come up with a better way to handle pretty-printers

maybe you could write up an elaborated proposal for this and put it up for a future design meeting?

centril (Oct 18 2019 at 14:52, on Zulip):

(or if // ignore doesn't work, whatever the equivalent of that is)

eddyb (Oct 18 2019 at 14:52, on Zulip):

@centril we should require issues on every single // ignore

centril (Oct 18 2019 at 14:53, on Zulip):

@eddyb that's a good idea

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

I don't have any problem with tagging the test with ignore, as long as we file a related follow-up issue so it doesn't get lost.

Wesley Wiser (Oct 18 2019 at 14:54, on Zulip):

Moving the scripts out of tree seems reasonable to me but I'm not sure how that resolves this issue. Do we just plan to delete/ignore these tests? If so, why don't we just do that now while the scripts are still in tree?

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

I think we want to make sure we keep the tests that are just testing the compiler's debuginfo generation

centril (Oct 18 2019 at 14:54, on Zulip):

@pnkfelix cool; I'll investigate how the test can be ignored then

Wesley Wiser (Oct 18 2019 at 14:55, on Zulip):

I guess my point is that we could do that now while the scripts are still in tree

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

@Wesley Wiser that is why I thought @eddyb made a good point about separating debuginfo from debugger-pretty

Wesley Wiser (Oct 18 2019 at 14:55, on Zulip):

So if that's all we want to do, I don't see much reason to move the scripts to another repo

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

yes, we can absolutely do such things now. it doesn't need to block on decisions about whether debugger-scripts live in tree or not

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

one reason to move the scripts to another repo: it may be easy to land changes and/or iterate development

eddyb (Oct 18 2019 at 14:57, on Zulip):

you could argue they're like syntax highlighting files

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

PR #60826 has been up since May

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

you could argue they're like syntax highlighting files

right, I made that analogy when I brought up our Emacs rust-mode.el repo

centril (Oct 18 2019 at 14:57, on Zulip):

Conclusions so far:
- we ignore the problematic test for now
- we split the tests by debuginfo/debugger-pretty
- consider moving them out of tree
- eddyb has various ideas and PRs about MIR and debuginfo

eddyb (Oct 18 2019 at 14:57, on Zulip):

@pnkfelix if you find me someone who knows how these python scripts work, and remind me to dive into LLVM's DWARF building API, I can probably come up with a workable solution

eddyb (Oct 18 2019 at 14:58, on Zulip):

the problem is that I can come up with a dozen hacks but I have no filter for which would be viable today

eddyb (Oct 18 2019 at 14:58, on Zulip):

at best right now I can propose "do something with a trait"

eddyb (Oct 18 2019 at 14:58, on Zulip):

which could very well be found in an issue with a 3-digit number for all I know

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

/me continues to be sad that @mw was not here

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

(hmm, zulip no longer highlights @**mw** ?

eddyb (Oct 18 2019 at 14:59, on Zulip):

@mw<TAB> makes @mw for me

eddyb (Oct 18 2019 at 15:00, on Zulip):

manual: @mw

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

what the heck, I am writing @mw

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

(!)

eddyb (Oct 18 2019 at 15:00, on Zulip):

#FunTimesWithZulip

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

okay sorry I'll play with this in the Zulip stream later

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

so I think we have the main action items for #64343 (namely, add an // ignore and open an issue)

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

do we have any action item for PR #60826 ?

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

since @eddyb said that we may not want to land it, I think we need to wait before we take action

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

I'll write a comment on the PR

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

Is there any other point that anyone wants to raise? We are 3 minutes over, so no one should feel obligated to stick around

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

(speaking of which, thank you to everyone in @T-compiler/meeting for attending !!!)

eddyb (Oct 18 2019 at 15:10, on Zulip):

I was looking for relevant issues and found https://github.com/rust-lang/rust/issues/37504 (apparently even &[T] is a problem, not just Vec<T>)

eddyb (Oct 18 2019 at 15:50, on Zulip):

the only other semi-relevant issue I can find is https://github.com/rust-lang/rust/issues/43334

eddyb (Oct 18 2019 at 17:04, on Zulip):

@pnkfelix btw I sketched a bit of the idea I had https://github.com/rust-lang/rust/issues/65564

nikomatsakis (Oct 19 2019 at 01:21, on Zulip):

(not sure if somebody is on this already, but can somebody open a PR with minutes or notes on the compiler-team repository?)

mw (Oct 21 2019 at 08:35, on Zulip):

Sorry for not attending. I was out sick the second half of last week :(

pnkfelix (Oct 21 2019 at 13:36, on Zulip):

@mw I totally understand

Last update: Nov 22 2019 at 04:30UTC