Seemingly incompatible design between rust-project.json and checkOnSave.overrideCommand

Hey all!

I have a couple of questions:

1. Is it expected that in a code base where with Cargo you would have many Cargo.toml files spread across multiple folders, you only use one rust-project.json?
2. Is there a way to give some info on what file we want to "cargo check" (i.e. what file triggered the invocation of checkOnSave.overrideCommand)? For example, passing it as an argument to checkOnSave.overrideCommand.

My personal investigation has reached "yes, you should have only one rust-project.json" for 1.:

• in rust-project.json you reference deps with their index in the array for the same rust-project.json file, and I don't know how this could be compatible with multiple rust-project.jsons
• trying to run rust-analyzer with multiple rust-project.jsons doesn't work - e.g. cross rust-project.json goto def doesn't work

and "no" for 2.:

• it seems that nothing dynamic is passed to the executable when it's run (in the source code) - only the presupplied args and the environment from checkOnSave.extraEnv are passed, which both appear to be static

This combination is very unfortunate, because now, there is no way for the tool that's going to be used instead of cargo check to know what it should be building - in a huge repo, this is not viable.

I assume that when we're using cargo this "what should I build" issue is resolved by the fact that cargo check is run in the root of the workspace, which is determined by a Cargo.toml file. However, in the rust-project.json, this is no longer a solution, because we can have only one rust-project.json file, hence in order to be correct, the only thing checkOnSave.overrideCommand could do is build everything in the workspace.

My proposed solutions are to do one of

• "fix" 2. so that we pass some info to checkOnSave.overrideCommand (seems to be much easier)
• "fix" 1. to allow autodiscovery and combining of rust-project.json files - seems to be much more difficult to implement, but perhaps it's a better approach in the long run, so that the assumptions made for cargo based projects are also valid for rust-project.json based ones?

I would be happy to implement some version of "fix" 2., if we could come to an agreement on what that would be.

Context:
I'm trying to implement diagnostics support for rust-analyzer+rules_rust, which relies on checkOnSave.overrideCommand/cargo check.

Review how rust-project.json and checkOnSave.overrideCommand are handled, including the configuration used for rules_rust diagnostics. Clarify whether multiple project files or dynamic information about the triggering file should be supported, then define the agreed behavior and validation needed before implementing it.