mirror of
https://github.com/rust-lang/rust-analyzer.git
synced 2025-12-27 16:07:46 +00:00
Merge pull request #21156 from Wilfred/manual_formatting
Fix formatting issues in manual
This commit is contained in:
Chayim Refael Friedman
GitHub
commit
36fa19936b
@ -562,7 +562,7 @@ config_data! {
|
||||
/// `DiscoverArgument::Path` is used to find and generate a `rust-project.json`, and
|
||||
/// therefore, a workspace, whereas `DiscoverArgument::buildfile` is used to to update an
|
||||
/// existing workspace. As a reference for implementors, buck2's `rust-project` will likely
|
||||
/// be useful: https://github.com/facebook/buck2/tree/main/integrations/rust-project.
|
||||
/// be useful: <https://github.com/facebook/buck2/tree/main/integrations/rust-project>.
|
||||
workspace_discoverConfig: Option<DiscoverWorkspaceConfig> = None,
|
||||
}
|
||||
}
|
||||
|
||||
@ -26,16 +26,18 @@ value.
|
||||
For example, a very common configuration is to enable proc-macro
|
||||
support, can be achieved by sending this JSON:
|
||||
|
||||
{
|
||||
"cargo": {
|
||||
"buildScripts": {
|
||||
"enable": true,
|
||||
},
|
||||
},
|
||||
"procMacro": {
|
||||
"enable": true,
|
||||
}
|
||||
}
|
||||
```json
|
||||
{
|
||||
"cargo": {
|
||||
"buildScripts": {
|
||||
"enable": true,
|
||||
},
|
||||
},
|
||||
"procMacro": {
|
||||
"enable": true,
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Please consult your editor’s documentation to learn more about how to
|
||||
configure [LSP
|
||||
|
||||
@ -1630,7 +1630,7 @@ Similarly, the JSON representation of `DiscoverArgument::Buildfile` is:
|
||||
`DiscoverArgument::Path` is used to find and generate a `rust-project.json`, and
|
||||
therefore, a workspace, whereas `DiscoverArgument::buildfile` is used to to update an
|
||||
existing workspace. As a reference for implementors, buck2's `rust-project` will likely
|
||||
be useful: https://github.com/facebook/buck2/tree/main/integrations/rust-project.
|
||||
be useful: <https://github.com/facebook/buck2/tree/main/integrations/rust-project>.
|
||||
|
||||
|
||||
## rust-analyzer.workspace.symbol.search.excludeImports {#workspace.symbol.search.excludeImports}
|
||||
|
||||
@ -120,7 +120,7 @@ See [#93](https://github.com/rust-lang/rust-analyzer/pull/93) for an example PR
|
||||
**Architecture Invariant:** `syntax` crate is completely independent from the rest of rust-analyzer. It knows nothing about salsa or LSP.
|
||||
This is important because it is possible to make useful tooling using only the syntax tree.
|
||||
Without semantic information, you don't need to be able to _build_ code, which makes the tooling more robust.
|
||||
See also https://mlfbrown.com/paper.pdf.
|
||||
See also <https://mlfbrown.com/paper.pdf>.
|
||||
You can view the `syntax` crate as an entry point to rust-analyzer.
|
||||
`syntax` crate is an **API Boundary**.
|
||||
|
||||
|
||||
@ -57,13 +57,13 @@ To apply changes to an already running debug process, press <kbd>Ctrl+Shift+P</k
|
||||
|
||||
- Go back to the `[Extension Development Host]` instance and hover over a Rust variable and your breakpoint should hit.
|
||||
|
||||
If you need to debug the server from the very beginning, including its initialization code, you can use the `--wait-dbg` command line argument or `RA_WAIT_DBG` environment variable. The server will spin at the beginning of the `try_main` function (see `crates\rust-analyzer\src\bin\main.rs`)
|
||||
If you need to debug the server from the very beginning, including its initialization code, you can use the `--wait-dbg` command line argument or `RA_WAIT_DBG` environment variable. The server will spin at the beginning of the `try_main` function (see `crates/rust-analyzer/src/bin/main.rs`)
|
||||
|
||||
```rust
|
||||
let mut d = 4;
|
||||
while d == 4 { // set a breakpoint here and change the value
|
||||
d = 4;
|
||||
}
|
||||
let mut d = 4;
|
||||
while d == 4 { // set a breakpoint here and change the value
|
||||
d = 4;
|
||||
}
|
||||
```
|
||||
|
||||
However for this to work, you will need to enable debug_assertions in your build
|
||||
|
||||
@ -7,7 +7,7 @@ This guide describes the current state of rust-analyzer as of the 2024-01-01 rel
|
||||
architectural solutions related to the problem of building IDE-first compiler
|
||||
for Rust. There is a video version of this guide as well -
|
||||
however, it's based on an older 2019-01-20 release (git tag [guide-2019-01]):
|
||||
https://youtu.be/ANKBNiSWyfc.
|
||||
<https://youtu.be/ANKBNiSWyfc>.
|
||||
|
||||
[guide-2019-01]: https://github.com/rust-lang/rust-analyzer/tree/guide-2019-01
|
||||
[2024-01-01]: https://github.com/rust-lang/rust-analyzer/tree/2024-01-01
|
||||
|
||||
@ -23,7 +23,7 @@ If you want to be notified about the changes to this document, subscribe to [#46
|
||||
|
||||
## Configuration in `initializationOptions`
|
||||
|
||||
**Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/567
|
||||
**Upstream Issue:** <https://github.com/microsoft/language-server-protocol/issues/567>
|
||||
|
||||
The `initializationOptions` field of the `InitializeParams` of the initialization request should contain the `"rust-analyzer"` section of the configuration.
|
||||
|
||||
@ -39,7 +39,7 @@ If a language client does not know about `rust-analyzer`'s configuration options
|
||||
|
||||
## Snippet `TextEdit`
|
||||
|
||||
**Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/724
|
||||
**Upstream Issue:** <https://github.com/microsoft/language-server-protocol/issues/724>
|
||||
|
||||
**Experimental Client Capability:** `{ "snippetTextEdit": boolean }`
|
||||
|
||||
@ -74,7 +74,7 @@ Any additional `TextDocumentEdit`s will only have edits which are `InsertTextFor
|
||||
|
||||
## `CodeAction` Groups
|
||||
|
||||
**Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/994
|
||||
**Upstream Issue:** <https://github.com/microsoft/language-server-protocol/issues/994>
|
||||
|
||||
**Experimental Client Capability:** `{ "codeActionGroup": boolean }`
|
||||
|
||||
@ -121,7 +121,7 @@ Invoking code action at this position will yield two code actions for importing
|
||||
|
||||
## Parent Module
|
||||
|
||||
**Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/1002
|
||||
**Upstream Issue:** <https://github.com/microsoft/language-server-protocol/issues/1002>
|
||||
|
||||
**Experimental Server Capability:** `{ "parentModule": boolean }`
|
||||
|
||||
@ -155,7 +155,7 @@ mod foo;
|
||||
|
||||
## Join Lines
|
||||
|
||||
**Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/992
|
||||
**Upstream Issue:** <https://github.com/microsoft/language-server-protocol/issues/992>
|
||||
|
||||
**Experimental Server Capability:** `{ "joinLines": boolean }`
|
||||
|
||||
@ -202,7 +202,7 @@ fn main() {
|
||||
|
||||
## On Enter
|
||||
|
||||
**Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/1001
|
||||
**Upstream Issue:** <https://github.com/microsoft/language-server-protocol/issues/1001>
|
||||
|
||||
**Experimental Server Capability:** `{ "onEnter": boolean }`
|
||||
|
||||
@ -297,7 +297,7 @@ SSR with query `foo($a, $b) ==>> ($a).foo($b)` will transform, eg `foo(y + 5, z)
|
||||
|
||||
## Matching Brace
|
||||
|
||||
**Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/999
|
||||
**Upstream Issue:** <https://github.com/microsoft/language-server-protocol/issues/999>
|
||||
|
||||
**Experimental Server Capability:** `{ "matchingBrace": boolean }`
|
||||
|
||||
@ -342,7 +342,7 @@ Moreover, it would be cool if editors didn't need to implement even basic langua
|
||||
|
||||
## Runnables
|
||||
|
||||
**Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/944
|
||||
**Upstream Issue:** <https://github.com/microsoft/language-server-protocol/issues/944>
|
||||
|
||||
**Experimental Server Capability:** `{ "runnables": { "kinds": string[] } }`
|
||||
|
||||
@ -854,7 +854,7 @@ Such actions on the client side are appended to a hover bottom as command links:
|
||||
|
||||
## Open Cargo.toml
|
||||
|
||||
**Upstream Issue:** https://github.com/rust-lang/rust-analyzer/issues/6462
|
||||
**Upstream Issue:** <https://github.com/rust-lang/rust-analyzer/issues/6462>
|
||||
|
||||
**Experimental Server Capability:** `{ "openCargoToml": boolean }`
|
||||
|
||||
@ -897,7 +897,7 @@ interface TestInfo {
|
||||
|
||||
## Hover Range
|
||||
|
||||
**Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/377
|
||||
**Upstream Issue:** <https://github.com/microsoft/language-server-protocol/issues/377>
|
||||
|
||||
**Experimental Server Capability:** { "hoverRange": boolean }
|
||||
|
||||
@ -924,7 +924,7 @@ Triggering a hover inside the selection above will show a result of `i32`.
|
||||
|
||||
## Move Item
|
||||
|
||||
**Upstream Issue:** https://github.com/rust-lang/rust-analyzer/issues/6823
|
||||
**Upstream Issue:** <https://github.com/rust-lang/rust-analyzer/issues/6823>
|
||||
|
||||
This request is sent from client to server to move item under cursor or selection in some direction.
|
||||
|
||||
@ -949,7 +949,7 @@ export const enum Direction {
|
||||
|
||||
## Workspace Symbols Filtering
|
||||
|
||||
**Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/941
|
||||
**Upstream Issue:** <https://github.com/microsoft/language-server-protocol/issues/941>
|
||||
|
||||
**Experimental Server Capability:** `{ "workspaceSymbolScopeKindFiltering": boolean }`
|
||||
|
||||
@ -983,7 +983,7 @@ const enum WorkspaceSymbolSearchKind {
|
||||
|
||||
## Client Commands
|
||||
|
||||
**Upstream Issue:** https://github.com/microsoft/language-server-protocol/issues/642
|
||||
**Upstream Issue:** <https://github.com/microsoft/language-server-protocol/issues/642>
|
||||
|
||||
**Experimental Client Capability:** `{ "commands?": ClientCommandOptions }`
|
||||
|
||||
|
||||
@ -3032,7 +3032,7 @@
|
||||
"title": "Workspace",
|
||||
"properties": {
|
||||
"rust-analyzer.workspace.discoverConfig": {
|
||||
"markdownDescription": "Enables automatic discovery of projects using [`DiscoverWorkspaceConfig::command`].\n\n[`DiscoverWorkspaceConfig`] also requires setting `progress_label` and `files_to_watch`.\n`progress_label` is used for the title in progress indicators, whereas `files_to_watch`\nis used to determine which build system-specific files should be watched in order to\nreload rust-analyzer.\n\nBelow is an example of a valid configuration:\n```json\n\"rust-analyzer.workspace.discoverConfig\": {\n \"command\": [\n \"rust-project\",\n \"develop-json\"\n ],\n \"progressLabel\": \"rust-analyzer\",\n \"filesToWatch\": [\n \"BUCK\"\n ]\n}\n```\n\n## On `DiscoverWorkspaceConfig::command`\n\n**Warning**: This format is provisional and subject to change.\n\n[`DiscoverWorkspaceConfig::command`] *must* return a JSON object corresponding to\n`DiscoverProjectData::Finished`:\n\n```norun\n#[derive(Debug, Clone, Deserialize, Serialize)]\n#[serde(tag = \"kind\")]\n#[serde(rename_all = \"snake_case\")]\nenum DiscoverProjectData {\n Finished { buildfile: Utf8PathBuf, project: ProjectJsonData },\n Error { error: String, source: Option<String> },\n Progress { message: String },\n}\n```\n\nAs JSON, `DiscoverProjectData::Finished` is:\n\n```json\n{\n // the internally-tagged representation of the enum.\n \"kind\": \"finished\",\n // the file used by a non-Cargo build system to define\n // a package or target.\n \"buildfile\": \"rust-analyzer/BUILD\",\n // the contents of a rust-project.json, elided for brevity\n \"project\": {\n \"sysroot\": \"foo\",\n \"crates\": []\n }\n}\n```\n\nIt is encouraged, but not required, to use the other variants on `DiscoverProjectData`\nto provide a more polished end-user experience.\n\n`DiscoverWorkspaceConfig::command` may *optionally* include an `{arg}`, which will be\nsubstituted with the JSON-serialized form of the following enum:\n\n```norun\n#[derive(PartialEq, Clone, Debug, Serialize)]\n#[serde(rename_all = \"camelCase\")]\npub enum DiscoverArgument {\n Path(AbsPathBuf),\n Buildfile(AbsPathBuf),\n}\n```\n\nThe JSON representation of `DiscoverArgument::Path` is:\n\n```json\n{\n \"path\": \"src/main.rs\"\n}\n```\n\nSimilarly, the JSON representation of `DiscoverArgument::Buildfile` is:\n\n```json\n{\n \"buildfile\": \"BUILD\"\n}\n```\n\n`DiscoverArgument::Path` is used to find and generate a `rust-project.json`, and\ntherefore, a workspace, whereas `DiscoverArgument::buildfile` is used to to update an\nexisting workspace. As a reference for implementors, buck2's `rust-project` will likely\nbe useful: https://github.com/facebook/buck2/tree/main/integrations/rust-project.",
|
||||
"markdownDescription": "Enables automatic discovery of projects using [`DiscoverWorkspaceConfig::command`].\n\n[`DiscoverWorkspaceConfig`] also requires setting `progress_label` and `files_to_watch`.\n`progress_label` is used for the title in progress indicators, whereas `files_to_watch`\nis used to determine which build system-specific files should be watched in order to\nreload rust-analyzer.\n\nBelow is an example of a valid configuration:\n```json\n\"rust-analyzer.workspace.discoverConfig\": {\n \"command\": [\n \"rust-project\",\n \"develop-json\"\n ],\n \"progressLabel\": \"rust-analyzer\",\n \"filesToWatch\": [\n \"BUCK\"\n ]\n}\n```\n\n## On `DiscoverWorkspaceConfig::command`\n\n**Warning**: This format is provisional and subject to change.\n\n[`DiscoverWorkspaceConfig::command`] *must* return a JSON object corresponding to\n`DiscoverProjectData::Finished`:\n\n```norun\n#[derive(Debug, Clone, Deserialize, Serialize)]\n#[serde(tag = \"kind\")]\n#[serde(rename_all = \"snake_case\")]\nenum DiscoverProjectData {\n Finished { buildfile: Utf8PathBuf, project: ProjectJsonData },\n Error { error: String, source: Option<String> },\n Progress { message: String },\n}\n```\n\nAs JSON, `DiscoverProjectData::Finished` is:\n\n```json\n{\n // the internally-tagged representation of the enum.\n \"kind\": \"finished\",\n // the file used by a non-Cargo build system to define\n // a package or target.\n \"buildfile\": \"rust-analyzer/BUILD\",\n // the contents of a rust-project.json, elided for brevity\n \"project\": {\n \"sysroot\": \"foo\",\n \"crates\": []\n }\n}\n```\n\nIt is encouraged, but not required, to use the other variants on `DiscoverProjectData`\nto provide a more polished end-user experience.\n\n`DiscoverWorkspaceConfig::command` may *optionally* include an `{arg}`, which will be\nsubstituted with the JSON-serialized form of the following enum:\n\n```norun\n#[derive(PartialEq, Clone, Debug, Serialize)]\n#[serde(rename_all = \"camelCase\")]\npub enum DiscoverArgument {\n Path(AbsPathBuf),\n Buildfile(AbsPathBuf),\n}\n```\n\nThe JSON representation of `DiscoverArgument::Path` is:\n\n```json\n{\n \"path\": \"src/main.rs\"\n}\n```\n\nSimilarly, the JSON representation of `DiscoverArgument::Buildfile` is:\n\n```json\n{\n \"buildfile\": \"BUILD\"\n}\n```\n\n`DiscoverArgument::Path` is used to find and generate a `rust-project.json`, and\ntherefore, a workspace, whereas `DiscoverArgument::buildfile` is used to to update an\nexisting workspace. As a reference for implementors, buck2's `rust-project` will likely\nbe useful: <https://github.com/facebook/buck2/tree/main/integrations/rust-project>.",
|
||||
"default": null,
|
||||
"anyOf": [
|
||||
{
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user