who debugs the debuginfo about compiler-team

[nikomatsakis]

We discussed this meeting in today's design meeting and we decided to schedule it tentatively for October 18th. (Sadly, I will not be present 😢)

The goal is more to discuss how we can get a sustainable story than the particular issues themselves, though that may also be a topic of discussion. On Zulip, we outlined:

1. what steps can we do to recruit folks
2. what are some thresholds and timelines where upon we consider more drastic action
3. what might that drastic action be :)

We also said that we should be trying to take some pre-steps and resolving immediate problems without waiting for the meeting.

[pnkfelix]

we had the meeting.

here is the zulip archive: https://zulip-archive.rust-lang.org/131828tcompiler/13652designmeeting20191018.html

some of the main points from the discussion:

• a common refrain: most of the compiler developers know next to nothing about how the debugger support scripts are implemented. So we are not in a good position to maintain the debugger support scripts.
• @eddyb has ideas for how we might try to shift functionality out of the debugger support scripts and instead "handled it through traits and codegen" (?)
• debuginfo tests are effectively unmaintained because everyone has their own ways of ignoring the failures
  • We should add // ignore to the problematic tests in the short term (but make sure to associate any such ignore with a rust-lang/rust issue).
• we might want to split the tests into debuginfo and debugger-pretty or something; the debuginfo stuff we must keep working, while debugger-pretty are more "nice to have" bits of functionality

[pnkfelix]

(ah I guess the way we're supposed to handle this is to actually add minutes from the meeting to the repo, and then that can close this issue. I suppose I should look into translating the above comment into such minutes.)