The no-op always-success RUSTC_WRAPPER breaks build scripts

[RalfJung]

It is not an uncommon pattern for build scripts to invoke rustc to detect whether some features are available. Popular crates like anyhow and eyre do that, and the autocfg crate (14 million "recent" downloads, >100 million all-time downloads) even provides a convenient interface to write such build scripts.

RA entirely breaks that by having a RUSTC_WRAPPER that always returns success. I think that is a bug in RA.

[lnicola]

This was never reported before. Skimming autocfg, it doesn't seem to use RUSTC_WRAPPER, which might explain the difference. You can use disable rust-analyzer.cargo.buildScripts.useRustcWrapper as a workaround.

Specifically about anyhow, I don't think it should be testing for a feature that no longer exist, but we don't control that.

It would be nice for cargo to have a "run the build scripts, but don't check the code" mode.

[RalfJung]

This wrapper might also be responsible for rust-lang/rust#99538; at least I have not seen that problem since I disabled proc macros and build scripts.

Skimming autocfg, it doesn't seem to use RUSTC_WRAPPER

Oh, good point.

anyhow was specifically asked to use RUSTC_WRAPPER in dtolnay/anyhow#157. And I tend to agree with the author that using RUSTC_WRAPPER is more correct. But neither eyre nor autocfg are using RUSTC_WRAPPER so they happen to not hit this problem. I think that is an accident though, and arguments could be made that they should use RUSTC_WRAPPER.

Specifically about anyhow, I don't think it should be testing for a feature that no longer exist, but we don't control that.

Well, the probe needs updating to latest nightly, yeah. And soon the feature will be stable and this will only be relevant for old compilers. But that doesn't really help with the general problem.

[lnicola]

One solution might be to detect nested invocations of our wrapper: if we're not the outer one, we could pass through the call to rustc (or even to a RA_ORIGINAL_RUSTC_WRAPPER that we've saved).

[bjorn3]

Build scripts don't cause nested invocations of the wrapper.

[lnicola]

Build scripts don't cause nested invocations of the wrapper.

Doesn't the anyhow build script do just that?

[RalfJung]

Yes, it does.

[bjorn3]

Anyhow's build script invokes the wrapper, but the build script doesn't run underneath the wrapper, but directly under cargo. As such the wrapper invocation is not nested within the wrapper.

[lnicola]

Am I missing something here?

1. RA sets RUSTC_WRAPPER=rust-analyzer
2. RA runs cargo check
3. cargo check compiles the anyhow build script
4. cargo check runs the anyhow build script, presumably without clearing RUSTC_WRAPPER
5. the build script checks for RUSTC_WRAPPER and uses it to compile some code

[bjorn3]

That is correct. But how do we detect that anyhow's build script invoked the wrapper rather than cargo itself? Both use pretty much the same env vars and because at step 4 the wrapper isn't used to run the build script, we can't set an env var either to signal that a build script ran rustc with the wrapper as opposed to cargo.

[lnicola]

Can't we set RA_RUSTC_WRAPPPER=$RUSTC_WRAPPER in step 1, then we check for it (in step 5) and run that instead?

[bjorn3]

How do you make sure that it doesn't run for rustc invoked by cargo then?

[bjorn3]

I think we can check env vars like NUM_JOBS or PROFILE which only get set for build scripts.

[RalfJung]

It would be nice for cargo to have a "run the build scripts, but don't check the code" mode.

Yeah, fundamentally this is a hack to work-around not being able to tell cargo what you really want to do. Is that being tracked on the cargo side somewhere, are the cargo devs aware of this?

[lnicola]

How do you make sure that it doesn't run for rustc invoked by cargo then?

Hmm...

Is that being tracked on the cargo side somewhere, are the cargo devs aware of this?

I suppose not, but a request for cargo build --dependencies-only (which isn't that different) has been open since 2016 without any end in sight.