Macro error with futures::try_join!

[lnicola]

Same as @jeromegn , I am still getting the error on the nightly version of rust-analyzer, in my case in a call to futures::try_join!.

Originally posted by @Victor-Savu in #6716 (comment)

[peku33]

Same here.
This affect all futures macros, like select, join etc.

[edwin0cheng]

Maybe related to #6811

[flodiebold]

@Victor-Savu @peku33 Please check this again with the next nightly or current master.

[Victor-Savu]

Unfortunately I can still reproduce the problem. Here is a minimal reproduction:

Extension version: 0.3.418-nightly

cargo.toml:

[package]
name = "rust-analyzer-error"
version = "0.1.0"
edition = "2018"

[dependencies]
tokio = { version = "0.2", features = ["macros"] }
futures = "0.3"

main.rs:

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

I used join! instead of try_join! to keep the example as short as possible but the error is the similar:

could not resolve macro $crate::join_internal

[flodiebold]

join_internal seems to be a proc_macro_hack macro; that's probably the problem.

[peku33]

So this is a problem with rust-analyzer or futures?
At the moment one of the most popular crates with 3M recent downloads (futures) triggers this error for basic usage.

[flodiebold]

Any error that rust-analyzer produces in code that compiles is a problem in rust-analyzer.

You can disable the diagnostic by adding macro-error to the rust-analyzer.diagnostics.disabled setting.

[lnicola]

Triage: this still happens even after #7145.

[lnicola]

Ah, it's a proc_macro_hack thing.

[bionicles]

still getting this, any easy way to disable it temporarily?

[Victor-Savu]

@bionicles if you are using VSCode, create a file .vscode/settings.json at the root of your project folder containing:

{
    "rust-analyzer.diagnostics.disabled": [
        "macro-error"
    ]
}

[lolgeny]

It's annoying that with futures::join, with this, rust-analyser can't infer types for the output. Is there any hacky fix to get that working?

[mountainfloating]

@bionicles if you are using VSCode, create a file .vscode/settings.json at the root of your project folder containing:

{
    "rust-analyzer.diagnostics.disabled": [
        "macro-error"
    ]
}

Doesn't work for me with futures::select!. Any other way i can disable this?

[jonas-schievink]

The diagnostic is now called unresolved-macro-call

[Diggsey]

This also occurs with Yew's html! macro.

[KyGost]

This occurs with fstrings's macros (seemably all?).
Disabling unresolved-macro-call provided a good temporary fix! Thanks.

[Ciantic]

If the problem is proc_macro_hack, then I think futures needs to be just updated? I created an issue in futures ( rust-lang/futures-rs#2406 ) repo to remove the proc_macro_hack. After all the proc_macro_hack repo says:

Proc_macro_hack Note: As of Rust 1.45 this crate is superseded by native support for #[proc_macro] in expression position. Only consider using this crate if you care about supporting compilers between 1.31 and 1.45.

[Ciantic]

It's now fixed in the futures package! try_join! and select! works now with the futures git repo.

I think this can be closed, though futures is not released yet, it will start to work in futures 0.4 and rust 1.45

[jonas-schievink]

I'd rather keep it open. It will probably take years until the ecosystem uses futures 0.4

[taiki-e]

I will backport that patch to 0.3, so no need to wait for futures 0.4. (See the label of the PR that fixed the issue)

[taiki-e]

Released futures 0.3.15 which includes the fix for this issue.

[regexident]

I recently started getting the same error with log's macros, such as log::debug!(…) on v0.2.599, for what it's worth.

Should I open a separate issue or is this reasonably related?

[jonas-schievink]

Doesn't sound like the same issue

[neor164]

I've just ran into this issue recently with pyo3.
you can try it yourself with pyo3 numpy example project: https://github.com/PyO3/rust-numpy/tree/main/examples/simple-extension.

[m1ten]

I've just ran into this issue recently with pyo3.

I am experiencing the same thing, for now I just disabled rust-analyzer.procMacro.enable.

[sebaslopez01]

I've just ran into this issue recently with pyo3. you can try it yourself with pyo3 numpy example project: https://github.com/PyO3/rust-numpy/tree/main/examples/simple-extension.

Me too, I am also disabling it.

[Jason5Lee]

I got the problem in ifmt.

[aleokdev]

I've ran into this issue with tokio::select! and the thiserror crate Error derive. Says it has entered into unreachable code.

[lnicola]

@alexdevteam thiserror used to work. Which compiler version are you using, and can you prepare a small test case?

[ModProg]

Got this error with serde_with::flattened_maybe as well, trying to resolve $crate::serde::Deserialize

[huntc]

In my particular case, I was getting the problem with Yew's macros. Other macros from other libraries like Embassy seemed to work.

To work-around my issue, my settings.json looks like:

{
    "rust-analyzer.diagnostics.disabled": [
        "unresolved-proc-macro"
    ]
}

[nerdai]

This also worked for me, but I was using a VS Workspace, for which settings.json is modified by opening the workspaces' code-workspace rather than adding a .vscode folder in the root dir of your code.

[gmelodie]

In my particular case, I was getting the problem with Yew's macros. Other macros from other libraries like Embassy seemed to work.

To work-around my issue, my settings.json looks like:

{
    "rust-analyzer.diagnostics.disabled": [
        "unresolved-proc-macro"
    ]
}

For anyone using CoC with neovim:

1. open nvim
2. :CocConfig (it'll open CoC's config file)
3. paste the above into this file
4. Save and reopen nvim

[Veykril]

I'll close this issue, a lot of comments in here are about very different issues making it difficult to figure out what the problem even is at this point. So we gain more from people opening new specific issues instead.