### What does this PR try to resolve?
Track unit dependency graph in `LogMessage::UnitRegistered`.
This gives the unit-graph information before running the build, which
will help enable root cause analysis for cascading rebuilds.
Part of <https://github.com/rust-lang/cargo/issues/15844>
### How to test and review this PR?
Track unit dependency graph in `LogMessage::UnitRegistered`.
This gives the unit-graph information before running the build,
which will help enable root cause analysis for cascading rebuilds.
### What does this PR try to resolve?
Fixes#9722
When a user requests a non-existent feature, cargo suggests a similar
feature if one exists via edit distance. However, if no feature name is
close enough to suggest, the error message provides no help.
This PR adds a fallback that lists all available features so the user
can see their options when no close match exists.
**Before:**
```shell
package foo depends on bar with feature serde but bar does not have that feature.
```
**After:**
```shell
package foo depends on bar with feature serde but bar does not have that feature.
available features: cookies, json, tls
```
### How to test and review this PR?
This PR follows the atomic commit pattern:
1. First commit adds a test documenting the current behavior
2. Second commit implements the fix and updates the test expectation
Run the new test:
```shell
cargo +nightly test --test testsuite -- features::dependency_activates_feature_with_no_close_match
```
When a requested feature does not exist and there is no similar
feature name to suggest, list all available features.
Implements the "closest else all" pattern - show the closest match
if one exists, otherwise list all available features as a fallback.
Fixes#9722
### What does this PR try to resolve?
A new report command `cargo report sessions` is added.
The motivation of this is to provide an access to the build session ID,
so that user can retrieve reports for specific session.
For example, `cargo report timings --id <my-older-build>`.
The command name `sessions` was chosen because
* It is a thing that Cargo "reports to user",
feeling more reasonable than `cargo report list-runs`
or `cargo rebuild recent-builds`.
* Discussed with `@Muscraft`,
and we feel `SessionId` will be a better term in `RunId`.
While whether a `cargo` invocation is a session is debatable,
sessions the term is widely used for logging and metrics.
* This is unstable. We can always change its name later.
Design decision:
- Doesn't show total number of sessions to not be a performance burden
when we add filtering, see
https://github.com/rust-lang/cargo/pull/16428#discussion_r2649281077
Part of https://github.com/rust-lang/cargo/issues/15844
Fixes https://github.com/rust-lang/cargo/issues/16401
### How to test and review this PR?
See tests for the report output.
It is a simple text-based report. JSON schema is not included.
```console
$ cargo report sessions -Zbuild-analysis
Session IDs for `/projects/cargo` (most recent first):
- 20251218T220836847Z-0e981be2243ad433
- 20251218T220801494Z-0e981be2243ad433
- 20251218T220704295Z-0e981be2243ad433
... and more (use --limit N to see more)
```
Unresolved questions
- without a workspace, do we error? if not, should we have a flag for
forcing of global listing?
(https://github.com/rust-lang/cargo/pull/16428#discussion_r2648201273,
https://github.com/rust-lang/cargo/pull/16428#discussion_r2648202658)
### What does this PR try to resolve?
Closes#13952
This PR adds location information of where each 'patch' was defined to
the dependency override algorithm. Currently there're three possible
sources: manifest `Cargo.toml`, one of the configuration files (listed
[here](https://doc.rust-lang.org/cargo/reference/config.html#hierarchical-structure))
or CLI option `--config 'patch.crates-io.rand.path="rand"'`
([source](https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#the-patch-section)).
Preserving location of where the patch was defined should simplify
troubleshooting of incorrect or incompatible dependency override
configuration.
This PR does not change:
- the way of toml files parsing
- the way of working with dependency locks
- the way of patch overlaps resolving (end of
`cargo::core::Workspace::root_patch` function)
- related error messages happening in a different phases of the build,
e.g. toml parsing
### How to test and review this PR?
I suppose test changes should demonstrate the intended behavior change.
Few earlier commits do not contain test changes because they do not
change visible behavior of cargo but allow to proceed with the ones that
do.
A new report command `cargo report sessions` is added.
The motivation of this is to provide an access to the build session ID,
so that user can retrieve reports for specific session.
For example, `cargo report timings --id <my-older-build>`.
The command name `sessions` was chosen because
* It is a thing that Cargo "reports to user",
feeling more reasonable than `cargo report list-runs`
or `cargo rebuild recent-builds`.
* Discussed with `@Muscraft`,
and we feel `SessionId` will be a better term in `RunId`.
While whether a `cargo` invocation is a session is debatable,
sessions the term is widely used for logging and metrics.
* This is unstable. We can always change its name later.
Part of rust-lang/cargo#15844
Remaining `build`s:
- linker is potentially involved
- testing related to dev-dependencies
(didn't look to see if `check --benches` could replace `bench`)
Similarly, some `run`s` were removed so long as compilation verified the
same details.
Inspired by #16436 which is adding more tests which don't need `build`
but copied the existing ones.
### What does this PR try to resolve?
Support
- multi-line inline tables
- trailing commas on inline tables
- `\e` string escape character
- `\xHH` string escape character
- Optional seconds in times (sets to `0`)
Anyone using these features will raise their development MSRV. The
published `Cargo.toml` file will still be compatible with old TOML
parsers and so old Cargos. If `toml_datetime` gains the ability to track
whether seconds were optional (will be a breaking change), then that
might change though that would only apply to `package.metadata` as we
don't make use of times in Cargo.
### How to test and review this PR?
### What does this PR try to resolve?
Fixes#16148Fixes#13607
Right now cargo vendor only filters .gitattributes, .gitignore, and .git
at the top level of each package. If these files exist in
subdirectories, they don't get filtered. This causes problems when the
vendored code gets checked into a git repo - git processes those files
and modifies them, which breaks checksums.
I ran into this when trying to vendor libssh2-sys. The .gitattributes
file in libgit2/src/util/ was getting its line endings changed by git,
causing checksum failures.
### How should we test and review this PR?
This follows the atomic commit pattern:
- First commit adds a test showing the current buggy behavior (test
passes)
- Second commit implements the fix and updates test assertions (test
still passes)
The fix uses components() to recursively check for .git directories
(since they can appear at any path level like deep/nested/.git/config),
while using file_name() for .gitattributes and .gitignore files.
### Additional context
This should also help with #13607 since it filters .gitignore and .git
recursively too.
If people actually need git functionality in their vendored deps, they
can add rules to their own .gitattributes at the root level.
In rust-lang/cargo#15514, Cargo starts direct-extraction from `.crate`
tarball in `$CARGO_HOME/registry/cache` when vendoring. This is fine with
remote registrires but not for local registries, as local registries'
tarball are stored along with index.
This fix abstracts `cache_path` to `RegistryData` trait, so every
registry source type can define its own locationa of tarball cache.
Note that for local-registry when accessing either index or cache, the
assumption is that file lock of the index and cache directory need to
be externally synchronized. Cargo doesn't take care of it.
### What does this PR try to resolve?
Noticed `CARGO_SBOM_PATH` was being set when playing around with
artifact-deps.
I could have gated the env by whether the nightly feature was enabled
but figured it would be better to not set if it there aren't SBOMs.
### How to test and review this PR?
Noticed `CARGO_SBOM_PATH` was being set when playing around with
artifact-deps.
I could have gated the env by whether the nightly feature was enabled
but figured it would be better to not set if it there aren't SBOMs.
Done by having `requested: true` field in user-requested units
Instead of calling it "root units", here we use "requested units",
which represent the actual build targets that users requested.
This is for reserving future extension that requested units may not
always be the "root units" of the unit graph. We might have some
synthetic units like rustdoc-merge, lipo universal binary for macOS,
post-processing, or any user-defined super root units.
The requested units sounds more future-proof than root_units,
This caused a headache that
* You need to remember to generate timings report, otherwise the HTML
get stale.
* The source diff of both the log file and the HTML report are basically
unreviewable, and the timestamp and elapsed time change every time.
We'd like to find a better way to help review timing HTML instead of this.
### What does this PR try to resolve?
This makes the log message more complete.
Also consumers can check whether a crate is really "no rebuild needed"
It also open a door if we want to log the current fingerprint value.
Part of <https://github.com/rust-lang/cargo/issues/15844>.
### How to test and review this PR?
The test diff should show the behavior change
This makes the log message more complete.
Also consumers can check whether a crate is really "no rebuild needed"
It also open a door if we want to log the current fingerprint value.
### What does this PR try to resolve?
While triaging #16396, I noticed that the error messages don't match the
rustc style which we are aiming for, so I tweaked the messages and went
ahead and fixed#16396.
Fixes#16396
### How to test and review this PR?
Since `different-binary-name` doesn't have a `-Z` variant, I held off on
suggesting it so we didn't suggest using an unstable feature.
### What does this PR try to resolve?
* `resolution-started`
* `resolution-finished`
* `unit-graph-started`
* `unit-graph-finished`
* `unit-registered`
The first four events are simple log events with elapsed time.
The `unit-registered` event contains unit metadata and the index, so
that `unit-started` doesn't need to have those. As a result, the timing
replay now requires `unit-registered` events to derive those data.
The log and HTML snapshot also changed to `rustfix`, which is a bit
smaller in size.
Part of <https://github.com/rust-lang/cargo/issues/15844>
### How to test and review this PR?
