who debugs the debuginfo

[pnkfelix]

Meeting proposal info

• Title: Who debugs the debuginfo
• Type: it's complicated
• Proposed by: pnkfelix
• Link: https://gist.github.com/pnkfelix/a9f86000840701d8474daadcef43e0e0
• Scheduled dates for discussion:
  • Not yet scheduled, we'll add content here when it gets scheduled

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

[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.)