Regression(?): proc macro not expanded since v0.3.1091

[andrew-sol]

I use NEAR Rust SDK crate (https://docs.rs/near-sdk/latest/near_sdk).
I see "proc macro not expanded" errors everywhere after the update to v0.3.1091.

v0.3.1083 works fine.

rust-analyzer version: 0.3.1091
rustc version: rustc 1.61.0 (fe5b13d68 2022-05-18)
relevant settings: CARGO, RUSTUP_HOME, RUSTUP_HOME are empty

[bjorn3]

You will need to update rustc. Between the rustc version you are using and the latest one there has been an abi breaking change in the proc_macro implementation. Rust-analyzer 0.3.1091 updated for the new abi and thus broke support for the old abi (on nightly rustc at least) Rust-analyzer doesn't attempt to support nightlies other than the latest.

[lnicola]

There was a change affecting 1.63 nightlies, but it shouldn't have any effect on 1.61.

[Veykril]

The latest release upgraded the diagnostic to warning from weak-lint since we now properly detect whether proc-macros are disabled or not. So these errors might not be new for your project, they are just more visible now.

This usually indicates some other build problem for r-a in your project. The easy way out is to disable the specific diagnostic via the settings, though that might give you a worse experience overall for other IDE features still. There might be some information in the server logs as to what is going wrong.

Browsing the near-sdk repo works fine for me, the few uses of some proc-macros expand properly.

[arnolddevos]

Same problem here but with yew macros. Versions as above:

rust-analyzer version: 0.3.1091
rustc version: rustc 1.61.0 (fe5b13d68 2022-05-18)
yew version: "0.19.3"

ra shows an error unresolved-proc-macro for yew's Properties, function_component and html macros. There was no warning or error with the previous ra version and cargo builds the project without warnings or errors.

[andrew-sol]

Will clarify a bit. In my case (NEAR SDK) the error appears only for attribute macroses and derive macroses:

#[near_bindgen]
#[ext_contract(...)]
#[derive(BorshDeserialize, BorshSerialize, PanicOnDefault)]

Some of them are from this crate: https://docs.rs/borsh/latest/borsh.

Log (Extension Host) doesn't show any errors.

EDIT: "Rust Analyzer Language Server" and "Rust Analyzer Language Server Trace" log channels are empty.

[lnicola]

(sneaky little macroses 😅)

The log channel is called Rust Analyzer Language Server.

[Veykril]

The borsh and yew macros work fine for me on rustc 1.61 with latest r-a.

For anyone having errors here, please check your Rust Analyzer Language Server logs for any warnings or errors and check your configs for anything build related that might impact the build script execution of rust-analyzer, that is any of the rust-analyzer.cargo.* and rust-analyzer.procMacro.* configs. It might help setting your rust-analyzer.server.extraEnv to { "RA_LOG": "warn,rust_analyzer::reload=info" } as well for more useful outputs.

As a reminder, if you get errors now but didn't onl last r-a it is almost certainly because the weak-lint warning got upgraded, so they were erroring for you before they were just barely visible.
Note that there is a small bug here if you have proc-macros disabled alltogether, that is rust-analyzer.procMacro.enable: false, then you'll see a bunch of errors you shouldn't see. #12528 Fixes that. But if you have that setting enabled this release shouldn't be causing any new errors for you, only showing you ones that the previous release didn't really show. This doesn't actually cause non weak-lints.

[Veykril]

And for those that either do not want to investigate why their proc-macro's don't get resolved by r-a, or want to get around this since they want to work before investigating it, you can set "rust-analyzer.diagnostics.disabled": ["unresolved-proc-macro"] which should hide these errors. Note though that all the proc-macros that error aren't being expanded and as such will degrade your overall experience most likely.

[Veykril]

I'll hide the resolved comments here so we don't lose track of the different people here, @sumerman if you can't seem to figure out your new problem feel free top open a new issue for that.

[flodiebold]

@andrew-sol @arnolddevos Please try the current pre-release version; it should show a more detailed error message.

[Veykril]

Heads up, #12584 fixed an issue where we potentially did misdiagnose derive helpers as being unresolved specifically. Please let us know if your issues were due to derive helpers erroring or not (so we know whose issues may have been fixed by that here).

[andrew-sol]

Updated to the pre-release version. Now the error says (paths are shortened):

proc macro `near_bindgen` not expanded: Cannot create expander for /.../path-to-the-project-
dir/target/debug/deps/libnear_sdk_macros-7d99f10f2e6fc575.dylib: Io(Custom { kind: InvalidData, error: DlOpen { desc:
"dlopen(/.../path-to-the-project-dir/target/debug/deps/libnear_sdk_macros-7d99f10f2e6fc575.dylib, 0x000A): tried:
\'/.../path-to-the-project-dir/target/debug/deps/libnear_sdk_macros-7d99f10f2e6fc575.dylib\' (mach-o file, but is an
incompatible architecture (have \'x86_64\', need \'arm64e\'))" } })

I'm on Apple M1.

[lnicola]

CC @cloutiertyler via #10894.

@andrew-sol what do you get in Code / Help / About, and did you set rust-analyzer.server.path?

[andrew-sol]

VSCode's "about" shows this:

Version: 1.68.1
Commit: 30d9c6cd9483b2cc586687151bcbcd635f373630
Date: 2022-06-14T12:48:37.209Z
Electron: 17.4.7
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: 9.8.177.13-electron.0
OS: Darwin arm64 21.4.0

I didn't change any rust-analyzer settings, so rust-analyzer.server.path is not set either.

[lnicola]

@andrew-sol what about rustup toolchain list? Did you switch recently from an x64 to an M1 Mac?

[Veykril]

That incompatible arch problem has popped up for a few mac users it seems, see #12494 (comment)

Given the comment that is probably something we'll have to fix somehow, but I don't know anything about that.

[andrew-sol]

rustup toolchain list shows this:

stable-aarch64-apple-darwin
stable-x86_64-apple-darwin (default)
1.56.0-x86_64-apple-darwin
1.58.1-x86_64-apple-darwin
1.61.0-x86_64-apple-darwin (override)

I switched some time ago back and forth, but not recently.

My rust-toolchain file contains:

1.61.0

[lnicola]

stable-x86_64-apple-darwin (default), 1.61.0-x86_64-apple-darwin (override)

Yeah, I don't think you want that.

[flodiebold]

Given the comment that is probably something we'll have to fix somehow, but I don't know anything about that.

I think #12579 will fix that problem if/when we implement it.

[flodiebold]

stable-aarch64-apple-darwin
stable-x86_64-apple-darwin (default)

Hmm but that's the target architecture, right? Like when I install a wasm toolchain, it compiles to wasm, but runs on x86_64. Can you have a toolchain built for aarch64 that compiles to x86_64, or vice versa? How does rustup choose the host architecture of the toolchain on M1 Macs? 🤔

(What does rustc -vV actually say, @andrew-sol?)

[lnicola]

Can you have a toolchain built for aarch64 that compiles to x86_64, or vice versa?

Umm, yes? I think the problem is that @andrew-sol is using the Aarch64 RA with an x64 toolchain, so we can't load the proc macro library in the server process.

I'm curious if this is a new install or a cloned drive. And can you use e.g. an x64 Firefox or Chrome to download an x64 rustup and get an x64 toolchain?

[andrew-sol]

I did:

rustup default stable-aarch64-apple-darwin

removed the target folder, rust-toolchain file, and recompiled.

The error has gone.

When I did this the previous time some project dependencies didn't compile for arch64, but now they do.

[lnicola]

I suppose you need to install the x64 version of Code (or use the x64 RA server) if you want to build your project for x64.

[flodiebold]

Umm, yes? I think the problem is that @andrew-sol is using the Aarch64 RA with an x64 toolchain, so we can't load the proc macro library in the server process.

Right, but what I'm trying to say is that just because rustup says stable-x86_64-apple-darwin (default), that wouldn't automatically mean the host architecture is x86_64? Like, the target architecture shouldn't matter, you should be able to cross-compile from aarch64 to x86_64, in which case rustc should build proc macros for aarch64.

Unless rustup on M1 Mac installs aarch64 builds for compiling to aarch64, and x86 builds for compiling to x86. Which I guess would make some sense.

I suppose you need to install the x64 version of Code if you want to build your project for x64.

Or just point rust-analyzer.server.path to an x86_64 build of rust-analyzer.

[bjorn3]

that wouldn't automatically mean the host architecture is x86_64?

Yes it would. The triple in the toolchain name is the triple for which the compiler itself is built and is thus the host triple.

[flodiebold]

Ah right, I was confusing toolchains with targets 😅

Then I guess it should also be possible to cross-compile to x86_64 with an aarch64 toolchain and aarch64 rust-analyzer build.

[flodiebold]

Well, the original issue is clarified, so let's close this ticket.

[andrew-sol]

Yeah, thanks for your help.