Why is tokio::main guarded by a #[cfg(not(test))]?

[sodiboo]

So, here's my story for why this is a sorta big issue for me:

Recently, with an update to rust-analyzer (i think), i started seeing some weird errors all over my code, "proc macro main not expanded: proc macro not found" (but also for seemingly just about all other proc macros i was using). I found rust-lang/rust-analyzer#12525 which seems to suggest updating rustc.

I ran rustup update and that fixed all my errors, except for the one with tokio::main. In the autocompletion list, tokio::test still existed, so it wasn't an issue breaking all of tokio's macros, as it previously seemed to be. It was clearly specific to tokio::main, so i looked at the definition of tokio::main, and found #[cfg(not(test))] on its definition. It says it's a workaround for rust-lang/rust#62127, which is closed as completed, so i don't think it's still an issue? I also checked the blame and found that the problematic cfg has not been touched in 2 years, so I have no idea why this has started happening just now

I thought maybe this is only in the main tokio crate, because i found it just forwards from tokio-macros. So, i tried depending on tokio-macros and using tokio_macros::main as a workaround, but i found the same line in tokio-macros, from 3 years ago so that's no good.

I searched around for this on the internet, and found rust-lang/rust-analyzer#7225 which mentions that apparently rust-analyzer has a config option to fix this? It does? Well, i added tokio and the error kept appearing. So the solution was not obvious, which is why i'm creating this discussion, because even though i have fixed it, it feels like a hack and i think others should be able to find it by searching for this same issue.

The solution i found was that the editor option rust-analyzer.cargo.unsetTest must include tokio ANDtokio-macros.

So, if anyone else has this same issue, there's your solution.

But... what?? I'm only depending on tokio! I think it is ridiculous that i have to change a config option for a transitive dependency that's clearly not supposed to be used directly, and only has 10 dependents on crates.io that aren't directly related to tokio

Now that leaves me with my question, why the hell is all this necessary? Why is tokio::main not defined when cfg(test)? The issue that this is supposedly a workaround for seems to be that #[main] is ambiguous. Of course it is, there's a builtin #[main] attribute. But i've always seen this used as tokio::main, which is not ambiguous from what i can tell. So why does this workaround need to exist, when it causes issues, and a simpler workaround could be to either have #[cfg(not(test))] on your actual main function, the one that #[tokio::main] would be applied to, or to import it as a different name when cfg(test)?

And a harder question, which is probably more related to rust-analyzer than tokio, why was my code working just fine a week ago, when i was using #[tokio::main]?

This doesn't seem to be a bug in tokio, it's not preventing my code from working correctly. It still compiles just fine. The issue is that the cfg causes rust-analyzer to break, because it automatically enables cfg(test) when analyzing crates, so that test modules still have proper language support. When running my code, there is no problem, because cargo run does not enable cfg(test), and tokio::main exists just fine

[JoshuaCarter]

Thanks for the solution!

[Darksonn]

Well, the reason we are doing this is this issue: rust-lang/rust#62127. If somebody knows of a way to fix it, I would be very happy to change it.

[Novirius]

Thanks for the solution; I've been trying to solve this recently

[Oreolicious]

Yesterday everything was working fine. The problem started showing up today. I find it mildly frustrating that I now have to alter VSCode settings for the project when I want to distribute it to my colleagues. From what I understand it's not immediately obvious how to navigate this issue because it resulted from a fix for something else? Seems like quite the predicament

[Darksonn]

If this is a new issue, then it should probably be reported elsewhere. Tokio has been set up like this for years.

[sodiboo]

If this is a new issue, then it should probably be reported elsewhere. Tokio has been set up like this for years.

Yeah, i realize that. It's definitely not something tokio is doing wrong suddenly, because this hasn't been broken by a change in tokio. That's why i didn't use the issues tab to report this. But i also don't know where to report this (is it a bug in rustc or rust-analyzer? idk) other than tokio because the issue was very much also specific to tokio, in that it disappeared for every macro except tokio::main after running rustup update