Deeper rust-analyzer Integration with Non-Cargo Build Systems

This issue connects several disparate issues and discussions, such as https://github.com/rust-lang/rust-analyzer/issues/13437, https://github.com/rust-lang/rust-analyzer/pull/13128, https://github.com/rust-lang/rust-analyzer/issues/12105, https://github.com/rust-lang/rust-analyzer/issues/13226, and several others that I'm probably missing. This issue will be a bit handy-wavy, but I think there's value in describing my ideal user experience, which is to make rust-analyzer work with Buck/Bazel/et. al. as just as well as if they were Cargo.

The Current State

My current employer has one of the largest monorepos in the world and uses the Buck build systemto manage the vast majority of Rust builds. At the moment, most users connect to a remote dev server via VS Code and have their VS Code workspace be at the root of the monorepo (these are largely immutable user behavior and expectations). They then run a small CLI that spits out a rust-project.json (e.g., rust-project develop //foo/bar/my-target) and work on their project from the root of the workspace. To get cargo check-style diagnostics, people need to manually invoke Buck with a check-flavored build as such: buck build :my-target[check].

Possible Improvements

In no particular order, since I see these as roughly equivalent in impact:

• After VS Code has activated the rust-analyzer extension (for instance, after the user has opened a Rust file), rust-analyzer-the-language-server should be able to delegate to an external tool (in my case, rust-project) that can query the build system for the owning TARGETs, generate a rust-project.json, and continue with the remainder of the rust-project.json-based workspace loading. This option would occur after rust-analyzer checks for a Cargo.toml or a rust-project.json, doesn't find them, and a "discover workspace" (name to be bikeshed!) command is defined.
• The flycheck crate should be configurable to run builds/checks through a non-Cargo-based build system. When I last looked at the flycheck crate, it didn't seem like a particularly difficult change, just one that nobody has gotten around to designing or implementing.
• All of the above features can be configured through a rust-analyzer.toml (which I don't believe has an issue), which can be placed at the root of the monorepo, which would reduce how many configuration forks I need to make for the rust-analyzer extension.

Start by reading the linked issues and pull request, then inspect the rust-project.json workspace-loading path and the flycheck crate. Consider how external workspace discovery, non-Cargo checks, and rust-analyzer.toml configuration relate to the existing VS Code activation flow. Done would require a decided scope and implementation plan covering the requested non-Cargo build-system integration.