### What does this PR try to resolve?
While doing some investigation on the theoretical performance
implications of #4282 (and #15010 by extension) I was profiling cargo
with some experimental changes. (Still a work in progress)
But in the mean time, noticed that we do not have spans for rustc
invocations. I think these would be useful when profiling `cargo build`.
(`cargo build --timing` exists but is more geared towards debugging a
slow building project, not cargo itself)
For reference below is an example before/after of a profile run of a
dummy crate with a few random dependencies.
#### Before
#### After
### What does this PR try to resolve?
The `target_short_hash` function is a fallback used by the `pkg_dir`
function for units that should not generate `-C extra-filename`.
This makes the function private since it would be easy to misuse and
fixes an outdated method name in the doc comment.
### How should we test and review this PR?
Trivial.
Suggest to user to use a crate name with an inserted @ before the first
invalid package name character
Fixes#15318
<!--
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?
The "1 tries remaining" message is boring, "1 try remaining" seems
better.
### How should we test and review this PR?
Run `cargo update` without network and watch the output messages.
This proposes to stabilize automatic garbage collection of Cargo's
global cache data in the cargo home directory.
### What is being stabilized?
This PR stabilizes automatic garbage collection, which is triggered at
most once per day by default. This automatic gc will delete old, unused
files in cargo's home directory.
It will delete files that need to be downloaded from the network after 3
months, and files that can be generated without network access after 1
month. These thresholds are intended to balance the intent of reducing
cargo's disk usage versus deleting too often forcing cargo to do extra
work when files are missing.
Tracking of the last-use data is stored in a sqlite database in the
cargo home directory. Cargo updates timestamps in that database whenever
it accesses a file in the cache. This part is already stabilized.
This PR also stabilizes the `gc.auto.frequency` configuration option.
The primary use case for when a user may want to set that is to set it
to "never" to disable gc should the need arise to avoid it.
When gc is initiated, and there are files to delete, there will be a
progress bar while it is deleting them. The progress bar will disappear
when it finishes. If the user runs with `-v` verbose option, then cargo
will also display which files it deletes.
If there is an error while cleaning, cargo will only display a warning,
and otherwise continue.
### What is not being stabilized?
The manual garbage collection option (via `cargo clean gc`) is not
proposed to be stabilized at this time. That still needs some design
work. This is tracked in
https://github.com/rust-lang/cargo/issues/13060.
Additionally, there are several low-level config options currently
implemented which define the thresholds for when it will delete files. I
think these options are probably too low-level and specific. This is
tracked in https://github.com/rust-lang/cargo/issues/13061.
Garbage collection of build artifacts is not yet implemented, and
tracked in https://github.com/rust-lang/cargo/issues/13136.
### Background
This feature is tracked in
https://github.com/rust-lang/cargo/issues/12633 and was implemented in a
variety of PRs, primarily https://github.com/rust-lang/cargo/pull/12634.
The tests for this feature are located in
https://github.com/rust-lang/cargo/blob/master/tests/testsuite/global_cache_tracker.rs.
Cargo started tracking the last-use data on stable via
https://github.com/rust-lang/cargo/pull/13492 in 1.78 which was released
2024-05-02. This PR is proposing to stabilize automatic deletion in 1.82
which will be released in 2024-10-17.
### Risks
Users who frequently use versions of Rust older than 1.78 will not have
the last-use data tracking updated. If they infrequently use 1.78 or
newer, and use the same cache files, then the last-use tracking will
only be updated by the newer versions. If that time frame is more than 1
month (or 3 months for downloaded data), then cargo will delete files
that the older versions are still using. This means the next time they
run the older version, it will have to re-download or re-extract the
files.
The effects of deleting cache data in environments where cargo's cache
is modified by external tools is not fully known. For example, CI
caching systems may save and restore cargo's cache. Similarly, things
like Docker images that try to save the cache in a layer, or mount the
cache in a read-only filesystem may have undesirable interactions.
The once-a-day performance hit might be noticeable to some people. I've
been using this for several months, and almost never notice it. However,
slower systems, or situations where there is a lot of data to delete
might take a while (on the order of seconds hopefully).
This updates the flags used for doctest xcompile to match the upstream
changes in https://github.com/rust-lang/rust/pull/137096 which renamed
and stabilized the flags.
This cannot be merged until after nightly is published tonight.
### What does this PR try to resolve?
I recently depended on a package with `preserve-order` rather than
`preserve_order` and the error message didn't help me with the problem
so I figure I'd fix that. I also found other improvements along the way
- Suggest an alternative feature when a feature includes a missing
feature
- Suggest an alternative feature when a dependency includes a missing
feature
- Lower case error messages
- Re-frame prescriptive information as help
- Change plural "features" error messages to singular "feature" as they
can only ever have one (knowing an the `MissingFeature` string only has
one feature in it was important for doing a `closest` match on the
feature).
### How should we test and review this PR?
### Additional information
### What does this PR try to resolve?
Fixes#15445, where there were still differences between the format of
package ids of "`cargo metadata` and build JSON messages", and
`--unit-graph` package ids.
### How should we test and review this PR?
Everything compiles correctly (and outputs what's expected). I also
fixed the testcases
changes summary :
- change the `pkg_id` field of `struct SerializedUnit<'a>` to be `PackageIdSpec` instead of `PackageId`
- change the unit-graph testcases to match the changes
(cleaning previous commits so every commit passes CI checks, as required)
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
|
[cargo-semver-checks](https://redirect.github.com/obi1kenobi/cargo-semver-checks)
| minor | `0.40.0` -> `0.41.0` |
---
### Release Notes
<details>
<summary>obi1kenobi/cargo-semver-checks (cargo-semver-checks)</summary>
###
[`v0.41.0`](https://redirect.github.com/obi1kenobi/cargo-semver-checks/compare/v0.40.0...v0.41.0)
[Compare
Source](https://redirect.github.com/obi1kenobi/cargo-semver-checks/compare/v0.40.0...v0.41.0)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - Every minute ( * * * * * ) (UTC),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/rust-lang/cargo).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4yNDguNCIsInVwZGF0ZWRJblZlciI6IjM5LjI0OC40IiwidGFyZ2V0QnJhbmNoIjoibWFzdGVyIiwibGFiZWxzIjpbXX0=-->
<!--
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?
remove duplicate word in comment
### 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.
-->
remove duplicate word in comment
Because the last string in this match statement was over 100 characters,
it prevented rustfmt from formatting the entire thing. By wrapping it,
that allows rustfmt to do its job.
Because the last string in this match statement was over 100 characters,
it prevented rustfmt from formatting the entire thing. By wrapping it,
that allows rustfmt to do its job.
### What does this PR try to resolve?
This PR uses `zlib-rs` via the `flate2` crate. It is used for
(de)compressing gzip files (e.g. in `cargo package`).
Using zlib-rs is significantly faster, and produces output of roughly
similar size. For the `windows-bindgen` crate
(a very large crate), the speedup is over 60%, or about 2 seconds.
```
> time cargo package -p windows-bindgen --no-verify
Packaging windows-bindgen v0.61.0 (/home/folkertdev/rust/windows-rs/crates/libs/bindgen)
Updating crates.io index
Packaged 76 files, 31.2MiB (8.2MiB compressed)
________________________________________________________
Executed in 3.30 secs fish external
usr time 3.19 secs 424.00 micros 3.19 secs
sys time 0.05 secs 61.00 micros 0.05 secs
> time ~/rust/cargo/target/release/cargo package -p windows-bindgen --no-verify
Packaging windows-bindgen v0.61.0 (/home/folkertdev/rust/windows-rs/crates/libs/bindgen)
Updating crates.io index
Packaged 76 files, 31.2MiB (8.3MiB compressed)
________________________________________________________
Executed in 1.25 secs fish external
usr time 1.15 secs 0.00 micros 1.15 secs
sys time 0.04 secs 589.00 micros 0.04 secs
```
### How should we test and review this PR?
Generally CI/the test suite should handle correctness.
Something to look out for is zlib-rs producing larger binaries than
before. So far we're seeing output sizes that are roughly the same
(sometimes a bit better, sometimes a bit worse) as the status quo.
We've not specifically looked at decompression yet, mostly because we
could not come up with a good command to benchmark. In general zlib-rs
is much faster than stock zlib there too.
### Additional information
For the time being, `cargo` still depends on stock zlib via e.g. `curl`
and `git`. As far as I know it is the intention to eventually move away
from these C dependencies, at which point the dependency on stock zlib
also disappears.
### What does this PR try to resolve?
- separates each test into different test cases
- `snapbox` is used to test the snapshots
- difference in `.json` file alone should never cause a test to fail
- `.json` files updated only if expected fix != actual fix &&
`SNAPSHOTS=overwrite`
- when `.json` files are updated, the json is pretty printed
- replaced environment variables `RUSTFIX_TEST_*` for overwriting test
snapshots with `SNAPSHOTS=overwrite`
- ❗ The `RUSTFIX_TEST_RECORD_FIXED_RUST` feature is removed (generate a
`*.fixed.rs` on demand`). We can add it back whenever needed.
Fixes#13891
### How should we test and review this PR?
Run tests with:
```sh
cargo test -p rustfix
```
All the test should run as different test cases
nightly tests run only when using nightly version of rustc is used
If a library exists both in an added folder inside OUT_DIR and in the
OS, prefer to use the one within OUT_DIR. Folders within OUT_DIR and
folders outside OUT_DIR do not change their relative order between
themselves.
This is accomplished by sorting by whether we think the path is inside
the search path or outside.
### What does this PR try to resolve?
Fixes#15220. If a Rust crates builds a dynamic library & that same
dynamic library is installed in the host OS, the result of the build's
success & consistent behavior of executed tools depends on whether or
not the user has the conflicting dynamic library in the external search
path. If they do, then the host OS library will always be used which is
unexpected - updates to your Rust dependency will still have you linking
& running against an old host OS library (i.e. someone who doesn't have
that library has a different silent behavior).
### How should we test and review this PR?
This is what I did to verify my issue got resolved but I'm sure there's
a simpler example one could construct.
* Make sure Alsa and libllama.so are installed (on Arch I installed
alsa-lib and llama.cpp-cuda).
* Clone llama-cpp-2 & init llama.cpp submodule & update the submodule to
point to https://github.com/ggml-org/llama.cpp/pull/11997 instead.
* Add plumbing to expose the new method within llama-cpp-2 as a public
facing function on the LlamaModel struct (it's basically the same code
as for n_head, just calling n_head_kv from llama.cpp).
* Add cpal as a dependency in crate "foo"
* Add llama-cpp-2 via path as a dependency in crate "foo" and enable the
`dynamic-link` feature.
* Add code using the newly expose n_head_kv method in crate "foo" in
main.rs. NOTE: Code just needs to compile & be exported, doesn't have to
be correct (fn main is probably easiest.
* Add some basic code that tries to initialize cpal in crate "foo" in fn
main.
* Try to build / run crate "foo"
Before my change, it fails with a linker error saying it can't find
`llama_model_n_head_kv` because /usr/lib appears in the search path
before the directory that contains the libllama.so that was built
internally by the crate. This is because cpal depends on alsa-sys which
uses pkg-config which adds /usr/lib to the search path before the
llama-cpp-sys-2 build.rs is run.
### Additional information
I'm not sure how to add tests so open to some help on that. I wanted to
make sure that this approach is even correct. I coded this to change
Cargo minimally and defensively since I don't know the internals of
Cargo very well (e.g. I don't know if I have to compare against both
`script_out_dir` / `script_out_dir_when_generated` since I don't know
the difference & there's not really any explanation on what they are).
It's possible this over-complicates the implementation so open to any
feedback. Additionally, the sort that happens prior to each build up of
the rustc environment is not where I'd ideally place it. I think it
would be more efficient to have the list of search paths be
free-floating and not tied to a BuildOutput so that they could be kept
updated live & resorted only on insertion (since it's changed less
frequently than rustc is invoked). Additionally, the generalized sort is
correct but pessimistic - maintaining the list sorted could be done
efficiently with some minor book keeping (i.e. you'd only need to sort
the new paths & then could quickly inject into the middle of a
VecDeque).
And of course in terms of correctness, I didn't do a thorough job
testing across all possible platforms. From first principles this seems
directionally correct but it's always possible this breaks someone
else's workflow. I'm also uneasy that the relative position of `-L` /
`-l` arguments changes in this PR & I'm not sure if that's observable
behavior or not (i.e. it used to be -L for a crate followed by `-l` for
a crate), but now it's `-L` for all crates, still grouped by crated
internally, followed by `-l` by crate).
