Note: Highly suggest making this a dotfile (.rust-analyzer.toml). This would be aligned with other project-specific modifier configs such as .rustfmt.toml and .rusty-hook.toml, etc.

My usecase here is that I have a compiler_error!() macro in my project used for prevent builds if a target config isn't set up correctly (this is an edge-case, embedded project - not a typical library) that is #[cfg()]-gated. r-a chokes on it because it doesn't ever run with the correct target settings, making the some IDEs get really, really upset about things.

Having a per-project config file for r-a would allow me to specify a feature for analysis such as rust-analyzer or something like that that can be included in the #[cfg()] in order to avoid triggering such checks during analysis (but not in builds).

Yes please. We need something like this to provide proper integration with our build system and right now we can only provide that for vscode which is unfortunate.

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.

FWIW clangd has this feature (.clangd files) so may be worth checking out.

How does the priority work in regards to other mechanisms that set configurations?

Doesn't this depend on how the client sends configs at all? Does r-a get its configuration via the client, or from the filesystem? If the former, then it's up to the client implementations to specify this. Ideally each would allow the user to specify the priorities of the searched configs, be able to merge them based on this, and then send the flattened config to r-a. I don't see how that's r-a's problem, really.

How would r-a look for these, is nesting allowed, that is can we have hierarchies for these files?

I don't think nesting is necessary. Keeping it clean and simple is probably the best route. It would also make debugging easier. (Again, this assumes that r-a is getting the config from the client directly, not from scouring the source tree etc.)

What configs should be exposed in this

If the above are true, then is this really a fix for r-a directly? It'd be up to the individual client implementations to handle these sort of semantics. Perhaps r-a could specify that .rust-analyzer.toml is a valid configuration spot and specify its syntax. Otherwise, the client libs should probably have the "sane" default of...

1. Any in-client overrides (directly specified in the config of the client)
2. Any user-local files (e.g. ~/.rust-analyzer.toml), if it exists
3. $(pwd)/.rust-analyzer.toml, if it exists
4. Some default set of configuration pertinent to getting r-a working in the respective client

As far as I understand, 1. and 4. are already the case. It's 2. and 3. that would have to be added.

Bonus points for allowing the user to specify search paths / their order for .rust-analyzer.toml files, allowing for both absolute and relative paths.

For anyone who wants a hack-and-slash workaround for Neovim that is non-standard, use this to initialize your init.vim:

function get_project_rustanalyzer_settings()
  local handle = io.open(vim.fn.resolve(vim.fn.getcwd() .. '/./.rust-analyzer.json'))
  if not handle then
    return {}
  end
  local out = handle:read("*a")
  handle:close()
  local config = vim.json.decode(out)
  if type(config) == "table" then
    return config
  end
  return {}
end

