{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicm7wnqwbjism54da3fppbjdh7nhkzlzq2sm4uy6xuuvqtd3zimly",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgumldgfh5z2"
  },
  "path": "/t/optional-features-are-part-of-the-crate-the-project-should-say-so/24069#post_15",
  "publishedAt": "2026-03-12T10:30:23.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "A hint from cargo.toml for rust-analyzer can be used to include optional features. But for that to make sense it should also benefit Cargo, and I don't know enough about Cargo's design to say if that's justified.\n\nRust-analyzer already has the ability to read project settings. It respects [env] from `.cargo/config.toml`. Though I believe it does so through Cargo, not by parsing the file directly (Somebody might confirm this). Since work on rust-analyzer support is experimental (could not make it work yet), it would make it easier to also read their own keys from `.cargo/config.toml`. The experiment does give me the idea that there is a demand for project-level config. I think my proposal is also an addition to the rust-analyzer config file.\n\nIn general, I think of it this way:\n\n  * Project intent -> shared defaults `.cargo/config.toml`\n  * User preference -> local settings `rust-analyzer.toml`\n  * Editor choice -> editor-specific settings (e.g. `.vscode/`, `.zed/`)\n\n\n\nAll three can be version controlled separately if preferred.\n\nProject-level config could go in `rust-analyzer.toml`, but then there's no clean distinction between a crate's suggestion and a user preference. As rust-analyzer already uses [env] from `.cargo/config.toml`, it makes sense to also use it to set defaults. Using a cargo config also works in workspaces.",
  "title": "Optional features are part of the crate — the project should say so"
}