### What does this PR try to resolve?
If a there is a symlink into a git repository/submodule,
when checking its git status with the wrong outer repo,
we'll get an NotFound error,
as the object doesn't belong to the outer repository.
This kind of error blocked the entire `cargo package` operation.
This fix additionally discovers the nearest Git repository,
and then checks status with that,
assuming the repo is the parent of the source file of the symlink.
This is a best effort solution, so if the check fails we ignore.
### How should we test and review this PR?
If we don't want the complication,
we could drop the last commit, ignore the error, and forget about
handling submodules
fixes#15384fixes#15413
If a there is a symlink into a git repository/submodule,
when checking its git status with the wrong outer repo,
we'll get an NotFound error,
as the object doesn't belong to the outer repository.
This kind of error blocked the entire `cargo package` operation.
This fix additionally discovers the nearest Git repository,
and then checks status with that,
assuming the repo is the parent of the source file of the symlink.
This is a best effort solution, so if the check fails we ignore.
Dirtiness check for symlinks is mostly informational.
And changes in submodule would fail git-status as well (see #15384).
To avoid adding complicated logic to handle that,
for now we ignore the status check failure.
Stop a few tests which aren't marked with `public_network_test` from
trying to access crates.io. While doing so, also make sure that other
`cargo_add` and `cargo_info` tests initialize the registry.
### What does this PR try to resolve?
This leverages the unstable `--emit=depinfo` option from rustdoc,
so that rustdoc invocation rebuild can be better tracked
without traversing the entire directory.
Some design decisions made in the current implementation:
* Rustdoc's depinfo doesn't and shouldn't emit to `target/doc`,
as the directory is considered part of the final artifact directory.
In regard to that, we specify the dep-info output path to
the fingerprint directory of rustdoc invocation.
It looks like this
`target/debug/.fingerprint/serde-12d29d32b3b8b38f/doc-lib-serde.d`.
* We also start supporting `-Zchecksum-freshness` as a side effect.
Could make it a separate PR if desired.
* `-Zbinary-dep-depinfo` is not enabled along with this,
since doc generations don't really require any binary dependencies.
### How should we test and review this PR?
The tests added has covered these cases:
* target src outside package root, e.g., `lib.path = "../lib.rs"`
* `#[doc = include_str!("../outside/pkgroot")]`
* `#[path = "../outside/pkgroot"]`
* `env!`
### Additional information
Fixes#12266Closes#15205
This renames the gc config table to `[cache]` to help avoid some
confusion, and to set up a namespace for possible expansion in the
future for different kind of cache controls.
Low-level settings are stuffed into the `[cache.global-clean]` table,
but we do not expect to stabilize these at this time. Only the top-level
`cache.auto-clean-frequency` setting is expected to be stabilized.
Closes https://github.com/rust-lang/cargo/issues/14292
This leverages the unstable `--emit=depinfo` option from rustdoc,
so that rustdoc invocation rebuild can be better tracked
without traversing the entire directory.
Some design decisions:
* Rustdoc's depinfo doesn't and shouldn't emit to `target/doc`,
as the directory is considered part of the final artifact directory.
In regard to that, we specify the dep-info output path to
the fingerprint directory of rustdoc invocation.
It looks like this
`target/debug/.fingerprint/serde-12d29d32b3b8b38f/doc-lib-serde.d`.
* We also start supporting `-Zchecksum-freshness` as a side effect.
Could make it a separate PR if desired.
* `-Zbinary-dep-depinfo` is not enabled along with this,
since doc generations don't really require any binary dependencies.
<!--
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.
-->
fixes#12663
Lockfile might be gitignore'd,
So it never shows up in `git status`.
However, `cargo packag` vcs checks actually performs
`git status --untracked --ignored`.
It is a bit confusing that lockfile is ignored but still counts as dirty
from the report of `cargo package`.
There are some more nuances:
We check lockfile's VCS status if the lockfile is ouside the current
package root. That means a non-workspace Cargo package will not have
this VCS check. I don't think it is good that we have diverged behaviors
Hence this revert.
We can always re-evaluate later,
as we've reserved rooms for doing more dirty checks.
https://github.com/rust-lang/cargo/issues/14967#issuecomment-2651329783
This fixes a problem introduced by
https://github.com/rust-lang/cargo/pull/11648 where the future-incompat
report will tell you to run with an `--id` flag with the wrong value
if the report is already cached.
The solution is to add a method to determine which ID to use for the
suggestions *before* attempting to save the report.
<!--
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?
Small PR to rename `workspace-manifest-path-hash` to
`workspace-path-hash` in the build-dir template as mentioned
[here](https://github.com/rust-lang/cargo/issues/14125#issuecomment-2733611870)
(cc: #14125)
r? @epage
### What does this PR try to resolve?
This PR is a follow up on #15104 and and adds support for the path
templating in `build.build-dir` as defined in #14125.
Supported templates:
* `{workspace-root}`
* `{cargo-cache}` (pointing to `CARGO_HOME` for now)
* `{workspace-manifest-path-hash}`
#### Unresolved questions
What should we name `{workspace-manifest-path-hash}` and what should it
include? Should we shorten to `{workspace-hash}` or even just `{hash}`?
Should we include the Cargo version so we get unique whole-target
directories for easier cleanup (#13136)
How should this handle unknown variables (error) or unclosed `{` / `}`
(ignored), see
https://github.com/rust-lang/cargo/pull/15236#discussion_r1977898973
When using `{workspace-manifest-path-hash}` this hash will change based
on the project path. In the event of a cargo being executed in a
symlinked project, the hash will change.
For example, given the following directory
```
/Users/
└─ user1/
└─ projects/
├─ actual-crate/
│ └─ Cargo.toml
└─ symlink-to-crate/ -> actual-crate/
```
the hash will be unique when running cargo from each of the following
directories.
* `/Users/user1/actual-crate`
* `/Users/user1/symlink-to-crate`
Figuring out whether to handle this is deferred out, see
- https://github.com/rust-lang/cargo/pull/15236#discussion_r1971938021
-
https://github.com/poliorcetics/rfcs/blob/cargo-target-directories/text/3371-cargo-target-dir-templates.md#symbolic-links
-
https://github.com/rust-lang/cargo/issues/12207#issuecomment-2711402159
### How should we test and review this PR?
This PR is fairly small. I included tests for each template variable.
You can also clone my branch and test it locally with
```console
CARGO_BUILD_BUILD_DIR='{workspace-root}/foo' cargo -Z build-dir build
```
### Additional information
While searching Cargo for any prior art for path templating, I found
[`sources/registry/download.rs`](https://github.com/rust-lang/cargo/blob/master/src/cargo/sources/registry/download.rs#L84)
doing a simple string replace. Thus I followed the same behavior.
r? @epage
This commit adds logic to check for unexpected variables in templated
paths like `build.build-dir`. Cargo will error if it finds a variable
that it does not know how to expand.
### What does this PR try to resolve?
Fixes#15059Fixes#15159
This provides an escape hatch `--exclude-lockfile`for uncommon workflows
that don't verify (`--no-verify` is passed) the build with their
unpublished packages
In effect, this takes the heuristic removed in #14815 and replaces it
with a flag
When `--exclude-lockfile` is enabled,
`cargo package` will not verify the lock file if present,
nor will it generate a new one if absent.
Cargo.lock will not be included in the resulting tarball.
Together with `--no-verify`,
this flag decouples packaging from checking the registry index.
While this is useful for some non-normal workflows that requires
to assemble packages having unpublished dependencies.
It is recommended to use `-Zpackage-workspace` to package the entire
workspace, instead of opting out lockfile.
### How should we test and review this PR?
The first commit was stolen from
<1a104b5444>
(credit to @NoisyCoil!)
The second added two failing cases we observed in #15059.
### Additional information
### What does this PR try to resolve?
This builds on the work done in #15199 to improve target selection
errors to also disambiguate when the same binary name is used in
multiple packages.
This also makes the errors from #15199 more consistent with the rustc
style guide and reduces code duplication.
Fixes#13312
### How should we test and review this PR?
This is a first pass and does not do the full `--package foo --bin bar`
syntax. I wanted to focus on the basic functionality before we iterated
on it, e.g. investigating how well we can predict the CLI flags, how
much noise they might add, etc.
### Additional information