local lspflags = {
  rust_analyzer = {
    settings = {
      ['rust-analyzer'] = vim.tbl_deep_extend(
        "force",
        {
          -- Defaults (can be overridden by .rust-analyzer.json
        },
        get_project_rustanalyzer_settings(),
        {
          -- Overrides (forces these regardless of what's in .rust-analyzer.json
          procMacro = { enable = true },
          diagnostics = { disabled = {"inactive-code"} },
        }
      )
    }
  }
}

Then add a .rust-analyzer.json to your project (and either .gitignore it or add it to .git/info/exclude since it's non-standard):

{
        "cargo": {
                "features": [ "stm32f479" ]
        }
}

The downside is that this doesn't scan the directory hierarchy, so you have to open nvim from the directory that has the .rust-analyzer.json. I'll leave a hierarchy traversal modification to the code as an exercise to the reader 🙃 for now this works for me. A standardized way of doing this is still highly sought after, though.

My initial thought here was for the server to consume the rust-analyzer.toml, not the client. Having the client consume it seems pointless, as that requires any LSP client to add special support for the rust-analyzer.toml format and ideally, rust-analyzer should have a baseline usability with any LSP compliant client.

Doesn't this depend on how the client sends configs at all? Does r-a get its configuration via the client, or from the filesystem? If the former, then it's up to the client implementations to specify this. Ideally each would allow the user to specify the priorities of the searched configs, be able to merge them based on this, and then send the flattened config to r-a. I don't see how that's r-a's problem, really.

So effectively with this rust-analyzer.toml added, we would have two ways of receiving config data, by the client and then per-project (per cargo workspace, opened project folder or crate even etc). I think we should always prefer the rust-analyzer.toml settings in that regard, the main reason I raised this question was because VSCode for example has global settings and local project settings but we can only treat them as "the client settings" in one unit, but that should be fine I think. Also note that not all config settings exposed by r-a today would make sense in the rust-analyzer.toml, an example being cargo.autoreload.

Bonus points for allowing the user to specify search paths / their order for .rust-analyzer.toml files, allowing for both absolute and relative paths.

That's a good point to consider.

The other points you've raised are somewhat moot with the thought of the server consuming it (I shouldve been clearer on that in the issue description, will edit) I think.

Note: Highly suggest making this a dotfile (.rust-analyzer.toml). This would be aligned with other project-specific modifier configs such as .rustfmt.toml and .rusty-hook.toml, etc.

Allowing both rust-analyzer.toml and .rust-analyzer.toml seems fine to me (and given rustfmt consumes either forms as well it would only make sense for us to do the same)

I remember another request for allowing Rust Analyzer to work without Cargo.toml aka over a
single file, I believe some config options were still required could we add them to rust-analyzer.toml would make scripting very easy if we could also have a rust-analyzer.toml globally. For say default custom global configuration?

And ensure that we use Cargo.toml or folder-local config only if they are present?

Yes that somewhat plays into the third checkbox point, how r-a will look for the file and if nesting is allowed.

@rustbot claim

So I am claiming this issue just to let everyone know that someone is working on it, although this won't be my number one priority for the first couple of weeks. If someone makes any progress within this time frame, please share it.

Here is more or less a roadmap that I plan to follow : (The two names that I use here global and local are not very descriptive and probably will be changed to something more meaningful so do not mind them for now. And let .rust-analyzer.toml be RATOML for the time being. )

• Find out which configs are globally or locally-scoped. Create a PR where we possibly publish a document in which we briefly mention why a certain key-value pair is global or local.
• Replace rust_analyzer::config::ConfigData with GlobalConfigData LocalConfigData. As a result of this change rust_analyzer::config::Config's data will be of type GlobalConfigData. project_model::ProjectManifest is a good place to handle the discovery of the .rust-analyzer.toml file and finding out which configurations apply to a single ProjectManifest. This change will probably entail adding two more variants to ProjectManifest like ProjectManifest::ProjectJsonWithConf and ProjectManifest::CargoTomlWithConf. As I said before names are at this point arbitrary.
• Client settings and RATOML : During first handshakes between the server and the client config data are sent from the client to the server, which is how we have received configuration data so far. I plan to keep this as is and let server do a fresh start if any RATOML files are discovered. But this shouldn't tell you that the configs sent from the client have a higher priority than RATOML. Although I agree with @Veykril on the point that our hand is forced to choose either RATOML or client settings over another, the user should still be able to say that they want to use their own configs, which means that we need to add a KV pair that does just that : telling us which source we should prefer.
• First version of the RATOML : Although I may have sounded like this is something I want to have ready in the first version, I think we should first enable the use of a single RATOML file and gradually introduce nesting. So this version will use two sources to read configs from : (1) lsp_types::InitializeParams as sent by the client (2) RATOML.

What does global and local solve? Why not just use a list of configs that overwrite each other in order, as I mentioned before?

There are some configurations for which overwriting doesn't make much sense and can even be misleading. An example would be rust-analyzer.cachePriming.enable which states whether to Warm up caches on project load. ( this example may also be the wrong example I am not super sure about it but the point I am trying to make is that some configs are different from other in that they should be configured once). As to what goes in the RATOML there is no difference between globals and locals, they are configured exactly the same way it is just that for a global you can still nest it but only its first occurrence counts.

I still don't see why global vs local makes more sense than multiple configs. Who cares if a second config overwrites the first in some weird way? That's on the user at that point.

(That distinction came from a discussion Ali and I had elsewhere)

It is more that there a configs that apply to the server session as a whole and then there are configs that apply to individually loaded projects. There are also configs that do not make sense to be in the rust-analyzer.toml at all, like all the hover configs for example. Those are project irrelevant so they won't be configurable by the r-a toml file.

Though having a second look at things, I don't think there are configs that can't be applied on a per loaded project level (opposed to server session wide), aside from current implementation reasons maybe (files.watcher would be a server wide one, but at the same time that one should not be configured by the rust-analyzer.toml). So ye, the first step here is to classify all the current configs into the three buckets not applicable for rust-analyzer.toml, project/cargo workspace applicable and "global"/session wide. Then we can see whether that split makes sense or not.