Tracking issue for procedural macro support

[Undin]

Procedural macro support feature depends on the following (experimental) features:

• org.rust.cargo.evaluate.build.scripts - enables building and collecting build artifacts including proc-macro libraries during importing of project structure. Enabled by default
• org.rust.macros.proc.function-like - enables expansion of function-like procedural macros. Enabled by default
• org.rust.macros.proc.derive - enables expansion of derive procedural macros. Enabled by default
• org.rust.macros.proc.attr - enables expansion of attribute procedural macros

To enable an experimental feature, type Experimental feature in the dialog of Help | Find Action action, enable the corresponding items and reload the project model via Refresh Cargo Projects action in Cargo tool window

• introduce proc macro server to evaluate procedural macro functions Add proc-macro-expander source #6658
• compile only "host" code of project: build scripts and proc-macro targets when org.rust.cargo.evaluate.build.scripts experimental feature is enabled Compile only buildscripts and proc macros when fetching build scripts #6735
• support Apple silicon machines (aarch64-apple-darwin target) CI&MACRO: expand proc macros on Apple Silicon machines #7307
• expand function-like macros Expand function-like (bang) procedural macros #6564
  Fixes Support paste::item! macro. #4707
  Fixes Macros using paste! don't get expanded successfully #6983
  Fixes Unresolved reference / trait bound not satisfied error  #7090
  Fixes Syntax highlighting and autocompletion don't work inside macro (like async_stream, lazy_static and etc) #7242
  Fixes Incorrect inference for futures::try_join!() #7608
  Fixes Tuples do not show the correct type #7699
  Fixes Types aren't recognized when using Bevy queries #8049
  Fixes mod created in the autocxx's macro is not recognized #8785
  Fixes Macro expansion is producing false positive E0308 #9266
• expand custom derive macros (impl only) MACRO: expand custom derive, resolve impls from custom derive #6992
  Fixes derive_more::Add and another Add trait impl: spurious error #4629
  Fixes Plugin doesn't see generated functions #5468
  Fixes Plugin doesn't recognize Display derive #5478
  Fixes False positives for Request<HelloRequest> doesn't implement Debug (required by {:?}) #5728
  Fixes "CustomError doesn't Display" false positive error using "failure" create #5954
  Fixes Problem with #[derive] macro? #6036
  Fixes False positive "Use of moved value" when Copy is derived by enumset #6489
  Fixes Mismatched types [E0308] reported in Clion, but not with cargo check #6880
  Fixes Missing methods introspection for fltk-rs #7158 (requires RES: resolve proc macros through #[macro_use] #7184)
  Fixes The trait method implemented through a derived macro cannot be prompted #7848
  Fixes Regression in new engine for Rust macro expansion? #8193
  Fixes False error when determining type of decode function of BorshSerialize trait #8415
  Fixes False positive error on the bevy Asset trait #8581
  Fixes sea-orm ActiveModelBehavior #8610
  Fixes False Error with strum #[derive(Display)]: enum doesn't implement Display #8847
  Fixes False positive with auto-dereferencing #8856
  Fixes intellij-rust parse thiserror::Error has problem #9133
  Fixes false positive of lacking impl, if given from derive_more crate #9216
  Fixes Trait defined by custom derive macro can't be traced properly #9226
• take into account all items generated by custom derive macros MACRO&RES: support arbitrary items expanded from custom derive #7725
  Fixes Support items generated by proc macros #1786
  Fixes Support items generated by snafu derive macro #7365
  Fixes SeaQL(sea-orm) derive macros not detected #7901
  Fixes False positive 'unresolved reference' #7997
