Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(env): dont track envs set by cargo in dep-info file #14811

Closed
wants to merge 2 commits into from

Conversation

weihanglo
Copy link
Member

What does this PR try to resolve?

Don't track environment variables set by Cargo1 in Cargo's dep-info file.

This patch is quite hacky since the "set-by-Cargo" env vars are
hardcoded. However, not all environment variables set by Cargo are
statically known. To prevent the actual environment variables applied to
rustc invocation get out of sync from what we hard-code, a debug time
assertion is put to help discover missing environment variables earlier.

Fixes #14798

How should we test and review this PR?

A new test is added to show no rebuild triggered.

Try adding a random new env here and see if a debug build fails.

@rustbot
Copy link
Collaborator

rustbot commented Nov 12, 2024

r? @epage

rustbot has assigned @epage.
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

@rustbot rustbot added A-build-execution Area: anything dealing with executing the compiler A-rebuild-detection Area: rebuild detection and fingerprinting S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 12, 2024
Comment on lines +576 to +586
#[cfg(debug_assertions)]
pub(crate) fn assert_only_envs_set_by_cargo<'a>(
keys: impl Iterator<Item = impl AsRef<str>>,
env_config: &HashMap<String, OsString>,
) {
for key in keys {
let key = key.as_ref();
// When running Cargo's test suite,
// we're fine if it is from the `[env]` table
if env_config.contains_key(key) {
continue;
}
assert!(
is_env_set_by_cargo(key),
"`{key}` is not tracked as an environment variable set by Cargo\n\
Add it to `ENV_VARS_SET_FOR_CRATES` if you intend to introduce a new one"
);
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This patch is quite hacky since the "set-by-Cargo" env vars are
hardcoded. However, not all environment variables set by Cargo are
statically known. To prevent the actual environment variables applied to
rustc invocation get out of sync from what we hard-code, a debug time
assertion is put to help discover missing environment variables earlier.

@ehuss I'm curious about your thoughts on this

github-merge-queue bot pushed a commit that referenced this pull request Nov 13, 2024
### What does this PR try to resolve?

This was found when doing #14811.

Other counterparts display environment variables,
but rustdoc does not.
This patch makes rustdoc follow suit.

### How should we test and review this PR?

Run `cargo doc -vv`
@@ -529,3 +529,98 @@ fn target_linker(bcx: &BuildContext<'_, '_>, kind: CompileKind) -> CargoResult<O
}
Ok(matching_linker.map(|(_k, linker)| linker.val.clone().resolve_program(bcx.gctx)))
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In order to better discover these variables, whether to put this part of the content in a separate file management is better?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A simple search for ENV_VARS_SET_FOR_CRATES could lead the way, though no objection to this proposal, just lacking of a better module name (naming is hard 😆).

@bors
Copy link
Contributor

bors commented Nov 16, 2024

☔ The latest upstream changes (presumably 69e5959) made this pull request unmergeable. Please resolve the merge conflicts.

This is a side effect when fixing 13280 via PR 14701.
This patch is quite hacky since the "set-by-Cargo" env vars are
hardcoded. However, not all environment variables set by Cargo are
statically known. To prevent the actual environment variables applied to
rustc invocation get out of sync from what we hard-code, a debug time
assertion is put to help discover missing environment variables earlier.
"CARGO_PKG_DESCRIPTION",
"CARGO_PKG_HOMEPAGE",
"CARGO_PKG_REPOSITORY",
"CARGO_PKG_LICENSE",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To remove these requires that we are tracking these somewhere else. For things like the package name, thats more obvious. For ones like this, where is that happening? Should we have a test that changing the license causes a rebuild?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good catch. We actually only rebuild for authors, homepage, repository, and repository.

let metadata = util::hash_u64((&m.authors, &m.description, &m.homepage, &m.repository));

If we're going to hand-pick some of them, I would rather drop this out.

Since we were trying to fix #14811, the alternative is a “wontfix” and documenting it.

If you're setting CARGO_SOMETHING in [env], you are screwed because it won't work and may hurt your rebuild detection.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently, package.description was tracked by fingerprint because of the usage of CARGO_PKG_DESCRIPTION #3857.

Okay, maybe the other way round—We do hand-pick whatever we want to "remove" from cargo's dep-info file. The other stay in dep-info so they are happy to rebuild when requires by env!. And we don't even need to track them in fingerprint.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes sense for us to track metadata in dep info rather than fingerprint so we only rebuild if the user cares.

As for the other part, I'm unusre

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pub links: Option<String>,
pub rust_version: Option<RustVersion>,

It is so fun that package.links and package.rust-version are considered metadata and and won't trigger any rebuild when changed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imo there isn't a reason to rebiild on rust-version change unless the user is using it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is fair. It is a kind of metadata for the actual compilation.

@weihanglo
Copy link
Member Author

Going to close this.

  • It is not good that a patch relying on debug assertions
  • We may want to track metadata by Cargo's dep-info file, insteado of manual track in fingerprint. fix(env): dont track envs set by cargo in dep-info file  #14811 (comment)
  • CARGO_RUSTC_CURRENT_DIR has been removed. If other folks has bumped into the same situation of setting internal envs in [env] table, we can at least tell them it is not supported.

@epage
Copy link
Contributor

epage commented Dec 18, 2024

CARGO_RUSTC_CURRENT_DIR may come back because file! is being specified, see rust-lang/rust#134442

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-build-execution Area: anything dealing with executing the compiler A-rebuild-detection Area: rebuild detection and fingerprinting S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CARGO_RUSTC_CURRENT_DIR is causing forced rebuilds
5 participants