Read rust-analyzer configuration from Cargo.toml?

[cuviper]

Would it be possible to read configuration options from Cargo.toml? Then they could be specified in an editor-neutral way, something like:

[package.metadata.rust-analyzer.cargo]
noDefaultFeatures = true
features = ["foo", "bar"]

I think snake-case would be more idiomatic for Cargo.toml, but I don't know how deep we'd want to get into translating names. There's also a mismatch between the usual default_features = false and RA's noDefaultFeatures.

[lnicola]

Depending on the priorities, a possible downside here (for open-source projects) is that you might get the settings the project author likes, not what you'd like to use.

[cuviper]

True, and I would suggest it be used sparingly for that reason.

I was thinking along the lines of [package.metadata.docs.rs], which is relatively limited: https://docs.rs/about/metadata

[kjeremy]

Depending on the priorities, a possible downside here (for open-source projects) is that you might get the settings the project author likes, not what you'd like to use.

Could user specific overrides go into .cargo/config?

[lnicola]

Could user specific overrides go into .cargo/config?

Traditionally, cargo/.config is completely different from Cargo.toml.

[jonas-schievink]

.cargo/config sometimes gets checked into repos too

[matklad]

Tough question.

On the one hand, this is definitely an upstream issue. Configuration handling in LSP is just a mess, and "ability to share lsp config in an editor-agnostic way" is something that, imo, should be solved at the protocol level.

On the other hand, I doubt that this will ever be fixed upstream.

So we can do one of the following:

• punt on upstream and do nothing
• beat purity with practicality and support rust-analyzer.toml
• rebel against upstream, introduce lsp_config.toml and advertise it to authors of other LSP servers as well.

[flodiebold]

Configuration handling in LSP is just a mess, and "ability to share lsp config in an editor-agnostic way" is something that, imo, should be solved at the protocol level.

I feel like consistency with other Rust tooling would be more useful than consistency with other LSP servers anyway?

[therealprof]

I was just pointed to this issue since we've been having the discussion on the rust-embedded channel. I fully agree with the motivation and would like to second it.

Regarding the actual implementation, I'd very much favour:

• beat purity with practicality and support rust-analyzer.toml

That'd allow projects to check in a useful configuration (those actually do exist for embedded cases) and in other cases people to create their own preferred configuration without having to work around Cargo.toml modifications all the time.

[matklad]

Somewhat related, #6776 documents our current configs.

[flodiebold]

IMO we should go with rust-analyzer.toml (or maybe .rust-analyzer.toml).

[lnicola]

And maybe a separate setting that enables or disables support for it (to give users the final say, unless the project author overrides it in .vscode/settings.json 😕).

[matklad]

I do think that editor's preferences should override the .toml. Implementation wise, we'd need some way to prevent VS Code from stomping over the config though -- it sends client-side defaults even if user's config is empty :(

[lilyball]

I really want something like this so I can enable features during development that aren't part of the default feature set. I work in a large workspace so I can't just turn them on in VSCode's Workspace settings as the features only apply to a specific crate within the workspace. So being able to read them from Cargo.toml or from a rust-analyzer.toml file would be extremely helpful.

And on that note, any such support for this does need to handle the case of a project within a workspace (in my case, a virtual manifest workspace). Even if I have the whole workspace open in VSCode, rust-analyzer should pick up feature settings on a per-crate basis for each workspace member.

[lnicola]

@Veykril should we close this in favor of #13529?

[Veykril]

Yes, I think everything in here has been noted down in that issue (except for one small thing that I'll add).