RA in VS Code highlights `#[tokio::main]`as error despite successful compilation with nightly Rust

[Sandmeyer]

​​Environment:​​

• Rust toolchain: 1.91.0-nightly (809200ec9 2025-08-24)

• Editor: VS Code (latest stable)

• rust-analyzer: v0.3.2593,

• tokio = { version = "1.47.1", features = ["full"] }

​​Issue:​​

The #[tokio::main]macro is highlighted as an error in VS Code by rust-analyzer(red underline, error hint: "tokio::main: proc macro server error: Cannot create expander for ~\target\debug\deps\tokio_macros-0db0bbc0b2211d25.dll: unsupported metadata version 10"). However, the project compiles and runs successfully via cargo build/runon the same toolchain. This occurs even in minimal async examples:

#[tokio::main]
async fn main() {
    println!("Hello, tokio!");
}

​​Question:​​

Is this a known issue with RA + nightly + Tokio? Are there workarounds beyond suppressing the diagnostic?

[bjorn3]

Your rust-analyzer version is too old. It doesn't support the proc-macro ABI of the latest nightly rustc yet according to the error.

[cubewhy]

You can let vscode rust-analyzer plugin use the nightly rust-analyzer by doing this setting

"rust-analyzer.server.path": "/usr/lib/rustup/bin/rust-analyzer"

BTW, do not forget to install the nightly rust analyzer

rustup +nightly component add rust-analyzer

[bjorn3]

You shouldn't need to use the rust-analyzer shipped with rustup if you use vscode. If anything normally the rust-analyzer shipped with the vscode extension itself is newer. I guess what happened here though is that the rust-analyzer stable releases (and thus vscode stable channel updates) are currently paused due to a big internal refactor and the proc-macro abi got changed since this freeze. Using the pre-release version of the extension may work, or it could be broken due to said big internal refactor.

[cubewhy]

vscode rust-analyzer plugin provides a way to use an external rust-analyzer binary

BTW, the vscode rust-analyzer plugin uses the bundled rust-analyzer by default (not the rustup one)

[bjorn3]

@cubewhy

BTW, the vscode rust-analyzer plugin uses the bundled rust-analyzer by default (not the rustup one)

Yes, that is why I said you shouldn't need the rustup one normally.

[cubewhy]

That right...but when I define a "rust-toolchain.toml" file in my project, rustup claims the nightly toolchain for /usr/lib/rustup/bin/rust-analyzer on my machine

[bjorn3]

What I'm saying is that you shouldn't use /usr/lib/rustup/bin/rust-analyzer with the vscode extension normally. Instead just use the rust-analyzer shipped with the vscode extension as is the default.

Also never mind about the rust-analyzer stable release freeze. Turns out the v10 abi shipped several months before the freeze. I think the issue is rather that for some reason the rust-analyzer-proc-macro-server binary of the wrong rustc toolchain is picked up. It should always pick the one from the toolchain with which the proc-macro was compiled. Setting rust-analyzer.server.path will not fix this. One question @Sandmeyer: Did you happen to switch from the stable to the nightly channel without restarting rust-analyzer? If so try restarting rust-analyzer to force rust-analyzer-proc-macro-server getting restarted.