4

I'm trying to debug an issue in Serde, and I can step through my code fine, but unfortunately Serde is like 90% macros, so it seems like the entire call to deserialize() gets mapped to the line containing #[derive(Deserialize)] and I can't set through it.

Is there any way around this? If it were code I have written I suppose I could use cargo expand, but it's in another crate so I'm not sure how to do that.

Timmmm
  • 88,195
  • 71
  • 364
  • 509
  • 1
    What debugger are you using? What makes you think stepping into Serde's code is a good idea? Why can't you just set a breaking point into one of Serde's function? – mcarton Mar 06 '20 at 13:06
  • Did you try `cargo expand`? It doesn't matter where the macros come from, it works for any, including built-in ones like `println`. – Peter Hall Mar 06 '20 at 13:33
  • 1
    @mcarton: I'm using `lldb`, and why wouldn't it be a good idea to step into Serde's code? @Peter Hall: Yes I did. The issue is that it only expands macros in *my* code. It doesn't help if I step into macro in Serde's code. (I did actually manage to solve my original issue using `cargo expand`, but the question still stands - how would I debug an issue in another crate's code that uses macros?) – Timmmm Mar 06 '20 at 16:00
  • It doesn't seems like a good idea to step into Serde's code because it's a well tested library with a lot a generated code. If you do think there is a bug in serde, then I'd place breakpoints (or a regular expression BP) to some interesting Serde methods. – mcarton Mar 06 '20 at 16:11
  • 5
    That's silly. All software [has bugs](https://github.com/serde-rs/serde/issues/1748). – Timmmm Mar 06 '20 at 16:24

0 Answers0