rust-analyzer.toml

This is a tracking issue/discussion for a potential rust-analyzer.toml. There have been a lot of requests for a per-project configuration in various issues, some clients like VSCode allow specifying settings per workspace, but usually these kinds of settings are not committed in a repo and are therefor usually not meant to necessarily configure r-a for the project specifically (like certain coding style settings, think of import merging etc.). Other related things might be requiring a special built procedure for a cargo project, prime example being https://github.com/rust-lang/rust which currently has a few suggested config lines in the dev guide which a user has to specify manually when they check out the repo locally, see https://rustc-dev-guide.rust-lang.org/building/suggested.html#configuring-rust-analyzer-for-rustc.

The idea is for the server to consume this file, so that you do not need a "rust-analyzer capable" LSP client to make use of it.

So there is clearly a need for a project config option like this, but here are few open questions.

• We could make use of the Cargo.toml metadata section instead, but that would only solve the problem for cargo based projects and it feels wrong to have certain settings in there opposed to a rust-analyzer.toml I believe.
  • I believe a rust-analyzer.toml to be the correct solution here.
• How does the priority work in regards to other mechanisms that set configurations? Ideally we'd favor a client's settings over rust-analyzer.toml, but we cannot know if a client sends us the default config for something or if its explicitly set, so we might have to bite the bullet and prefer rust-analyzer.toml.
• How would r-a look for these, is nesting allowed, that is can we have hierarchies for these files? We should probably stick to what other tools like rustfmt do in this regard. Hierarchies could pose an implementation problem though, as r-a only has global configurations (global in the sense of project wide, not per workspace). I am unsure how complex it would be to change that, so this might entail a bigger architecture change.
• What configs should be exposed in this
• We might want to allow to specifying search paths and their order for .rust-analyzer.toml files, allowing for both absolute and relative paths.