Regression around proc-macros which change signatures

[ndmitchell]

I have a project (closed-source alas) which has a proc-macro where you write:

#[foo]
fn myfun() {
   ...
}

And the proc-macro changes that to:

fn myfun(x: &str) {
    ...
}

Since my last upgrade to Rust Analyser 2020-07-13, when I call such functions I get the message:

Expected 0 arguments, found 1

This code works fine if I do cargo build or cargo check, but Rust Analyser displays a persistent error message. I tried Rust Analyser Nightly and that still has the same issue.

This code worked fine a few weeks ago. In case it's relevant, I'm on Rust Nightly 2020-07-12. I upgraded the toolchain the day before the IDE, and it seemed to work fine for that day.

[bjorn3]

Attribute proc-macros are not yet implemented I believe.

This code worked fine a few weeks ago.

This error was implemented a few weeks ago.

[ndmitchell]

So it's a case of Rust Analyser getting a new feature (detecting incorrect arity functions) which happens to play poorly with missing macros. Any advice on how to get around it until macros are implemented?

[bjorn3]

You could use "rust-analyzer.diagnostics.enable": false to disable all errors of rust-analyzer itself, but not the cargo check errors. Other than that the only thing you could do is just ignore the errors I think.

[flodiebold]

We're considering adding a separate toggle for these type-based diagnostics.

[ndmitchell]

Thanks for the info. In my case I suspect the easiest thing to do to keep a good IDE experience is to make the macro not change the type signature - so make people write myfun(x: &str) explicitly. And I'll wait for this issue to be resolved to make it revert it back.