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 
A super hacky approach could be to check for RUSTC_WRAPPER=rust-analyzer within a build.rs script of your proc-macro, if you wanted to be able to interact with out-of-the-box rust-analyzer 
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).
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.