Rust-analyzer: unresolved import: `thiserror::Error`

Created on 21 Sep 2020  路  31Comments  路  Source: rust-analyzer/rust-analyzer

In the latest version of rust-analyzer (on nvim+coc, but a coworker is reporting the same thing on VSCode), I'm getting the following error from rust-analyzer.

image

[rust-analyzer] [E] unresolved import

This happens even though a regular build of the project finishes just fine.

[thiserror::Error] is a derive macro without an accompanying trait (c.f. serde::Serialize, which is a derive macro _and also_ a trait, which does not cause an error).

Could there be a regression with importing derive macro traits?

E-unknown S-actionable

Most helpful comment

They're all working now :tada: (the procMacro.enable setting can be kept off, we can now resolve proc macro in rust-analyzer itself without consulting Cargo)

All 31 comments

I'm having a similar issue with snafu::Snafu (another error-handling derive macro)

Screenshot from 2020-09-21 18-41-15

You can enable proc-macro support using

{
    "rust-analyzer.cargo.loadOutDirsFromCheck": true,
    "rust-analyzer.procMacro.enable": true,
}

I had the same issue with derive macro imports after the latest update with an existing project, but cleaning the target, rebuilding the project and reloading the editor solved it. I still don't get any information on hover (it's stuck at "Loading..."), but I don't know if that was already the case in the previous version.

You can enable proc-macro support using

{
    "rust-analyzer.cargo.loadOutDirsFromCheck": true,
    "rust-analyzer.procMacro.enable": true,
}

I thought, I had this enabled but apparently it was only in workspace settings of another workspace :facepalm: . Fixed for me at least

You can enable proc-macro support using

{
    "rust-analyzer.cargo.loadOutDirsFromCheck": true,
    "rust-analyzer.procMacro.enable": true,
}

This worked for me! Is there any reason this isn't enabled by default? It seems like this is a fairly common use case/language feature.

It can be a security risk (you might load a project with a malicious build scripts), it slows down the first load of the project (because we need to compile them), it can slow down the analysis, it doesn't always work (because of ABI differences, e.g. proc macros don't work in nightly and beta right now and we can't fix them without breaking stable users they work since yesterday).

PS: cargo check is enabled by default, so maybe the security aspect is moot.

It can be a security risk (you might load a project with a malicious build scripts)

That already happens with cargo check.

You can enable proc-macro support using

Enabling those options worked for me but they made RA super slow to the point where I can't use it, and have to put up with the errors for now.

You can use "rust-analyzer.diagnostics.disabled": ["unresolved-import"] to disable the errors for this. It is already disabled in the latest version by default I think. (https://github.com/rust-analyzer/rust-analyzer/pull/6085)

I seem to be getting the unresolved import error for thiserror::Error regardless of whether I have procMacro enabled. I am on rust-analyzer version: nightly (7b674f9).

Do you also have "rust-analyzer.cargo.loadOutDirsFromCheck": true?

Yes. Sorry, I should have posted my config:

{
    "rust-analyzer.updates.channel": "nightly",
    "rust-analyzer.procMacro.enable": true,
    "rust-analyzer.cargo.loadOutDirsFromCheck": true,
    "rust-analyzer.inlayHints.parameterHints": false,
}

This just started happening today when I updated to the latest nightly. (My previous comment has the version)

Same here. Additionally, it seems that cargo will stop checking at all if "rust-analyzer.cargo.loadOutDirsFromCheck": true,. (Though that may be more related to the fact my project is large?)
Note I didn't have these options enabled before, but enabling them did not fix this issue for me, it still shows the unresolved imports.

@sunjay

I seem to be getting the unresolved import error for thiserror::Error regardless of whether I have procMacro enabled. I am on rust-analyzer version: nightly (7b674f9).

https://github.com/rust-analyzer/rust-analyzer/pull/5651

I worked around this issue thus:
use thiserror::*; // should be thiserror::Error, but https://github.com/rust-analyzer/rust-analyzer/issues/6053

image
I'm having similar issue

cc @jonas-schievink

They're all working now :tada: (the procMacro.enable setting can be kept off, we can now resolve proc macro in rust-analyzer itself without consulting Cargo)

Now we only need a stable release.

The fix for this has been included in the last two stable releases, as far as I can see.

rust-analyzer version: 2020-10-19 (3ca97b0)

This is still happening to me with things like:

use derivative::Derivative;
use strum_macros::EnumIter;

Is that a separate issue or should this be reopened?

@teohhanhui did you enable build script and proc macro support as in https://github.com/rust-analyzer/rust-analyzer/issues/6053#issuecomment-699028778?

strum_macros was mentioned here as well and seems to be related to cfg_attr support, which we already have #5548 for. It'd be worth verifying that for both of these though.

@lnicola:

did you enable build script and proc macro support as in #6053 (comment)?

https://github.com/rust-analyzer/rust-analyzer/issues/6053#issuecomment-708590486

the procMacro.enable setting can be kept off, we can now resolve proc macro in rust-analyzer itself without consulting Cargo

rust-analyzer.cargo.loadOutDirsFromCheck is already set to true.

I'm also getting this error in neovim with the built in lsp client but it's happening on a trait from the std lib rather than an external library. The autocompeltion also seems to not be working for the std::os module.

screenshot

My nvim_lsp config:

local nvim_lsp = require('nvim_lsp')
local on_attach = function(client)
    require'completion'.on_attach(client)
    require'diagnostic'.on_attach(client)
end

...

nvim_lsp.rust_analyzer.setup{
    on_attach = on_attach;
    settings = {
        ["rust-analyzer"] = {
            cargo = {
                loadOutDirsFromCheck = true;
            }
        }
    }
}

Ah thanks, I'll follow that issue as well

strum_macros was mentioned here as well and seems to be related to cfg_attr support, which we already have #5548 for. It'd be worth verifying that for both of these though.

Indeed derivative is the same issue. Thanks

#[cfg_attr(not(test), proc_macro_derive(Derivative, attributes(derivative)))]
pub fn derivative(input: TokenStream) -> TokenStream {

This is still happening for the original issue on latest nightly.

Enabling procMacro and cargo.loadOutDirsFromCheck resolves the import, but then all proc macros (that I have tried) fail with proc macro returned error: Server closed.

use thiserror::Error;
..
#[derive(Error, Debug)] // <-- on 'Error': proc macro returned error: Server closed
#[error("{0}")]
struct Foo(String);

Which rustc version are you using?

Which rustc version are you using?

rustc 1.46.0 (04488afe3 2020-08-24)

I'll try updating to latest.

EDIT:
Works on latest (and nightly) only with both of the mentioned options above set:

  "rust-analyzer.procMacro.enable": true,
  "rust-analyzer.cargo.loadOutDirsFromCheck": true,
Was this page helpful?
0 / 5 - 0 ratings

Related issues

matklad picture matklad  路  28Comments

bjorn3 picture bjorn3  路  25Comments

matklad picture matklad  路  25Comments

aochagavia picture aochagavia  路  41Comments

dakyskye picture dakyskye  路  23Comments