• expand attribute macros MACRO: expand attribute proc macros #7194
  Fixes Code completion regression in web-sys? #5104
  Fixes [Request] versuch::try_fn attribute macro support #5239
  Fixes Bug: Macro Declared Deref not identified correctly #5748
  Fixes Wrong inference for amethyst Option<Handle<SpriteSheet>>::as_ref().unwrap().clone() #5896
  Fixes False positive "main function not found" with rocket #5975 (the corresponding changes in the inspection made in INSP: properly process items by Main function not found #9914)
  Fixes Can't find async function #6006
  Fixes False E0050, E0185 #6091
  Fixes Unresolved reference while rustc is ok #6093
  Fixes Inspector incorrectly points out that #[derive] can only be used on structs, enums and unions #6162 (requires changes in the annotator)
  Fixes Unrecognised fields and no autocomplete [generated by macros] #6482
  Fixes pin project struct doesn't have code completion #6938
  Fixes Proc macro on struct which are generating new struct in crates failing #7610
  Fixes #[async_trait] with 'async_trait lifetime is incorrectly flagged as being an experimental in-band lifetime #7863
  Fixes Wrong error highlight with #[inherent] proc-macro #8350
  Fixes False positives with cxx #8369 (requires changes in org.rust.ide.annotator.RsSyntaxErrorsAnnotator)
  Fixes Ability to supress errors in Rust #8407
  FIxes Analyzer doesn't consider macro expansion before flagging errors. #8640
  Fixes Error E0107 - False positive while using tauri #9128
  Fixes Function modification is not captured #9384
  Fixes broken code navigation (minimal example included) IDEA Ultimate #9534
  Fixes Take into account allow attributes generated by macro #9918
  Fixes #[proc_macro_attribute] field injection is not supported by syntax highlighter #9973
• enable org.rust.cargo.evaluate.build.scripts experimental feature by default Stabilise org.rust.cargo.evaluate.build.scripts #9402 Enable build script evaluation by default #9532
• enable org.rust.macros.proc.function-like experimental feature by default Enable function-like and derive proc macro expansion by default #9729
• enable org.rust.macros.proc.derive experimental feature by default Enable function-like and derive proc macro expansion by default #9729
• enable org.rust.macros.proc.attr experimental feature by default
• Other
  Adding support for custom syntax introduced by proc macros #6367
  Cannot find declaration to go to - mod link macro param  #7170

[webern]

