RA cannot defer the type from a macro

[Indra-db]

rust-analyzer version: rust-analyzer version: 0.4.2369-standalone (588948f 2025-04-06)

rustc version: rustc 1.86.0 (05f9846f8 2025-03-31)

editor or extension: pre-release (release same problem): Version
0.4.2369
Last Updated
2025-04-07,

code snippet to reproduce:
cargo.toml

crabtime = "1.1.3"

fn main() {
    let x = {
        #[crabtime::eval_function()]
        fn boo2() {
            crabtime::output! {
                5u32
            }
        }
    };
}

RA reports x: () while with the expanded code from RA, it reports correctly u32
expanded:

let x = { 
#[doc = " # Compilation Stats"]
#[doc = " Start: 01:23:04 (771)"]
#[doc = " Duration: 0.50 s"]
#[doc = " Cached: false"]
#[doc = " Output Dir: /Users/indra/Code/git/flecs_rust/target/rust-analyzer/debug/build/crabtime/project_f940e44a8c006acd/pid_59609"]
#[doc = " Macro Options: MacroOptions {"]
#[doc = "     cache: true,"]
#[doc = "     content_base_name: false,"]
#[doc = " }"]
#[cfg(any())]
const _:() = ();
5u32
};

[Indra-db]

@wdanilo is the author of crabtime and aware of this issue. Any questions about crabtime specifically is better deferred to him if necessary.

[Indra-db]

worth pointing out, this works as expected on RustRover

[Veykril]

Woah that is cursed. That certainly is one way to get custom expression level attributes working while that feature is still unstable. rust-analyzer expands this as an item in local position, expecting this to expand to items and as such we discard the expansion/do not consider it when lowering the expression AST. Unlikely we'll fix this soon, given we do not support expression level attributes either and this will likely require similar plumbing to that feature to make it work for us.

[wdanilo]

@Veykril thanks for the reply! Is there any other way I could generate some code from this macro that RA will still provide hints for the users of the macro? This "cursed" way was the only way I found working :)

[Indra-db]

@Veykril in case you missed it

[Veykril]

you'd need to move a way from effectively treating item attributes as expression as that is what r-a can't handle.

Though on second thought, I would also almost call this a bug that attributed items are allowed to expand to non-items (not like it matters, that ship has sailed).