`rust_analyzer` is an unexpected cfg condition

[coolcatcoder]

Code

#![cfg(rust_analyzer)]

Current output

warning: unexpected `cfg` condition name: `rust_analyzer`
 --> src/lib.rs:1:8
  |
1 | #![cfg(rust_analyzer)]
  |        ^^^^^^^^^^^^^
  |
  = help: expected names are: `docsrs`, `feature`, and `test` and 32 more
  = help: consider using a Cargo feature instead
  = help: or consider adding in `Cargo.toml` the `check-cfg` lint config for the lint:
           [lints.rust]
           unexpected_cfgs = { level = "warn", check-cfg = ['cfg(rust_analyzer)'] }
  = help: or consider adding `println!("cargo::rustc-check-cfg=cfg(rust_analyzer)");` to the top of the `build.rs`
  = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration
  = note: `#[warn(unexpected_cfgs)]` on by default

Desired output

Rationale and extra context

Rust analyzer should be in the list of known cfgs, given that it works out of the box.

Rust Version

rustc 1.99.0-nightly (1a98b1e13 2026-08-07)
binary: rustc
commit-hash: 1a98b1e135b254f209c67d447b6d8bcd56a859e0
commit-date: 2026-08-07
host: x86_64-unknown-linux-gnu
release: 1.99.0-nightly
LLVM version: 23.1.0

Anything else?

No response

[Urgau]

Rust analyzer should be in the list of known cfgs, given that it works out of the box.

What do you mean by "works out of the box"? As far as I know it's only set by rust analyzer, not but rustc or Cargo, that requires using Rust analyzer.

[coolcatcoder]

rustfmt doesn't trigger this lint and is also an external tool like rust analyzer.
Either none or both should be linted.

[Urgau]

One of the reason we have used in the past for inclusion in the list of well know names and values is the number of usage of said cfgs in the wild (particularly for tools).

I'm only seeing 227 files referencing it, and they all of the case seems pretty happy to either add the cfg to list or allow the lint.

rustfmt doesn't trigger this lint and is also an external tool like rust analyzer.

rustfmt is was been trigger thousands of times in the Crater run we did, and we didn't wanted to force everyone to add the cfg to the well know list, in particular since rustfmt is the de-facto tool (while rust-analyzer isn't).

There isn't currently a way to unset a builtin cfg, so if we added it, every user would have it, including users who would never use it, like RustRover users, I don't think that's something we want.

[Urgau]

cc @rust-lang/rust-analyzer in case you want to add something

[ChayimFriedman2]

We have the rust_analyzer:: tool namespace (and we use it in rust-analyzer), I think this is equivalent (except that here it's only a warning you can silence - but not if you're a library).

Also - if we do introduce it as a built-in cfg, what will people not using it lose? Do you think there is a chance of using it by mistake? After all the purpose of check-cfg is to detect wrong cfg usage.

in particular since rustfmt is the de-facto tool (while rust-analyzer isn't)

But it is the only official tool for its purpose, even if there are competitors.

[Urgau]

The rust_analyzer tool namespace is indeed a good parallel, I didn't know the compiler had it as built-in, that seems like a sufficient precedent in it-self to add rust_analyzer as an well known cfg.

[Urgau]

If someone to give it a go, the cfg should be added around here:

• rust/compiler/rustc_session/src/config/cfg.rs

  Lines 386 to 394 in 7088e4b

  	// These four are never set by rustc, but we set them anyway; they
  	// should not trigger the lint because `cargo clippy`, `cargo doc`,
  	// `cargo test`, `cargo miri run` and `cargo fmt` (respectively)
  	// can set them.
  	ins!(sym::clippy, no_values);
  	ins!(sym::doc, no_values);
  	ins!(sym::doctest, no_values);
  	ins!(sym::miri, no_values);
  	ins!(sym::rustfmt, no_values);

• with a test in tests/ui/check-cfg/well-known-values.rs