Does this mean that a subset of derive macro code is currently considered (e.g. for code completion and missing-symbol highlighting?

take into account all items generated by custom derive macros

For example, the Snafu derive macro produces structs which intellij-rust seems to be unaware of.

Would a minimal use case example of this and tracking issue be of any benefit?

[Undin]

@webern

Does this mean that a subset of derive macro code is currently considered (e.g. for code completion and missing-symbol highlighting?

Yep. Currently, the plugin takes into account only impl blocks generated by derive proc macro

Would a minimal use case example of this and tracking issue be of any benefit?

I don't think that we need additional tracking issue only for that case because the current issue already contains a similar item: "take into account all items generated by custom derive macros". But an additional use-case can be useful indeed to check it during the corresponding implementation

[webern]

additional use-case can be useful indeed to check it during the corresponding implementation

Here is the use-case:

Cargo.toml:

[package]
name = "snafu-jetbrains"
version = "0.1.0"
edition = "2018"

[dependencies]
snafu = "0.6"

main.rs

use snafu::Snafu;

/// The error type for this library.
#[derive(Debug, Snafu)]
enum Error {
    #[snafu(display("This is always an error:: {}", message))]
    AlwaysError { message: String },
}

fn hello_world() -> Result<(), Error> {
    AlwaysError {
        message: "this is a struct created by snafu",
    }
    .fail()
}

fn main() {
    hello_world().unwrap()
}

Problem:

Desired behavior: code completion should be available for the struct AlwaysError:

Desired behavior: context actions should provide the ability to fill in missing struct fields for the AlwaysError struct.

Thank you! 🚀

[Undin]

@webern Thank you for your example. I've filed a separate issue #7365 with it

[webern]

How are we coming along on take into account all items generated by custom derive macros and #7365? This is suuuuuch a huge feature for me. Is at the top of the intellij-rust priority list?

Right now I have to open Sublime Text using Rust Analyzer to discover generated structs and functions! Help, I'm lost without my IDE!

[vlad20012]

@webern #7725

[ranile]

What's blocking #6732? I don't see that issue mentioned here. I'm experiencing the same problem and would love if that is fixed.

[vlad20012]

@hamza1311, I suppose it's #7725, but you can use the latest yew version from GitHub (not from crates.io) that works well right now.

[ranile]

@vlad20012, I see. It seems that specific case is fixed but there are other cases where the bug still exists. For example, the following code still gives the same message:
lib.rs:

use yew::prelude::*;

fn _test() -> Html {
    use_effect(|| {
        || {}
    });

    html! {

    }
}

Cargo.toml:

[package]
name = "yew-html-macro-bug-repro"
version = "0.1.0"
edition = "2018"

[dependencies]
yew = { git = "https://github.com/yewstack/yew/" }

Screenshot:

It is also worth mentioning that the warning disappears if I do this:

[lfrancke]

I tried enabling this, refreshed a cargo project and it just worked.
Unfortunately, it only worked once. All changes since the initial refresh don't show up.
I tried refreshing, I disabled and reenabled the functionality but nothing worked.

My code compiles fine even though IntelliJ now shows it as "red".

Before I open a new ticket I thought I'd ask if I am maybe missing something: Do I need to do anything to manually update proc macro details and/or can I delete a cache somewhere? A cargo clean followed by a refresh works. Is this intended?

[johansmitsnl]

Had a issue with Sycamore (originally reported it for Yew) but these experimental features solved it for me. Also added screenshots and a repo to reproduce it: #6732 (comment)

[CristianKerr]

Hi I wanted to activate org.rust.macros.proc as an experimental feature, but I do not see it in there, what can I do to make it available? Thanks

[Undin]

@CristianKerr follow this instruction

[CristianKerr]

@CristianKerr follow this instruction
Its not there

[Undin]

@CristianKerr I suppose you use too old plugin version

[CristianKerr]

@CristianKerr I suppose you use too old plugin version

You are right, I have 0.3.140.3644-202, but I do not know why it doesn't show latest version for me (it looks like its up to date). Thanks!

[Undin]

I do not know why it doesn't show latest version for me

Probably, you use old IDE version as well

[CristianKerr]

@Undin you are right, got stuck on older version, thanks for the help!

[Mersid]

I am not fully sure if this issue is related to procedural macros, but I'll post it here anyway. So, some functions from libraries do not show up in code completion:

As one can see, on line 20 it shows that it is a perfectly valid function, but attempting to invoke the code completion dropdown will show that it cannot find a function by that name. I have all of the experimental features turned on, but it doesn't appear to help:

Now, using the Re-Expand All Rust Macros command does fix it:

But it causes additional problems, because now CLion marks a lot of code as invalid and says things like "cannot move":

Or "use of moved" value:

The code does still work, and these errors did not show up before re-expanding macros. Additionally, re-expanding macros breaks the IDE's ability to detect and detect some macro-related code. Notice how BinaryTreeKey is in white; it appears that CLion no longer knows that BinaryTreeKey is a struct:

---

Closing and re-opening the project does fix these issues:

But it also means that code completion can't find some functions again:

Does anyone know how to fix this, or is this something that cannot be remedied?

Thanks!

[Mersid]

I think I found another issue. Macros that take structs don't show up properly if documentation in it ends with a backslash. For example, observe these two instances. They work fine normally

But when adding backslashes to the comment (and it only works with triple slash comments that end with a backslash),

The coloring gets stripped out, showing that the IDE is no longer able to properly recognize the code. I am not quite sure why this is happening, but it does mean that these types do not show up in code completion. An example is from the wgpu crate: the functions in wgpu::Features::* do not work because two of the bit flags end with a backslash in its comment.

[Mersid]

Environment

• IntelliJ Rust plugin version: 0.4.185.5086-223
• Rust toolchain version: nightly-x86_64-pc-windows-msvc, rustc 1.68.0-nightly (37d7de337 2022-12-12)
• IDE name and version: CLion 2022.3
• Operating system: Windows 10

Problem description

Derive macros do not appear to recognize procedural macros in code completion

Steps to reproduce

1. Install something like bytemuck
2. Derive (for example) bytemuck::Zeroable
3. Observe that it should be valid, but if you enter bytemuck::Zeroabl (missing the last character) and hit Ctrl + Space to bring up the code completion, it will say that there are no suggestions.

For this test, ensure Cargo.toml has these two dependencies:

glam = {version = "0.22.0", features = ["bytemuck"]}
bytemuck = {version = "1.12.3", features = ["derive"]}

Create a struct:

#[repr(C)]
#[derive(Copy, Clone, Debug, bytemuck::Pod, bytemuck::Zeroabl)]
pub struct Vertex {
    position: glam::Vec3,
    color: glam::Vec3
}

Observe that:

No suggestions. But if we were to manually enter it correctly?

It recognizes it.

[djdisodo]

Span::call_site.source_file.path has empty path