Set IS_RUST_ANALYZER=1 for build commands

[vgel]

We have some builds scripts that do heavy work (e.g., running wasm-pack) that isn't necessary for RA's analysis, but nonetheless slows down IDE startup because RA runs the build script on server restart^1. We want to add something essentially like this to our build script:

// build.rs
if !is_rust_analyzer() {
    // do slow stuff that RA doesn't need
}

But right now there isn't a great way to detect RA in a build script. Based on current main, our build script actually looks like this:

let is_rust_analyzer = option_env!("RA_RUSTC_WRAPPER").is_some() || option_env!("IS_RUST_ANALYZER").is_some();
if !is_rust_analyzer {
    do_wasm_pack();
}

Where RA_RUSTC_WRAPPER is set for some invocations, but for full coverage you need to manually add IS_RUST_ANALYZER to cargoExtraEnv in your editor's rust-analyzer config. This PR simply unconditionally sets that environment variable.

Bikeshedding welcome on the variable name, I just picked what seemed reasonable. There's also the question of documentation, tests, etc.—this is my first RA PR so (if people want to see this merged), I'd appreciate guidance on how to do that.

^1 : We do emit the appropriate cargo:rerun-if-changed directives, but that doesn't help when switching branches causes genuine changes in those directories.

[Veykril]

I'm curious but are there problems with just setting cargo.extraEnv for you here?

[vgel]

I'm curious but are there problems with just setting cargo.extraEnv for you here?

Yeah, that's what we're doing now, but (AFAIK) there's no way to automatically configure that setting for all contributors on repo clone, they need to manually configure it. it seems like the sort of thing that naturally belongs in rust-analyzer itself instead of each project needing to reinvent the wheel and nag everyone to fix their editor configuration.

[bjorn3]

This would cause alternating between a rust-analyzer invoked cargo check and a user build to rebuild the build script and everything that depends on it ever time, right?

Yeah, that's what we're doing now, but (AFAIK) there's no way to automatically configure that setting for all contributors on repo clone, they need to manually configure it.

You can set all rust-analyzer configurations in a .vscode/settings.json file you check in.

[vgel]

This would cause alternating between a rust-analyzer invoked cargo check and a user build to rebuild the build script and everything that depends on it ever time, right?

I'm not familiar enough with how rust-analyzer interacts with the workspace to know—does rust-analyzer produce intermediates that other cargo commands can use? In that case, at the risk of making the change more involved, maybe this could be an opt-in behavior from the build script in some way? Or, instead of an environment variable, the build script could signal "skip running me entirely if you're rust-analyzer and cache nothing so I'll be re-run correctly by cargo"?

Yeah, that's what we're doing now, but (AFAIK) there's no way to automatically configure that setting for all contributors on repo clone, they need to manually configure it.

You can set all rust-analyzer configurations in a .vscode/settings.json file you check in.

Only if the entire team uses VSCode :-) We're split between {Neo,}vim, Emacs, vscode, Jetbrains... plus we sometimes roll with person-specific workspace settings, for example setting the rust-analyzer target to wasm32 when working on the wasm parts of our code, and I think that approach would overwrite those personal settings?

[bjorn3]

Rust-analyzer uses plain cargo check with the same target dir as user initiated builds for producing diagnostics. You can set the target dir that is used using a rust-analyzer config, but that has the same issue of not being able to set it on a per project basis for non-vscode editors.

[Veykril]

Coming back to this finally (sorry for the silence), I am actually wondering now how cargo handles env changes here. Does it automatically track any env vars that are queried via the corresponding compile time macros?

That aside, I do think this is the wrong way to tackle this. The ideal solution I can see is that we finally get a minimal rust-analyzer.toml working that you can check out then that supports setting the extra env stuff for the project (so that this works in a client diagnostic way).

[bjorn3]

For env!() rustc records a dependency in the dep-info file which causes cargo to rebuild as necessary. For proc macros there is no tracking at all. And for env::var() in build scripts, the build script has to explicitly tell cargo the fact that it depends on the env var.

[Veykril]

I'll close this, I think the rust-analyzer.toml approach is the correct one here (and someone is looking into that soon), see #13529 to follow that