copacetic@discuss.tchncs.de to Rust@programming.devEnglish · 2 days agoSpeeding up the Rust edit-build-run cycledavidlattimore.github.ioexternal-linkmessage-square10fedilinkarrow-up123arrow-down11cross-posted to: [email protected]
arrow-up122arrow-down1external-linkSpeeding up the Rust edit-build-run cycledavidlattimore.github.iocopacetic@discuss.tchncs.de to Rust@programming.devEnglish · 2 days agomessage-square10fedilinkcross-posted to: [email protected]
minus-squareBB_C@programming.devlinkfedilinkarrow-up2·10 hours ago for multi threaded workloads there aren’t many options Anyone who actually writes Rust code knows about tracing my friend. We also have the ever useful #[track_caller]/Location::caller(). And it’s needless to say that dbg!() also exists, which is better than manual printing for quick debugging. So there exists a range of options setting between simple printing, and having to resort to using gdb/lldb (possibly with rr). But yes, skipping debugging symbols was a bad suggestion.
Anyone who actually writes Rust code knows about tracing my friend.
We also have the ever useful
#[track_caller]
/Location::caller().And it’s needless to say that dbg!() also exists, which is better than manual printing for quick debugging.
So there exists a range of options setting between simple printing, and having to resort to using gdb/lldb (possibly with rr).
But yes, skipping debugging symbols was a bad suggestion.