---
tags: debugging
---

# wg-debugging 2022-10-03 meeting

## Agenda

- Next upcoming meeting: Triage meeting on Mon October 17th, 10am ET.
- Text meeting in the Zulip channel.
- Last meeting we covered 8 issues (marked 5 as needs repro)

- Next design & status meeting: Tue November 1st, 12pm ET.
- We'll try to alternate between the Monday & Tuesday timeslots.
- (Wesley says they will check if we should just fold all meetings into Monday time slot; action item below)

- Wins
- Slow month overall, @wesleywiser was working on other things; should have more time for debugging work in the next cycle.
- ssa: implement #[collapse_debuginfo] [#99556](https://github.com/rust-lang/rust/pull/99556)
- Merged, thanks @davidtwco!
- Others?

# Topics

https://github.com/rust-lang/rust/issues/55352#issuecomment-1251186394

* The person who filed #55352 has now switched to the `instrument-coverage` feature, and says that it meets their needs.
* What to do for coverage of panic handlers?
* Might be useful to provide flags to say "optimize my debuginfo for code-coverage" vs "optimize for actual debugging"
* E.g. for code-coverage, you may not want panic-handlers to have line numbers
* But for actual debugging (as in stack-traces) of panics that you observe in a running system, you definitely want line numbers for those panic handlers
* May want flags to specific whether or not to annotate:
* panic handlers
* drops. I.e. some people do not care about ensuring that some combination of drops is tested, while another group very much *does* care about e.g. testing for `{ let z; { let y; let x; ..._1 /* drop {x,y} */ } ..._2 /* drop z */ }`, checking whether you have a test for when {x,y} are dropped but not `z` (i.e. testing when there is a break out of `..._2`)

Action items:

- Wesley to re-poll participants about design meeting time slot