Unnamed repository; edit this file 'description' to name the repository.
Fix URLs and highlighting in manual
Wilfred Hughes 5 months ago
parent 2133d66 · commit 1ce8ab3
-rw-r--r--crates/rust-analyzer/src/config.rs2
-rw-r--r--docs/book/src/configuration.md22
-rw-r--r--docs/book/src/configuration_generated.md2
-rw-r--r--docs/book/src/contributing/architecture.md2
-rw-r--r--docs/book/src/contributing/debugging.md10
-rw-r--r--docs/book/src/contributing/guide.md2
-rw-r--r--docs/book/src/contributing/lsp-extensions.md26
-rw-r--r--editors/code/package.json2
8 files changed, 35 insertions, 33 deletions
diff --git a/crates/rust-analyzer/src/config.rs b/crates/rust-analyzer/src/config.rs
index 1b15d831df..ec805db1a5 100644
--- a/crates/rust-analyzer/src/config.rs
+++ b/crates/rust-analyzer/src/config.rs
@@ -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,
}
}
diff --git a/docs/book/src/configuration.md b/docs/book/src/configuration.md
index 708eecd435..789ceb4ca0 100644
--- a/docs/book/src/configuration.md
+++ b/docs/book/src/configuration.md
@@ -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
diff --git a/docs/book/src/configuration_generated.md b/docs/book/src/configuration_generated.md
index f0da2bdd86..fe1ea57c9b 100644
--- a/docs/book/src/configuration_generated.md
+++ b/docs/book/src/configuration_generated.md
@@ -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}
diff --git a/docs/book/src/contributing/architecture.md b/docs/book/src/contributing/architecture.md
index 1cc13b3b96..f2b6c053b0 100644
--- a/docs/book/src/contributing/architecture.md
+++ b/docs/book/src/contributing/architecture.md
@@ -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**.
diff --git a/docs/book/src/contributing/debugging.md b/docs/book/src/contributing/debugging.md
index db3a28eed1..fcda664f5e 100644
--- a/docs/book/src/contributing/debugging.md
+++ b/docs/book/src/contributing/debugging.md
@@ -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
diff --git a/docs/book/src/contributing/guide.md b/docs/book/src/contributing/guide.md
index d06840368c..774eb5b2a5 100644
--- a/docs/book/src/contributing/guide.md
+++ b/docs/book/src/contributing/guide.md
@@ -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
diff --git a/docs/book/src/contributing/lsp-extensions.md b/docs/book/src/contributing/lsp-extensions.md
index 91154b6f1c..0e91e12612 100644
--- a/docs/book/src/contributing/lsp-extensions.md
+++ b/docs/book/src/contributing/lsp-extensions.md
@@ -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 }`
diff --git a/editors/code/package.json b/editors/code/package.json
index 4d1ae48c9d..c6b9b51528 100644
--- a/editors/code/package.json
+++ b/editors/code/package.json
@@ -3043,7 +3043,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": [
{