Stdlib macro expansion broken on nightly

[ra2-andor-u]

Disclosure: I used Claude to diagnose my issue but the report below is written by me, and Claude's findings make sense to me.

I use Zed as my editor which regularly downloads a recent, standalone, nightly version of r-a. Today it downloaded the 2026-07-20 nightly and I started getting type checking errors in places where stdlib macros are used in return position, e.g.

fn foo() -> String {
    format!("hello")
}

r-a would report as an error, saying it expected a String but got () instead. This is clearly wrong, and trying cargo check, clippy or actually compiling the code gave no errors or warnings.

I asked Claude to help find why r-a is showing macro invocations as () everywhere. At first it had some false starts, but then later it realized that the project in question is pinned to 1.92. It pointed me to #22784 as the PR that breaks resolution for stdlib macros for codebases pinned to <1.94, which makes sense to me.

The comment in that PR says "we only officially support that last stdlib, so I think it's fine to just not support older versions" which leads me to believe my setup (pinned toolchain, but running a recent r-a version) is an unsupported setup, however the current situation/resulting error message is very confusing. At least in zed these show up as "wrong type" errors. If this is an unsupported setup then r-a should warn about it at least.

Repro:

# rust-toolchain.toml
[toolchain]
channel = "1.92.0"

// src/main.rs
fn greet() -> String {
    format!("hello")
}
fn main() {
    println!("{}", greet());
}

~/.local/share/zed/languages/rust-analyzer/rust-analyzer-2026-07-20 diagnostics .
at crate ra_repro, file /tmp/ra-repro/src/main.rs: Error RustcHardError("unresolved-macro-call") from LineCol { line: 1, col: 4 } to LineCol { line: 1, col: 10 }: unresolved macro `format!`
at crate ra_repro, file /tmp/ra-repro/src/main.rs: Error RustcHardError("E0308") from LineCol { line: 2, col: 0 } to LineCol { line: 2, col: 1 }: expected String, found ()
at crate ra_repro, file /tmp/ra-repro/src/main.rs: Error RustcHardError("unresolved-macro-call") from LineCol { line: 5, col: 4 } to LineCol { line: 5, col: 11 }: unresolved macro `println!`

diagnostic scan complete

Error: diagnostic error detected

Stack backtrace:
   0: std::sys::backtrace::__rust_begin_short_backtrace::<<stdx::thread::Builder>::spawn<<rust_analyzer::cli::flags::Diagnostics>::run::{closure#0}, core::result::Result<(), anyhow::Error>>::{closure#0}, core::result::Result<(), anyhow::Error>>
   1: <std::thread::lifecycle::spawn_unchecked<<stdx::thread::Builder>::spawn<<rust_analyzer::cli::flags::Diagnostics>::run::{closure#0}, core::result::Result<(), anyhow::Error>>::{closure#0}, core::result::Result<(), anyhow::Error>>::{closure#1} as core::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
   2: <std::sys::thread::unix::Thread>::new::thread_start
   3: <unknown>
   4: <unknown>

[ChayimFriedman2]

It is unsupported indeed, although warning on unsupported versions will be nice. The problem is that we do somewhat try to support older versions whenever possible, so it's not always "you operate a non-last version so you'll have problems".

You can make r-a use the latest standard library without affecting rustc by setting { "rust-analyzer.server.extraEnv": { "RUSTUP_TOOLCHAIN": "stable" } }.

[Rapptz]

For anyone who suffers this problem and doesn't want to upgrade their toolchain to a newer version because of different MSRV or whatever other reason you can currently work around this by explicitly qualifying the macros with std::, e.g. std::println!. It's an admittedly goofy fix but it's better than everything currently breaking for those of us on older toolchains.

[ChayimFriedman2]

@Rapptz There are better fixes:

If you cannot upgrade rustc, you can try ordering r-a to behave as if rustc was new - see https://rust-analyzer.github.io/book/installation.html#rust-standard-library. If that also does not work, you need to downgrade your r-a. A r-a attached to your rustup toolchain will usually work.