Spec better runnables

This commit is contained in:
Aleksey Kladov 2020-06-02 17:34:18 +02:00
parent 0303982119
commit a83ab820a4
4 changed files with 49 additions and 38 deletions

View file

@ -87,6 +87,9 @@ pub fn server_capabilities(client_caps: &ClientCapabilities) -> ServerCapabiliti
"ssr": true, "ssr": true,
"onEnter": true, "onEnter": true,
"parentModule": true, "parentModule": true,
"runnables": {
"kinds": [ "cargo" ],
},
})), })),
} }
} }

View file

@ -110,7 +110,7 @@ pub enum Runnables {}
impl Request for Runnables { impl Request for Runnables {
type Params = RunnablesParams; type Params = RunnablesParams;
type Result = Vec<Runnable>; type Result = Vec<Runnable>;
const METHOD: &'static str = "rust-analyzer/runnables"; const METHOD: &'static str = "experimental/runnables";
} }
#[derive(Serialize, Deserialize, Debug)] #[derive(Serialize, Deserialize, Debug)]

View file

@ -311,6 +311,50 @@ Moreover, it would be cool if editors didn't need to implement even basic langua
This is how `SelectionRange` request works. This is how `SelectionRange` request works.
* Alternatively, should we perhaps flag certain `SelectionRange`s as being brace pairs? * Alternatively, should we perhaps flag certain `SelectionRange`s as being brace pairs?
## Runnables
**Issue:** https://github.com/microsoft/language-server-protocol/issues/944
**Server Capability:** `{ "runnables": { "kinds": string[] } }`
This request is send from client to server to get the list of things that can be run (tests, binaries, `cargo check -p`).
**Method:** `experimental/runnables`
**Request:**
```typescript
interface RunnablesParams {
textDocument: TextDocumentIdentifier;
/// If null, compute runnables for the whole file.
position?: Position;
}
```
**Response:** `Runnable[]`
```typescript
interface Runnable {
label: string;
/// If this Runnable is associated with a specific function/module, etc, the location of this item
location?: LocationLink;
/// Running things is necessary technology specific, `kind` needs to be advertised via server capabilities,
// the type of `args` is specific to `kind`. The actual running is handled by the client.
kind: string;
args: any;
}
```
rust-analyzer supports only one `kind`, `"cargo"`. The `args` for `"cargo"` look like this:
```typescript
{
workspaceRoot?: string;
cargoArgs: string[];
executableArgs: string[];
}
```
## Analyzer Status ## Analyzer Status
**Method:** `rust-analyzer/analyzerStatus` **Method:** `rust-analyzer/analyzerStatus`
@ -399,39 +443,3 @@ interface InlayHint {
label: string, label: string,
} }
``` ```
## Runnables
**Method:** `rust-analyzer/runnables`
This request is send from client to server to get the list of things that can be run (tests, binaries, `cargo check -p`).
Note that we plan to move this request to `experimental/runnables`, as it is not really Rust-specific, but the current API is not necessary the right one.
Upstream issue: https://github.com/microsoft/language-server-protocol/issues/944
**Request:**
```typescript
interface RunnablesParams {
textDocument: TextDocumentIdentifier;
/// If null, compute runnables for the whole file.
position?: Position;
}
```
**Response:** `Runnable[]`
```typescript
interface Runnable {
/// The range this runnable is applicable for.
range: lc.Range;
/// The label to show in the UI.
label: string;
/// The following fields describe a process to spawn.
kind: "cargo" | "rustc" | "rustup";
args: string[];
/// Args for cargo after `--`.
extraArgs: string[];
env: { [key: string]: string };
cwd: string | null;
}
```

View file

@ -56,7 +56,7 @@ export interface Runnable {
executableArgs: string[]; executableArgs: string[];
}; };
} }
export const runnables = new lc.RequestType<RunnablesParams, Runnable[], void>("rust-analyzer/runnables"); export const runnables = new lc.RequestType<RunnablesParams, Runnable[], void>("experimental/runnables");
export type InlayHint = InlayHint.TypeHint | InlayHint.ParamHint | InlayHint.ChainingHint; export type InlayHint = InlayHint.TypeHint | InlayHint.ParamHint | InlayHint.ChainingHint;