Re:Speeding up the Rust edit-build-run cycle
by freeone3000 on Thursday November 14, 2024 @05:02PM
(#42141699)
CLion adds the power of IntelliJ debuggers to Rust. It works exceptionally well.
Re:Speeding up the Rust edit-build-run cycle
by nicce on Thursday November 14, 2024 @06:30PM
(#42142418)
Do you have more information about this?
Last time I debugged Rust with CLion/RustRover, the debugger was the same as VSCode uses.
Re:Speeding up the Rust edit-build-run cycle
by freeone3000 on Thursday November 14, 2024 @07:24PM
(#42142773)
Sure. It’s got breakpoints, and conditional breakpoints, using the same engine as IntelliJ. It’s got evaluate, it’s got expression and count conditionals, it’s got rewind. It has the standard locals view.
Rust support has improved in 2024 pretty strongly (before this year it just shelled out to lldb); the expr parser and more importantly the variable viewer are greatly improved since January.
Re:Speeding up the Rust edit-build-run cycle
by gooosle on Thursday November 14, 2024 @06:25PM
(#42142382)
Does it support evaluating code, in context, while debugging?
Re:Speeding up the Rust edit-build-run cycle
by freeone3000 on Thursday November 14, 2024 @07:21PM
(#42142753)
Yes*, mostly
It can do any single expression, and the results are better than lldb, but it can’t do multiple statements and not everything in Rust can be one expression; you can’t use {} here
Re:Speeding up the Rust edit-build-run cycle
by flohofwoe on Friday November 15, 2024 @03:11AM
(#42144852)
> much more so than what I've seen from C/C++/Rust debuggers.
...have you ever used the Visual Studio integrated debugger for C/C++ instead of 'raw' gdb/lldb without a UI frontend?
Re:Speeding up the Rust edit-build-run cycle
by kaba0 on Friday November 15, 2024 @03:32AM
(#42144950)
I mean, even then c/CPP will optimize out stuff and you won't get as nice one-to-one mapping as you do with eg. Java.
Re:Speeding up the Rust edit-build-run cycle
by flohofwoe on Friday November 15, 2024 @03:43AM
(#42145010)
That's why the debug build config one uses during development only does little to no optimizations.
Re:Speeding up the Rust edit-build-run cycle
by kaba0 on Friday November 15, 2024 @03:47AM
(#42145038)
My point is that even that little can sometimes lead to less pleasant experiences, like stepping half a function's body ahead.
Re:Speeding up the Rust edit-build-run cycle
by flohofwoe on Friday November 15, 2024 @03:58AM
(#42145100)
Hmm, I've only seen that in some 'new-ish' languages sometimes (like currently Zig), which I think is a compiler bug when generating debug info. In C/C++ I see such random stepping only when trying to debug an optimized program.
If I'm debugging some complicated TomEE application that might take 2 minutes to start up, then I'm absolutely reaching to an IntelliJ debugger as one of my first tools.
If I'm debugging some small command line application in Rust that will take 100ms to exhibit the failure mode, there's a very good chance that adding a println debug statement is what I'll try first