-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add flexible configuration for runnables #5954
Conversation
8ebdf11
to
111e006
Compare
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 |
✌️ popzxc can now approve this pull request. To approve and merge a pull request, simply reply with |
111e006
to
4ebacf9
Compare
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. |
bors r+ |
Regarding
Yes - I think there is a use-case for this. E.g. there are configurations where you have to pass 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 |
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. |
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. |
Ah, @popzxc, could you document the new API in https://github.com/rust-analyzer/rust-analyzer/blob/master/docs/dev/lsp-extensions.md perhaps? |
Sure. I guess I'll do it this weekend, if it's not urgent. |
Not urgent -- it would have been better for me not to miss this in the first place, but now there's no particular rush. |
Couldn't resist: #6226 |
6253: Document change of 'cargo' Runnable kind in lsp-extensions.md r=lnicola a=popzxc As was requested in #5954 (comment) Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
This PR introduces two new configuration options for runnables:
overrideCargo
andcargoExtraArgs
.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.