Context-specific RunConfigurations/tasks

[matklad]

On of the important features a language server can provide is an ability to run a one specific tests:

At the moment, VS Code has a way to query for workspace tasks via task provider, but it can't query context specific tasks.

Ie, what additional capability the language server has is that it can noticed that a function at the cursor has a specific annotation, which means that it is a test, which needs to be run in a specific way.

Currently, various extensions hack this functionality (like the above lens from rust-analyzer), but it would be cool if this was a "standardized" request.

Some considerations:

• all languages are "run" in a different way, so some client and langauge-specific running infrastructure is inevitable. The server should produce something like { "runner_id": string, args: any }. The simple "process" runner can be build-in of course.
• however, all languages can share at least label, kind (test/executable) and mode (run/debug).
• the typical "context" for getting configuration is text document and position, but it should also be possible to "run" files and folders, so the context needs to be generic. One of the cooler features of IntelliJ is that you can run test functions directly from "workspace symbol" view, because currently selected symbol is used as a context.
• configurations need some kind of persistence. For example, the user might run the current test with a shortcut, then edit the task by hand to set an environment variable, and then press the same shortcut again. So, the client needs to be able to tell if the new config from server and the old config from user refer in fact to conceptually same configuration. So, we need some kind of id field to compare different configurations.
• configurations apply for some range of the document, and, for example, running tests of a single function should be more specific than running tests for the whole module.
• configurations might want to use some kind of prototype/merging behavior. IE, the rust server could by default generate cargo test -- $test_name command line, but the user might want to add extra arguments, like cargo test --target target_triple -- $test_name to each generated configuration. A natural UI here is to let the users specify a template configuration, which is cloned and extended by the server.

The sketch of the API would look like this:

type Directory = Uri
type RunConfigurationContext = TextDocumentPositionParams | TextDocument | Directory

interface RunConfiguration {
    label: string,
    kind: "test" | "executable",
    mode: "debug" | "run",
    id: string,
    range?: TextRange,
    identifier_range?: TextRange

    runner: string,
    runner_args: any,
}

function runConfigurations(ctx: RunConfigurationContext): RunConfiguration[] {
    
}

cc @DanTup I think Dart server has something for running things in the specific context?

[yyoncho]

also this: https://github.com/Microsoft/vscode-java-test

[DanTup]

@DanTup I think Dart server has something for running things in the specific context?

Yeah, right now the stable version of the Dart extension is not using LSP so this is handled on the client. However I do have a WIP LSP branch, and this is again being handled on the client (we use custom LSP notifications to get the required info for the client to build the code-lens, and then start debug sessions with the right arguments).

For Dart, we're using real debug sessions (with a DAP debug adapter) and not just spawning processes (like tasks) though, so if the above is geared around tasks/running processes, it might not help here (though I'd be curious what debug would do in the example above). To switch Dart over, we'd need LSP code-lens to be able to return information that an editor could use to start a real debug session.

[matklad]

To switch Dart over, we'd need LSP code-lens to be able to return information that an editor could use to start a real debug session.

Yep, that's precisely why we need runner_id and any as arguments, so that you could express arbitrary custom way to launch a thing. If DAP has some specific way to initiate a debug session, we can also build-in a dap runner_id into the protocol.

[dbaeumer]

Would someone be willing to work on a proposal including an implementation for VS Code ?

[matklad]

I personally won't be actively pushing this forward in the nearest future. However, I am interested in this feature, so I eventually I'd probably do it, if no one beats me to it.

[matklad]

Our current semi-general version is documented here:

https://github.com/matklad/rust-analyzer/blob/bc3db7c1ded0db2d3804b5ac3e5c35dd53350228/docs/dev/lsp-extensions.md#runnables

[dbaeumer]

The feature has not gain any traction in the community. I therefore close the issue. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[kirawi]

@matklad
There is https://github.com/build-server-protocol/build-server-protocol

[matklad]

I think the feature here needs support from both LSP and DAP. It's up to LSP to say "at the current currsor position, there's a fucntion test_foo annotated as a test in a module bar" -- figuring out whether something's a test requires semantic analysis of the source code (the test annotation might be generated by a macro or something).

Given a test function, figuring out the appropriate build command to run it is indeed something which DAP can handle.