Erroneous hints "proc macro Foo not expanded"

[malaire]

After updating to rust-analyzer 2021-01-25 from 2-months old version, I started getting hints which looks erroneous:

#[derive(thiserror::Error)] gives hint "proc macro Error not expanded"
#[derive(Deserialize)] gives hint "proc macro Deserialize not expanded" (macro is from serde)

[lnicola]

Did you enable proc macro support?

[malaire]

Did you enable proc macro support?

Is that some new requirement? I didn't change any settings when updating rust-analyzer and I didn't get these hints with earlier version. I'm using Sublime Text as editor.

[lnicola]

It's not a new requirement, but the hints are new. They're shown so that you know the macros weren't expanded, and why some features (e.g. completion) don't work with code using them.

You can either enable proc macro support or disable the diagnostics.

[malaire]

Why is the default to spam output with useless hints? Shouldn't it be better to opt-in to such hints instead of having to disable them for EVERY project?

[flodiebold]

You don't have to disable them per project, just once in the LSP settings (if you want).

And no, making the hints opt-in would make them useless, since someone who doesn't know that they need to enable a setting to have proc-macros be expanded is unlikely to know to enable a hint about it. This will go away when we enable proc macro expansion by default.

[malaire]

ok, disabling it works, but I still think this is a mis-feature.

For Sublime Text 3:

Preferences > Package Settings > LSP > Settings

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

[flodiebold]

Just to be clear, you probably want to enable proc macro support, not disable the diagnostic, unless you have specific reasons not to. (And if you do have specific reasons, you might want to explicitly disable proc macros, since we'll enable them by default soon.)

[bjorn3]

As far as I know hints are exactly for when a diagnostic would be too noisy to show as warning. Vscode only shows a gentle dotted line below the first character of the diagnostic range. It doesn't give any other indication of it's existence by default.

[malaire]

Just to be clear, you probably want to enable proc macro support, not disable the diagnostic, unless you have specific reasons not to.

But you can't just enable it, it requires some more settings also.

As far as I know hints are exactly for when a diagnostic would be too noisy to show as warning. Vscode only shows a gentle dotted line below the first character of the diagnostic range. It doesn't give any other indication of it's existence by default.

In Sublime Text 3 those are shown exactly as warnings or errors, just with "hint" instead of "warning" or "error", wasting space and spamming the output.

[malaire]

Actually re-opening this as disabling does NOT work - I still get the hints.

[flodiebold]

I'm going to guess you need to do {"diagnostics": {"disabled": [...]}} instead of {"diagnostics.disabled": [...]}.

[flodiebold]

But you can't just enable it, it requires some more settings also.

Yes, it requires running cargo check on startup so that the proc macro is actually there to be run.

[malaire]

I'm going to guess you need to do {"diagnostics": {"disabled": [...]}} instead of {"diagnostics.disabled": [...]}.

Using "rust-analyzer.diagnostics.disabled" seems to work even though the "rust-analyzer" there is superfluous as it's already under "rust-analyzer" client.

[malaire]

But you can't just enable it, it requires some more settings also.

Yes, it requires running cargo check on startup so that the proc macro is actually there to be run.

And even that isn't enough, it requires loading some OUT_DIRS which doesn't seem to be documented at all. How is that OUT_DIRS used? Is it a problem if it contains code for other projects also? etc.

[flodiebold]

That's what I was referring to. You need to enable rust-analyzer.cargo.loadOutDirsFromCheck, which will run cargo check on startup to get the proc macros. The name of the setting is historical, it's not only for OUT_DIRs anymore. (OUT_DIR is an environment variable that cargo sets when building a crate, which refers to the directory where code generated by build.rs is usually placed. So if you have dependencies using build.rs for code generation, you'll need this as well.) It's probably going to be changed soon too.

#6448 should provide more information about this.

[Ch00k]

In my case (neovim with coc.nvim extension) adding

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

to coc-settings.json fixed the issue.

[nyrf]

In my case (neovim with coc.nvim extension) adding

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

to coc-settings.json fixed the issue.

Thanks, you saved my times.

[hgomersall]

In my case (neovim with coc.nvim extension) adding

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

to coc-settings.json fixed the issue.

It took me ages to find this solution. It fixes a couple of issues I've been having with macros. Perhaps I'm crap at reading docs, but I feel this should have been more obvious. Not a criticism of anyone, just noting the issue.

[hgomersall]

Just to add a little more to @Ch00k's solution for CoC. You can access the settings with :CocConfig, which loads coc-settings.json into a buffer, whether or not it's empty. If it is empty, you need to complete the file properly:

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

On my system, coc-settings.json lives in ~/.config/nvim/, though it didn't exist until I created it.

[hgomersall]

To conclude, this has been fixed now and should work out-of-the-box. coc-rust-analyzer might need updating separately, which you can do with CocUpdate.