Help troubleshooting... Too many cargo processes

[augustocdias]

So since a couple weeks I can barely use rust-analyzer in neovim. It got to a point that my machine went out of memory and restarted itself. After investigating I found out that whenever I change something, dozens of cargo test processes are automatically spawned... I have no idea what is causing this... Could it be rust-analyzer? How do I troubleshoot this and find the root cause? I have tried a minimal config with just rustacean but I couldn't reproduce... So the plugin is not likely the cause, but I don't know what else to look at. Could you give me some help on how to find the issue?

This is the command that is ran:

cargo test --no-run --package core-crypto --lib --message-format=json

[mrcjkb]

Hey 👋

whenever I change something, dozens of cargo test processes are automatically spawned

This sounds to me like a rust-analyzer issue. If you can't reproduce it with a minimal config, I would suggest bisecting your rust-analyzer config.
You should be able to confirm it's caused by rust-analyzer by trying with the default config (i.e. passing in an empty table).

[augustocdias]

That's not what I'm understanding from reading the code. You get the runnables result from the server and for each result you call start from the dap module. Inside you call vim.system which basically runs cargo test --no-run.

[augustocdias]

Is it supposed to be starting dap during lsp initialisation?

[mrcjkb]

Oh yes, I forgot about that.
The issue is that if you have a lot of test configurations, it won't block on the vim.system call, leading to lots of parallel executions.

[mrcjkb]

This should solve the issue of parallel builds:

• fix(dap): prevent parallel cargo test builds #501

Is it supposed to be starting dap during lsp initialisation?

It doesn't actually run tests, it just compiles (hence the --no-run flag) and analyses the json output (hence the --message-format=json flag) to create a DAP configuration that can be registered with nvim-dap, so you can use commands like DapContinue to debug runnables discovered by rust-analyzer.

[augustocdias]

Oh yes, I forgot about that.

The issue is that if you have a lot of test configurations, it won't block on the vim.system call, leading to lots of parallel executions.

It is not supposed to block but because of the amount it does generate a couple freezes. This also adds up as it is ran every time I change something and save.

[mrcjkb]

The latest release runs the builds sequentially (see the PR linked in my previous comment).

This also adds up as it is ran every time I change something and save.

That doesn't sound right. It only runs when a new rust-analyzer client attaches.

[augustocdias]

That doesn't sound right. It only runs when a new rust-analyzer client attaches.

Yes. But imagine hundreds of child processes running in the background. And not cheap ones, rust compiling takes quite some time

which leads to the question: does it need to run for every runnable returned by the analyzer? Wouldn't a single cargo test return all the metadata needed here? I don't see any parameter related to each runnable being passed so isn't the output of all this processes the same?

your pr did solve the problem btw, but I didn't see the cargo test being ran at all and I get no runnables or debuggables

[mrcjkb]

And not cheap ones, rust compiling takes quite some time

cargo reuses artefacts that have been built already.
So it shouldn't be expensive with sequential builds.

does it need to run for every runnable returned by the analyzer?

Yes. rustaceanvim has no idea what build commands it's getting from rust-analyzer.

but I didn't see the cargo test being ran at all

There's no test being run (see the --no-run flag).

and I get no runnables or debuggables

You mentioned earlier that your tests weren't compiling yet. Perhaps that's the reason.
When building configurations to automatically add to nvim-dap, it fails silently.