rust-analyzer.toml

[Veykril]

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.

[Qix-]

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).

[emilio]

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.

[Qix-]

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.

[Veykril]

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.

[Veykril]

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)

[swarnimarun]

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?