Add flexible configuration for runnables

[popzxc]

This PR introduces two new configuration options for runnables: overrideCargo and cargoExtraArgs.
These options are applied to all the "run" tasks of rust analyzer, such as binaries and tests.

Overall motivation is that rust-analyzer provides similar options, for example, for rustfmt, but not for runnables.

overrideCargo

This option allows user to replace cargo command with something else (well, something that is compatible with the cargo arguments).

Motivation is that some projects may have wrappers around cargo (or even whole alternatives to cargo), which do something related to the project, and only then run cargo. With this feature, such users will be able to use lens and run tests directly from the IDE rather than from terminal.

cargoExtraArgs

This option allows user to add any additional arguments for cargo, such as --release.

It may be useful, for example, if project has big integration tests which take too long in debug mode, or if any other cargo flag has to be passed.

[matklad]

LGTM, but needs a rebase

while we are at it, maybe add support for env variables as well?

bors d+

Long-term, I kind of think we should pursue "template" configurations here, but this ideally needs upstream support: microsoft/language-server-protocol#944

[bors]

✌️ popzxc can now approve this pull request. To approve and merge a pull request, simply reply with bors r+. More detailed instructions are available here.

[popzxc]

It seems that env support was implemented as a separate feature (see the PR that references this PR), thus I guess I won't intervene.

[popzxc]

bors r+

[bors]

Build succeeded:

• Rust (ubuntu-latest)
• Rust (windows-latest)
• TypeScript (ubuntu-latest)
• TypeScript (windows-latest)

[Matthias247]

@popzxc @matklad @emgre

Regarding

while we are at it, maybe add support for env variables as well?

Yes - I think there is a use-case for this. E.g. there are configurations where you have to pass LD_LIBRARY_PATH to each wrapper call, to make sure the the executable built by cargo finds the correct shared libraries.

I'm not sure if #6099 is the ideal way to handle it, since it adds those variables to the RA server instead of to the commands it starts. Obviously those would be further propageted, but there exists for example the question if the values would actually be valid and could be populated before the first build.

For my personal use-case the value of the environment variable LD_LIBRARY_PATH would be retrieved running a script in the build folder. So I would be interested if the solution could support this instead of having to hardcode the env variables.

[emgre]

I'm open to that solution, although I don't think I have the required knowledge to implement it. My solution was just a quick'n'easy fix for my particular use case.

[matklad]

I am personally fine using either approach (overriding vars for server, or overriding vars for specific executable). I think at this stage both would be stop-gaps.

A proper solution would be to implement this in a language-agnostic way on the protocol level: microsoft/language-server-protocol#944. I think the design would end up different from what we have now, but I am not motivated to drive that to completion myself right now :-)

So, whatever does the job is fine! We will be able to change it in the future without problems.

[matklad]

Ah, @popzxc, could you document the new API in https://github.com/rust-analyzer/rust-analyzer/blob/master/docs/dev/lsp-extensions.md perhaps?

[popzxc]

Sure. I guess I'll do it this weekend, if it's not urgent.

[matklad]

Not urgent -- it would have been better for me not to miss this in the first place, but now there's no particular rush.

[matklad]

Couldn't resist: #6226