Skip to content

transcribed comments from github issue into a markdown doc. #223

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Nov 22, 2019
Merged

transcribed comments from github issue into a markdown doc. #223

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions content/minutes/design-meeting/2019-10-18-debuginfo-meeting.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
---
title: Debugging Support
type: docs
---

# Debugging Support in the Compiler

* [Zulip stream][] or read on the [Zulip archive][]


[Zulip stream]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-10-18/near/178475282
[Zulip archive]: https://zulip-archive.rust-lang.org/131828tcompiler/13652designmeeting20191018.html

## The problems

https://github.com/rust-lang/rust/issues/64343

We have bugs with debuginfo that are causing broad pain for people who use x.py test, but we do not have dedicated developers who own maintenance of debugger support.

https://github.com/rust-lang/rust/pull/60826

We have Pull Requests to improve our debuginfo support, but we do not have dedicated developers who own maintenance of debugger support.

Q: Are we willing/able to maintain debuginfo stuff Q: if we don't, then can we afford to keep these tests?

In short, as Niko said: "we need help to maintain this or we may have to remove it"

----

The overarching goal was to discuss how we can get a sustainable story than the particular issues themselves, though that may also be a topic of discussion.

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


## The meeting

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