fix: avoid inserting duplicate dylib_path_envvar when calling cargo run recursively

[linyihai]

What does this PR try to resolve?

If the current program started by cargo run recursively call into cargo run, the second cargo run will insert search_path into dylib_path_envvar again.

Fixes #14194

How should we test and review this PR?

The first commit adds the test to reflect the issue. The first call to cargo run stores the dylib search path env var to a file. Subsequent calls verify that env var remains the same.

The second commit fixes the behavior by checking if env vars in search_path are a prefix of the slice of env vars in dylib_path_envvar.

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[epage]

Should we test for the sympton rather than the specific detail? In this case, its an extra rebuild

[linyihai]

This issue seems need more exploration, thanks for your in advance review.

[weihanglo]

The reason this approach didn't work is pretty much due to #10358. When Cargo computes fingerprint for a Unit of work, it asks env::var which doesn't contain LIBRARY_PATH or PATH because that is set by Cargo. rerun-if-env-changed only captures environment variables set by users via shell like MY_VAR=1 cargo build. Variables added by Cargo only available when consulting the Command struct of the build script execution via Command::get_envs (like what has done in f91dc78).

As a consequence, if you open the fingerprint JSON file of the build script execution (normally at target/debug/.fingerprint/foo-559e30894cda9925/run-build-script-build-script-build.json), you'll see

{
  "rustc": 11851488446658826000,
  // ...
  "local": [
    {
      "RerunIfEnvChanged": {
        "var": "DYLD_FALLBACK_LIBRARY_PATH",
        "val": null
      }
    }
  ],
  "rustflags": [],
  // ...
}

which shows that Cargo failed to capture the initial library search path set by itself.

---

There is another way to observe this bug: set the LEVEL env var in the test to a higher number like 5. Any subsequent Cargo invocation after the first one should be fresh. Before doing this verification you need to change std::env!("LEVEL") to std::env::var!("LEVEL") because the former will be captured by rustc dep-info, which trigger a rebuild.

[linyihai]

Before doing this verification you need to change std::env!("LEVEL") to std::env::var!("LEVEL") because the former will be captured by rustc dep-info, which trigger a rebuild.

I didn't expect such a difference.

I decide to to get the "LEVEL" from the command line argument.

[weihanglo]

Thanks!

@bors r+

[bors]

📌 Commit 54dbc2b has been approved by weihanglo

It is now in the queue for this repository.

[bors]

⌛ Testing commit 54dbc2b with merge fbcd9bb...

[bors]

☀️ Test successful - checks-actions
Approved by: weihanglo
Pushing fbcd9bb to master...