Add an Optional `CargoTargetSpec`-like Data to rust-project.json

Motivations

Hi! I'm writing this issue not entirely convinced that it's the right approach, but I figured I'd at least open an issue for discussion/feedback. Anyways: We've added two fields to the rust-project.json format in the rust-analyzer/buck integration, which have been really useful. They are:

• a build_file corresponding to the BUCK file defining the crate(s), serving the same function that a ManifestPath does today in rust-analyzer.
• A target label corresponding to the build system's name of the crate (details: https://buck2.build/docs/concepts/glossary/#target-label), which is roughly a Buck/Bazel-flavored URI for a build target or a more user-visible version the package_flag method in crates/project-mode/src/cargo_workspace/CargoWorkspace.

We've added these fields because determining the ManifestPath and the owning targets on the fly by querying buck adds some non-trivial, perceptible latencies (200-300 milliseconds at the average, with some substantially higher latencies at the tail) in what users would otherwise expect to be a near-instant response. Similar operations in rust-analyzer are in the low single-digit milliseconds, to its immense credit!

I decided to open this issue to propose upstreaming these changes when I was working on adding generic runnable support[^1] and realized that a decent chunk of the information needed to successfully create a runnable (specifically, the manifest file) could be very easily added to a CargoTargetSpec via a rust-project.json, enabling a set of long-tail features and functionality that I've wanted to tackle in a Buck context but was blocked by either too-high latencies or rust-analyzer's lack of visibility into this information. These features include:

• The generic runnable support I mentioned above.
• Exposing a dependency explorer to rust-project.json-based projects, which require ManifestPath (c.f., https://github.com/rust-lang/rust-analyzer/pull/14931)
• With the knowledge that the current flycheck infrastructure is a hack (and the $saved_file interpolation is even more so), it might be feasible to replace that with building a specific CargoTargetSpec::package, which should have benefits for larger Cargo workspaces as well.
• This has (weirdly!) bothered me for a while, but it's be nice if the rust-analyzer status response showed workspace roots not as the folder the user has open, but rather, the manifest path of each indexed project/workspace.

Approach

I'd like to add an optional TargetSpec (renamed from CargoTargetSpec) to project_model/src/project_json/Crate, where any build system that opts into providing a TargetSpec would be required to provide all information that TargetSpec expects. My goal for providing this constraint is to minimize maintenance costs for rust-analyzer.

Alternatives/Caveats.

I worry about proposing this feature because I worry:

• it might be an unreasonable maintenance burden on rust-analyzer.
• it is a layering violation of the design goals of rust-project.json (in that the rust-project.json format is the lowered version of a cargo graph, and this would be introducing something that is conceptually adjacent to it.)

[^1]: Note that the current state of runnables can largely work if this line is commented out and the rust-buck-companion extension queries the owner of the file in question, but that's not an approach that I'd like to take because latencies of querying a build system are too high.

Start by reading project_model/src/project_json/Crate and the existing rust-project.json handling, then review the linked Buck integration fields and related runnable and dependency-explorer discussions. Done would mean agreeing on and implementing an optional TargetSpec contract that provides the required manifest and target information without imposing excessive maintenance or layering costs.