Merge branch 'main' into prog

Author: UebelAndre

.bazelci/presubmit.yml

@@ -885,7 +885,7 @@ tasks:
     build_flags:
       - "--compile_one_dependency"
     build_targets:
-      - "tools/rust_analyzer/main.rs"
+      - "tools/rust_analyzer/bin/gen_rust_project.rs"
   extensions_bindgen_linux:
     platform: ubuntu2004
     name: Extensions Bindgen

.gitignore

@@ -30,6 +30,9 @@ user.bazelrc
 .vscode
 *.code-workspace
 
+# zed
+.zed
+
 # JetBrains
 .idea
 .idea/**

MODULE.bazel

@@ -22,6 +22,7 @@ use_repo(
     internal_deps,
     "rrra",
     "rrra__anyhow-1.0.71",
+    "rrra__camino-1.1.9",
     "rrra__clap-4.3.11",
     "rrra__env_logger-0.10.0",
     "rrra__itertools-0.11.0",

docs/rust_analyzer.vm

@@ -2,10 +2,12 @@
 ## Overview
 
 For [non-Cargo projects](https://rust-analyzer.github.io/manual.html#non-cargo-based-projects),
-[rust-analyzer](https://rust-analyzer.github.io/) depends on a `rust-project.json` file at the
-root of the project that describes its structure. The `rust_analyzer` rule facilitates generating
-such a file.
+[rust-analyzer](https://rust-analyzer.github.io/) depends on either a `rust-project.json` file 
+at the root of the project that describes its structure or on build system specific 
+[project auto-discovery](https://rust-analyzer.github.io/manual.html#rust-analyzer.workspace.discoverConfig).
+The `rust_analyzer` rules facilitate both approaches.
 
+## rust-project.json approach
 ### Setup
 
 First, ensure `rules_rust` is setup in your workspace. By default, `rust_register_toolchains` will
@@ -84,4 +86,71 @@ build --@rules_rust//rust/settings:rustc_output_diagnostics=true --output_groups
 
 Then you can use a prototype [rust-analyzer plugin](https://marketplace.visualstudio.com/items?itemName=MattStark.bazel-rust-analyzer) that automatically collects the outputs whenever you recompile.
 
-]]#
+## Project auto-discovery
+### Setup
+
+Auto-discovery makes `rust-analyzer` behave in a Bazel project in a similar fashion to how it does
+in a Cargo project. This is achieved by generating a structure similar to what `rust-project.json` 
+contains but, instead of writing that to a file, the data gets piped to `rust-analyzer` directly 
+through `stdout`. To use auto-discovery the `rust-analyzer` IDE settings must be configured similar to:
+
+```json
+"rust-analyzer": {
+    "workspace": {
+        "discoverConfig": {
+            "command": ["discover_bazel_rust_project.sh"],
+            "progressLabel": "rust_analyzer",
+            "filesToWatch": ["BUILD", "BUILD.bazel", "MODULE.bazel"]
+        }
+    }
+}
+```
+
+The shell script passed to `discoverConfig.command` is typically meant to wrap the bazel rule invocation,
+primarily for muting `stderr` (because `rust-analyzer` will consider that an error has occurred if anything 
+is passed through `stderr`) and, additionally, for specifying rule arguments. E.g:
+
+```shell
+#!/usr/bin/bash
+
+bazel \
+    run \
+    @rules_rust//tools/rust_analyzer:discover_bazel_rust_project -- \
+    --bazel_startup_option=--output_base=~/ide_bazel \
+    --bazel_arg=--watchfs \
+    ${1:+"$1"} 2>/dev/null
+```
+
+The script above also handles an optional CLI argument which gets passed when workspace splitting is
+enabled. The script path should be either absolute or relative to the project root.
+
+### Workspace splitting
+
+The above configuration treats the entire project as a single workspace. However, large codebases might be
+too much to handle for `rust-analyzer` all at once. This can be addressed by splitting the codebase in 
+multiple workspaces by extending the `discoverConfig.command` setting:
+
+```json
+"rust-analyzer": {
+    "workspace": {
+        "discoverConfig": {
+            "command": ["discover_bazel_rust_project.sh", "{arg}"],
+            "progressLabel": "rust_analyzer",
+            "filesToWatch": ["BUILD", "BUILD.bazel", "MODULE.bazel"]
+        }
+    }
+}
+```
+
+`{arg}` acts as a placeholder that `rust-analyzer` replaces with the path of the source / build file
+that gets opened.
+
+The root of the workspace will, in this configuration, be the package the crate currently being worked on
+belongs to. This means that only that package and its dependencies get built and indexed by `rust-analyzer`, 
+thus allowing for a smaller footprint. 
+
+`rust-analyzer` will switch workspaces whenever an out-of-tree file gets opened, essentially indexing that
+crate and its dependencies separately. A caveat of this is that *dependents* of the crate currently being 
+worked on are not indexed and won't be tracked by `rust-analyzer`.
+
+]]#

examples/crate_universe/MODULE.bazel

@@ -603,7 +603,8 @@ use_repo(
     "crates_vendor_pkgs__tracing-0.1.41",
     "crates_vendor_pkgs__tracing-subscriber-0.3.19",
     "cvm",
-    "cvm__tempfile-3.19.0",
+    "cvm__serde_yaml-0.9.34-deprecated",
+    "cvm__tempfile-3.19.1",
     "cvm__tokio-1.44.1",
     "cvm__tokio-test-0.4.4",
 )

examples/crate_universe/vendor_remote_manifests/Cargo.toml

@@ -6,6 +6,9 @@ edition = "2018"
 
 [dependencies]
 tokio = { version = "1.17.0", features = ["full"] }
+# the full version is "0.9.34+deprecated
+# to prevent regressions of the - and + replacements
+serde_yaml = "=0.9.34"
 
 [dev-dependencies]
 tempfile = "3.2.0"