### 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.
### What does this PR try to resolve?
In https://github.com/rust-lang/cargo/pull/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.
Fixes https://github.com/rust-lang/cargo/issues/16412
### How to test and review this PR?
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?
This PR adds an SVG renderer and allows users to choose between Canvas
and SVG for rendering charts, which should hopefully resolve#8850.
<img width="1405" height="937" alt="image"
src="https://github.com/user-attachments/assets/760a1a61-72b3-45bc-b36a-bb581e50c0a6"
/>
### Additional information
This does not guarantee a pixel-perfect match from the previous
canvas-based solution, but I maintain it stays as close as possible.
When rendering SVGs with a large number of units, Firefox becomes quite
janky during scrolling. This appears to be caused by dependency lines
that use merged paths and dashed styles. Therefore, this approach splits
them into multiple paths instead.
### 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.
### What does this PR try to resolve?
This could help review the HTML report by download the artifacts.
### How to test and review this PR?
To review the HTML report changed in this PR
1. Go the the summary page of the associated GitHub Action run (e.g.,
<https://github.com/rust-lang/cargo/actions/runs/20354778718>)
2. Scroll to "Artifacts" section and download the `timing-report`
artifact
4. Unzip the `timing-report.zip` file, and open the
`cargo-timing-*.html` in your browser
### What does this PR try to resolve?
After this `cargo report timings` has 99.9% of the feature parity of
what `--timings` renders.
This adds some new fields to some events:
* unit-registered
* `features`: a list of enabled features for the unit
* unit-graph-finished
* `requested_units`: a list of user-requested units. Not calliing this
root units because we may have synthetic "super-root" units in the
future (like doc-merge, post-processing, or user-defined units), which
people may care less and want to focus on what they are actually
building.
* build-started
* `requested_platforms`: alist of target platforms the build is for
The only thing left is CPU usage, but I don't consider it is a
necessary.
Part of <https://github.com/rust-lang/cargo/issues/15844>
### How to test and review this PR?
[Rendered HTML
snapshot](4702fc0211/tests/testsuite/cargo_report_timings/html_snapshot/out/cargo-timing-20060724T012128000Z-b0fd440798ab3cfb.html)
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?
fixes#16363 by splitting the documentation of `DEBUG` and `OPT_LEVEL`
and listing the only possible values for `DEBUG` as commented by ehuss.
(I hope it's okay to just take your comment as documentation 😄 )
### How to test and review this PR?
With `mdbook build --open` for example.
### 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.
Needed for CI of https://github.com/rust-lang/rust/pull/150055 to pass.
Also: I used a full URL instead of a relative path to avoid this can
kind of issues in the future since `cargo` is a submodule and not a
subtree.
@ehuss [made a
comment](https://github.com/rust-lang/cargo/pull/16391#issuecomment-3649925243)
saying that `cargo` should set `__CARGO_TEST_TTY_WIDTH_DO_NOT_USE_THIS
to a very large value to avoid problems with long paths in tests. This
PR does that by setting it to `200` (the previous default was `140`).
Note: `200` is a start, and we can always go up if needed
This updates the contributor guide with more information about what
services and permissions are available to the Cargo team. This is
primarily to capture that we have a new `rust-lang/cargo-team`
repository. I took the opportunity to update some related information.
This updates the contributor guide with more information about what
services and permissions are available to the Cargo team. This is
primarily to capture that we have a new `rust-lang/cargo-team`
repository. I took the opportunity to update some related information.
### 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?
