### What does this PR try to resolve?
As #10358 said, `When a build.rs script emits
cargo:rerun-if-env-changed, it is not re-run when the value of the
specified variable is changed via the env configuration.`
Fixes#10358
### How should we test and review this PR?
Add test bofore fixing to reflect the issue, the next commit fixed it.
### Additional information
The PR is a sucessor of https://github.com/rust-lang/cargo/pull/14058,
so the previous dicussion can be refer to it.
metdata path fields may point to a dirty symlilnk and cause
duplicate report. This commit combines `dirty_metadata_paths`
and `dirty_symlinks` into one so is able to de-duplicate them.
This adds a special case for checking source files are symlinks
and have been modified when under a VCS control
This is required because those paths may link to a file outside the
current package root, but still under the git workdir, affecting the
final packaged `.crate` file.
This may have potential performance issue. If a package contains
thousands of symlinks, Cargo will fire `git status` for each of them.
`cargo package` will warn users when git `core.symlinks` is `false`
and some symlinks were checked out as plain files during packaging.
Git config [`core.symlinks`] defaults to true when unset.
In git-for-windows (and git as well),
the config should be set to false explicitly when the repo was created,
if symlink support wasn't detected [^1].
We assume the config was always set at creation time and never changed.
So, if it is true, we don't bother users with any warning.
[^1]: <f1241afcc7/setup.c (L2394-L2403)>
[`core.symlinks`]: https://git-scm.com/docs/git-config#Documentation/git-config.txt-coresymlinks
### What does this PR try to resolve?
rust-lang/rust#122565 adds a new line to thread panic output.
To make the current test suites works on stable, beta, and nightly,
similar to rust-lang/cargo#14602,
this relaxes the assertion around that by globbing everything.
rust-lang/rust#122565 adds a new line to thread panic output.
To make the current test suites works on stable, beta, and nightly,
similar to rust-lang/cargo#14602,
this relaxes the assertion around that by globbing everything.
This adds a special case for `package.{readme,license-file}`
to Git VCS status check.
If they were specified with paths outside the current package root,
but still under git workdir, Cargo checks git status of those files
to determine if they were dirty.
We don't need to take care of other fields with path values because
* `PathSource` only list files under the package root.
Things like `target.path` works for `cargo build`, but won't be
included in `.crate` file from `cargo publish`.
* The only exceptions are `package.readme`/`package.license-file`.
Cargo would copy files over if they are outside package root.
This is a test showing corner cases that dirty files outside
the package being packaging actually made the `.crate` file dirty.
However, `cargo package` and `.cargo_vcs_info.json` didn't capture it.
### What does this PR try to resolve?
So we don't need to `p.to_str().unwrap()`
and are able to pass different types for each argument
### How should we test and review this PR?
No response.
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide"
first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to
review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to
generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its
title.
* It's ok to use the CI resources to test your PR, but please don't
abuse them.
### What does this PR try to resolve?
Explain the motivation behind this change.
A clear overview along with an in-depth explanation are helpful.
You can use `Fixes #<issue number>` to associate this PR to an existing
issue.
### How should we test and review this PR?
Demonstrate how you test this change and guide reviewers through your
PR.
With a smooth review process, a pull request usually gets reviewed
quicker.
If you don't know how to write and run your tests, please read the
guide:
https://doc.crates.io/contrib/tests
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
### What does this PR try to resolve?
Fixes#14154
~~Added some of the missing package metadata to the fingerprint so that
rebuilds are triggered correctly.~~
~~Also updated the test to prevent a future regression.~~
Moved the manifest metadata tracking to use dep info in favor of
fingerprint so that rebuilds are only triggered if the metadata is
actually used.
This change moves the manifest metadata track to dep-info files
with the goal of reduce unneeded rebuilds when metadata is changed as
well fixing issues where builds are not retrigged due to metadata
changes when they should (ie. #14154)
Personally I liked that the test was only dependent on what really matters, the lack of presence of a particular filename. Now the test would fail if Cargo one day adds more (generated) files to the package.
Co-authored-by: Weihang Lo <weihanglo@users.noreply.github.com>
### What does this PR try to resolve?
This PR is resolving an
[issue](https://github.com/rust-lang/cargo/issues/14776#issuecomment-2515017963)
where `cargo doc --open --examples` does not give a clear message when
the examples file is given to it.
I changed the message from `no crates with documentation` in the
[cargo_doc.rs](58b2d609ec/src/cargo/ops/cargo_doc.rs (L62))
and
[doc.rs](58b2d609ec/tests/testsuite/doc.rs (L1504))
to `requested crate documentation is not available to open`. Now it
becomes easy for the user to understand what they're missing.
Fixes#14776
### How should we test and review this PR?
Here is the command through which you can test this change:
`cargo test SNAPSHOTS=overwrite -- doc::open_no_doc_crate`
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide"
first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to
review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to
generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its
title.
* It's ok to use the CI resources to test your PR, but please don't
abuse them.
### What does this PR try to resolve?
Explain the motivation behind this change.
A clear overview along with an in-depth explanation are helpful.
You can use `Fixes #<issue number>` to associate this PR to an existing
issue.
### How should we test and review this PR?
Demonstrate how you test this change and guide reviewers through your
PR.
With a smooth review process, a pull request usually gets reviewed
quicker.
If you don't know how to write and run your tests, please read the
guide:
https://doc.crates.io/contrib/tests
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
### What does this PR try to resolve?
Dirty file paths in the original message were stripped relative to
package root.
User is not able to know the full path to find dirty files.
This PR makes it relative to git workdir.
### How should we test and review this PR?
This was found during #14962
This was always enabled on nightly since 1.83-nightly (2024-09).
We have no feedback since then, so assume it is a low-impact change.
This stabilization is targeted at 1.85 (2025-02-20)
This is kinda a revert of 125e873dffc4b68b263c5decd88750ec10fd441e
in terms of the behavior.
After this, now `std_resolve` is always resolved by the same set of
packages that Cargo will use to generate the unit graph, (technically
the same set of crates + `sysroot`), by sharing the same set of primary
packages via `std_crates` functions.
This failed because since 125e873dffc4b68b263c5decd88750ec10fd441e
[`std_resolve`][1] only includes `sysroot` as primary package.
When any custom Cargo feature is provided via `-Zbuild-std-feature`,
the default feature set `panic-unwind` would be gone, so no
`panic_unwind` crate presents in `std_resolve`.
When then calling [`std_resolve.query`][2] with the default set of
crates from [`std_crates`][3], which automatically includes
`panic_unwind` when `std` presents, it'll result in spec not found
because `panic_unwind` was not in `std_resolve` anyway.
[1]: addcc8ca71/src/cargo/core/compiler/standard_lib.rs (L96)
[2]: addcc8ca71/src/cargo/core/compiler/standard_lib.rs (L158)
[3]: addcc8ca71/src/cargo/core/compiler/standard_lib.rs (L156)
See rust-lang/cargo#14935
47c2095b1dd580a91e42cb6197b58a318526b8c4 didn't really fix the flakiness.
build-std tests use the users `CARGO_HOME` for downloading registry
dependencies of the standard library. This reduces disk needs of the
tests, speeds up the tests, and reduces the number of network requests
that could fail.
However, this means all of the tests access the same locks for the
package cache. In one test, we assert on the output and a `[BLOCKING]`
message can show up, depending on test execution time from concurrent
test runs.
We are going to hack around this by having the one test that asserts
on test output to use the standard `cargo-test-support` `CARGO_HOME`,
rather than the users `CARGO_HOME`. There will then only be one process
accessing the lock and no `[BLOCKING]` messages.
