the cargo command configurations pick up the correct toolchain from the override
It's coold, but, as I mentioned, if you have rustup override in a project, Intellij Rust starts behaving strangely. At least, it was so some time ago. Rustup override is a very rarely used feature, so I'm not sure
So I am trying to set some breakpoints on gtk-rs, which is a dependency on my project.
Currently, the breakpoints seem to be valid/recognized by the debugger (they are red), but do not suspend the program.
Note that I can step into these areas of execution just fine.
It's just that I can't have the debugger run until it hits a breakpoint in an external library.
Is suspending on breakpoints in external libraries supported?
Edit Configurations...button). See https://blog.jetbrains.com/clion/2019/10/debugging-rust-code-in-clion/ for more information and screenshots
mouse008Does this plugin look inside
unsafeblocks, particularly those containing
asm!(...)? I'm getting an (incorrect) "potentially uninitialized..." warning from IntelliJ. Both
cargo clippyare totally OK with that code - no complaint from them, so they must've understood what the code is doing.
To testproject? Or must the PR also have someone assigned?
It's bad if the PR is not assigned to anyone. It can be easily missed. You can assign it to a someone by yourself.
If PR is assigned, but the assignee doesn't respond for a long time, I think it's OK to ping them.
Ideally, PRs should be reviewed fast. But I don't know how to achieve it :(
I can speak for myself: I usually focus on some large task for a long time and it's hard for me to switch context and review something in a subsystem that I am not good at. So, sometimes I review some PRs "in batch" =D At that time I don't do anything large. Maybe some bugfixes...
nixpkgs-mozillaoverlay), but since I am not using rustup, I have to set the stdlib path every time my toolchain is updated