copacetic@discuss.tchncs.de to RustEnglish · 2 days agoSpeeding up the Rust edit-build-run cycledavidlattimore.github.ioexternal-linkmessage-square10fedilinkarrow-up122arrow-down11cross-posted to: [email protected][email protected]
arrow-up121arrow-down1external-linkSpeeding up the Rust edit-build-run cycledavidlattimore.github.iocopacetic@discuss.tchncs.de to RustEnglish · 2 days agomessage-square10fedilinkcross-posted to: [email protected][email protected]
minus-squareBB_Clinkfedilinkarrow-up2·3 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.