Temporary configurations are fully functional, but you can only have a limited number of them at a time. In fact, when earlier we started a debug session from the gutter menu, CLion created a temporary Cargo Command configuration, which we can see greyed out in the switcher: Let’s get back to debugging, but this time let’s use a run/debug configuration. The bundled renderers also support standard library types like HashMap, HashSet, Rc, Arc, Cell, Ref, and others. These formatters build tree views for strings, structs, enums, and vectors, making it easier for you to look inside child elements. Rust compiler’s renderers: With this option, IntelliJ Rust takes pretty-printers from the standard rustc distribution and loads them onto the debugger.īundled renderers: The plugin’s own renderers were implemented from scratch for both GDB and LLDB, unifying types representation for the two debuggers. Because Rust type formatters are not available in the debuggers out of the box in their current state, this option means no rendering for types that differ from C/C++. No renderers: This option disables explicit rendering, leaving only the type support provided by GDB or LLDB natively. The supported versions are listed in CLion’s web help.Īpart from the debugger itself, we can switch the renderers it will use when showing Rust types in the Variables pane:
On Windows, we can choose between bundled GDB for MinGW, Cygwin GDB, or custom GDB.On macOS and Linux, the options are bundled LLDB, bundled GDB, or a custom GDB binary.
We can pick the debugger that IntelliJ Rust will employ:
#Clion wsl2 how to
Now that we know how to step through and examine variables, let’s stop the session and take a look at the settings. In such cases, Force Step Into jumps right to disassembly:
#Clion wsl2 code
The latter is helpful when we want to get into a function whose source code is unavailable. We can search in this pane by typing right into it and expand the child nodes of the data structures.Īctually, we don’t have to dig into the Variables pane at every step, as the values are also shown inline, together with the variables:Īcross the top of the Debug window, we have stepping buttons like Step Over ( F8), Step Into ( F7), and Force Step Into ( Shift+Alt+F7 on Windows/Linux, ⇧⌥F7 on macOS). On the right side, we have the variables in the current scope. It’s organized around the stack trace and threads: we can switch from one thread to another and travel up and down the frames. When our test hits the first breakpoint, the Debug window pops up automatically. The plugin will call cargo test to get the non-optimized binary with debug information, which it will then launch under the debugger. Let’s pick a test we want to debug, place a few breakpoints in the code, and click the gutter icon next to the test name: If we want to debug a test or target that doesn’t take input arguments, the quickest way is to use the gutter menu. You can set the appropriate toolchain by running rustup default. If you’re on MinGW64, it should be x86_64-pc-windows-gnu. For example, if you’re working on MinGW (32-bit), the default toolchain should be i686-pc-windows-gnu. Then, run rustup toolchain list and check the first line: it should be one of the gnu versions matching the bitness of the debugger. On Windows, go to Settings | Build, Execution, Deployment | Toolchain and set either Cygwin or MinGW as your working environment. If the indexing is finished and the Cargo tool window shows all the modules and targets of the workspace, you’re good to go. Before you beginįirst of all, make sure that your project is fully loaded. If you need more information at any point, please refer to the plugin’s Quick Start Guide and the Debug section in CLion’s web help.
0 kommentar(er)
