Proc-macros that re-use input spans break our syntax fixup

[Veykril]

#[tokio::main]
async fn main() {
    main.
}

gets expanded to

fn main(){
  {
    main.
  }[()]{
    tokio::runtime::Builder::new_multi_thread()()()()()
  }
}

while ideally it should be

fn main() {
    let body = async { main. };
    #[allow(clippy::expect_used, clippy::diverging_sub_expression)]
    {
        return tokio::runtime::Builder::new_multi_thread()
            .enable_all()
            .build()
            .expect("Failed building the Runtime")
            .block_on(body);
    }
}

tokio-macros version 1.8.0

This happens because the tokio macro is applying the span of the final expression of the block to all its extra tokens that it is outputting, so our syntax fixup (given its based on the token id of tokens, and token ids being our current span) completely obliterates the output in this case.

[Veykril]

So we have a problem here, the span setting happens entirely in the proc-macro library so we can't special case any of the set_span methods to ignore fixup ranges. Meaning this is not fixable as it stands right now.

[Veykril]

In other words, identity as a concept for spans/tokens cannot exist in Rust. So our fixup infra has a problem.

[Veykril]

This works better now due to changes in tokio, but the general issue is still a thing.

[jorgemmsilva]

Any shot this will be fixed?
As a workaround I have been commenting the #tokio[...] annotations to get auto-complente, then uncomment it, but this is poor DX 😞

I'd be happy to contribute and resolve the issue, but I have no idea where to start lol

[Veykril]

This is not workable from our side unfortunately, this is an inherent issue with the way proc-macros work. So the only other venue is changing the span usage in the tokio macros

[ChayimFriedman2]

@Veykril I think I actually got an idea that may improve things quite a bit. Let me see how this will work...

[Veykril]

Curious to hear about that as I don't see see how we could figure out if a span was re-used or not.

[ChayimFriedman2]

Actually I get completions as normal for #[tokio::test] 😕

[jorgemmsilva]

Interesting. Seems to be an issue specific to Cursor. I also get auto-complete in vanilla VSCode. 🤔

I see Cursor uses an ancient version of rust-analyzer - v0.3.2253. That's probably the issue