Can a proc macro detect that it's being run by rust-analyzer or rls?

Hello, everyone

Is it possible for a proc macro to detect that it's being run via rust-analyzer or rls (as opposed to being run by rustc)?

I have some proc macros that generate client code (e.g.: derive(AutoTypeScript)) but I don't want it regenerated every time rust-analyzer goes over my code.

Thanks o/

Conceptually, it would be weird for the "code assistant" to be dealing with your code in a different manner to that of a classic use of your crate. That being said, env vars and Cargo features are more general-purpose tools to tweak the behavior of code: you can set up r-a to enable a specific Cargo feature or to use a specific env var, and then have your crate use that to disable its own processing. It would have the tangential side-effect that testing this new behavior would not require using rust-analyzer :slightly_smiling_face:

A super hacky approach could be to check for RUSTC_WRAPPER=rust-analyzer within a script of your proc-macro, if you wanted to be able to interact with out-of-the-box rust-analyzer :see_no_evil:

1 Like

If you don't register RUSTC_WRAPPER as read env var that will cause any builds after rust-analyzer analyzed the code to still think that it is running in rust-analyzer until you do cargo clean. If you do register it, the build cache will be invalidated every time rust-analyzer reloads the project (because rust-analyzer reloaded or because a build script or proc macro changed).

1 Like

Yeah, cache invalidation is indeed something to be mindful of. Which leads me to think that env vars rather than Cargo features ought thus to be used, with a proc-macro implementation checking for ::std::env::var() rather than option_env!

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.