-
Notifications
You must be signed in to change notification settings - Fork 1.7k
proc macro *
not expanded: proc macro not found
#12610
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Please report the concrete examples, otherwise it's impossible to tell what's going on. These might be proc macros declared with |
rust-analyzer v0.3.1099 dependencies tokio = { version = "1.19.2", features = ["full"] } #[tokio::main]
async fn main() {
println!("Hello, world!");
} [{
"resource": "/src/main.rs",
"owner": "rustc",
"code": {
"value": "unresolved-proc-macro",
"target": {
"$mid": 1,
"external": "https://rust-analyzer.github.io/manual.html#unresolved-proc-macro",
"path": "/manual.html",
"scheme": "https",
"authority": "rust-analyzer.github.io",
"fragment": "unresolved-proc-macro"
}
},
"severity": 8,
"message": "proc macro `main` not expanded: proc macro not found",
"source": "rust-analyzer",
"startLineNumber": 1,
"startColumn": 1,
"endLineNumber": 1,
"endColumn": 15
}] |
|
I have the same issue using The error message is:
It looks like the error prints out for every usage, so 100s of times in my case. The
After that all other An example usage of this macro is:
As the original report said, this used to show up sometimes and go away. Even after restarting I must say that |
Opened #12614 for |
Hi, I'm currently seeing this with clap: E.g. with the stub program: use clap::Parser;
#[derive(Parser)]
#[clap(author, version, about, long_about = None)]
struct Args {
}
fn main() {
} Cargo.toml: Then I get this error from rust-analyzer:
(Although the code itself builds fine without any errors/warnings via cargo)
|
@rib I can't reproduce this with either the stable or the pre-release. What does the |
I've noticed this doesn't always happens. It just happened to me by pulling latest changes from git while vs code is open. Closing vs code and reopening again fixes it in some cases. I'll try to reproduce it on a minimal example. |
I can reproduce this with the |
@alice-i-cecile What's the precise error message, and what does |
same issue with tokio. Message says proc macro The Quick fix suggestions is saying: "Remove unnecessary async" |
|
@juanmait @alice-i-cecile That version is older than the fix for the tokio::main problem. If you install the pre-release, I'd expect you to get a newer version though (2022-06-20 or now 2022-06-23 with extension version 0.4.1103). |
Not sure if it matters, but also happening with sqlx. |
@Milo123459 If you can reproduce this with the newest pre-release version of rust-analyzer, it would be helpful if you can report a new issue for this. Ideally with a small example project, because sqlx issues are usually hard to reproduce without a bunch of setup. |
It only happens occasionally, but I'll try. |
Hi I am currently seeing this with tokio :
Cargo.toml
|
@JOSBEAK what's your extension version, and what does the "Show RA version" command say? |
@flodiebold Actually it just worked after doing a simple extension reload 👍🏼 Thanks :) |
Having the same issue. I just created this from scratch on an M1 with an up to date rustup. Compiles fine and the html! macro works correctly in the output. I get this error in the tooltip:
When I Ctrl-Click I go straight to the downloaded source file for the macro. main.rs
cargo.toml ra-version: Also used the non pre-release Edit: I've restarted VSCode several times |
@mattbradbury Can you please set |
@flodiebold Here's the results. Interesting extra findings below them.
I saw that my VsCode is running emulated in Rosetta (Intel version here on out). I downloaded the Apple Silicon version, ran it from the zip file and Rust Analyzer started working correctly. I went back to the Intel version and rust-analyzer is working correctly now in both versions. This felt a bit fishy so I started looking around. I noticed that while in the Intel version it said the RA extension needed a Reload. So I reloaded and the the OG error re-appeared. Closed the Intel, opened the Silicon version and the same error was happening in the Silicon version. Again the Reload Required message appeared in the extension. Upon reloading it works again. And again when i switch to the Intel version it's still working. As long as I don't click the Reload Required on the extension it seems to work fine. I did this roundtrip 3 or 4 times with no variation in behavior. Still don't know why the Silicon version worked immediately. Maybe some architecture specific files were missing and it downloaded the Silicon RA version on first start. In conclusion: It appears that the extension downloaded while Silicon works fine, the extension downloaded for Intel is borked. Maybe a separate Intel version is no longer needed for M1 machines? Hope this helps and I'll add anything else that can help, just ask. Oh, btw, in Silicon version the RA versions are the same as Intel for release and pre-release and the behavior was the same as above when switching between Silicon and Intel pre-release versions. |
You currently need to be using the same architecture (intel vs. ARM) for rust-analyzer as your rust toolchain. And VSCode will download the extension for its own architecture, so unless you're using a separate rust-analyzer you're getting the one matching the VSCode architecture. Hence why it only works with the extension downloaded by the ARM version. This will be fixed by #12579. I'm a bit confused why it showed "proc macro not found" instead of the architecture mismatch. I suspect the errors are sometimes getting lost somewhere on the way somehow, I'm also seeing this when the proc macro build isn't finished yet 🤔 Edit: Found it, #12648. |
problem in my case my system MacOS m1 #[tokio::main(flavor = "current_thread")]
async fn main() {
Args::parse(matches())
.map(serve)
.unwrap_or_else(handle_err)
.await
.unwrap_or_else(handle_err);
} error show message
my try to solve it use tokio::main; // that should fix error
#[main(flavor = "current_thread")]
async fn main() {
Args::parse(matches())
.map(serve)
.unwrap_or_else(handle_err)
.await
.unwrap_or_else(handle_err);
}
|
@alfuhigi Your problem is the exact opposite of |
@bjorn3 I try it on windows 10 inel x86_64 version vscode , rustc 1.61.0 (fe5b13d68 2022-05-18) #[tokio::main(flavor = "current_thread")]
async fn main() { ....
this code work fine for me ! use tokio::main;
#[main(flavor = "current_thread")]
async fn main() {... |
@alfuhigi that the error doesn't show up when you import the macro is a bug, #12649. I would not recommend changing it to that since it will actually make the situation worse for rust-analyzer, you just don't see it. Try to make sure you've got the newest version of the extension running on the Windows PC -- what does the |
@flodiebold FYI, this morning I installed the x86_64 toolchain and mostly had the same behavior in reverse, except that in the Arm64 version of VsCode it didn't put the 'Reload Required' tag on the RA Extension in the Extensions pane. Apparently I've been running my setup with Arm64 toolchain and Intel VsCode since I got this Mac a year and a half ago. Something changed in the last week or so to break this. |
@mattbradbury Nothing broke it, it never worked. We just didn't show the error as prominently before. |
Let's close this. If you're still encountering proc macro issues, please
If so, please open a new ticket with the code that results in the error, and the full error message. |
Which issue should I watch to know when that's fixed? |
rust-analyzer version: 6fc5c3c 2022-06-20
rustc version: (latest stable) rustc 1.61.0 (fe5b13d68 2022-05-18)
Since last week, rust analyzer shows several errors for proc macros not found including sometimes cfg_attr in the header of some files where there's no apparent cfg_attr.
Until yesterday's update the errors used to go away after a while but with yesterdays version and with latest pre-release the errors stay.
The text was updated successfully, but these errors were encountered: