Optional features are part of the crate — the project should say so

When a crate defines an optional feature like mock, and there's a module behind #[cfg(feature = "mock")], that code is part of the crate. It compiles. It’s tested. It’s documented. It’s not an afterthought — it’s intentional.

But when someone opens the project, that code is often grayed out. The file shows up as “not included in any crates.” Go-to-def doesn’t work. It’s as if it’s not there.

This isn’t because the code is optional. It’s because the project hasn’t said: “This feature is meant to be used.”

We already have a place for project-local intent: .cargo/config.toml. It’s where we set RUSTFLAGS, define targets, and configure environment variables. It’s version-controlled, shared, and respected by Cargo, build scripts, and tools.

And rust-analyzer already reads from it — whenever it sees [env].

So it’s natural for it to also express: “When analyzing this crate, these features are active.”

# .cargo/config.toml
[unstable]
rust-analyzer.cargo.features = "all"

or

[unstable]
rust-analyzer.cargo.features = ["mock"]

This doesn’t change how cargo build works. It doesn’t affect compilation. It just aligns analysis with the project’s intent — the same way [env] already does.

No setup. No terminal tricks. No editor-specific files.

If a feature exists and is meant to be used, the project should be able to say so — once, clearly, in the same place we already use for project configuration.

We already have the mechanism. This is just using it.