### 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
Whether a period was used was dependent on whether a `help:` block is
present.
That shouldn't make a difference and the rustc dev guide says not to use
periods unless multiple sentences are used.
This was found when updating git submodule in rust-lang/rust
```
---- cargo_command::overwrite_cargo_environment_variable stdout ----
running `/projects/rust/build/aarch64-apple-darwin/stage1-tools/aarch64-apple-darwin/release/cargo run`
thread 'cargo_command::overwrite_cargo_environment_variable' panicked at src/tools/cargo/tests/testsuite/cargo_command.rs:636:58:
test failed running `/projects/rust/build/aarch64-apple-darwin/stage1-tools/aarch64-apple-darwin/release/cargo run`
error: expected to find:
/projects/rust/build/aarch64-apple-darwin/stage1-tools/aarch64-apple-darwin/release/cargo
did not find in output:
[COMPILING] foo v1.0.0 ([ROOT]/foo)
[FINISHED] `dev` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s
[RUNNING] `target/debug/foo`
```
