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).
### What does this PR try to resolve?
Bad copy/paste in #14902
### How should we test and review this PR?
### Additional information
Found this when looking at how we handle MSRV in `build-rs`
### What does this PR try to resolve?
This reverts commit 71ea2e5c5fa285e8e0336d51fd03ba4a427154bf.
`Repository::discover` and `Repository::status_file` are too expenstive
to run inside a loop. And `cargo package` are doing a lot of duplicate
works for checking submodule VCS status.
Alternative fixes might look like
* Let `status_submodules` function returns a path entry set, so
Cargo can check whether a source file is dirty based on that.
* When listing files in `PathSource`, attach the VCS status of a
path entry assoicated with. Then subsequent operations can skip
status check entirely.
However, the above solutions are not trivial, and the dirtiness check is
informational only based on T-cargo conclusion, so we should be
good just reverting the change now.
Again, the caveat of this is that we can't really detect
dirty symlinks that link into a Git submodule.
### How should we test and review this PR?
Should be good to merge. We still got #15384 fixed via
d760263afb02c747a246bb0471a4f51e09075246
### Additional information
See
<https://github.com/rust-lang/cargo/issues/15384#issuecomment-2797064033>.
This reverts commit 71ea2e5c5fa285e8e0336d51fd03ba4a427154bf.
`Repository::discover` and `Repository::status_file` are too expenstive
to run inside a loop. And `cargo package` are doing a lot of duplicate
works for checking submodule VCS status.
The possible fix might look like
* Let `status_submodules` function returns a path entry set, so
Cargo can check whether a source file is dirty based on that.
* When listing files in `PathSource`, attach the VCS status of a
path entry assoicated with. Then subsequent operations can skip
status check entirely.
The above solutions are not trivial, and the dirtiness check is
informational only based on T-cargo conclusion, so we should be
good just reverting the change now.
Again, the caveat of this is that we can't really detect
dirty symlinks that links into a Git submodule.
### What does this PR try to resolve?
This PR improves the error message when an invalid template variable is
used in the `build.build-dir` config.
I am using `closest_msg` to find a close match. If there are no close
matches, we simply print the available template variables list.
See #14125
r? @epage
Regardless of crate search paths emitted, always prefer searching search
paths pointing into the artifacts directory to those pointing outside.
This way libraries built by Cargo are preferred even if the same library
name exists in the system & a crate earlier in the build process emitted
a system library path for searching.
### 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.
Various C dependencies (curl, git) still rely on `libz-sys`, so for the time being a system libc is still required. But, using zlib-rs via flate2 is straightforward, and gives good speedup for `cargo package`. It is also extremely portable, because it's just rust code.
Bumps [crossbeam-channel](https://github.com/crossbeam-rs/crossbeam)
from 0.5.14 to 0.5.15.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/crossbeam-rs/crossbeam/releases">crossbeam-channel's
releases</a>.</em></p>
<blockquote>
<h2>crossbeam-channel 0.5.15</h2>
<ul>
<li>Fix regression introduced in 0.5.12 that can lead to a double free
when dropping unbounded channel. (<a
href="https://redirect.github.com/crossbeam-rs/crossbeam/issues/1187">#1187</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="d35ffde18a"><code>d35ffde</code></a>
Prepare for the next release</li>
<li><a
href="6ec74ecae8"><code>6ec74ec</code></a>
crossbeam-channel: prevent double free on Drop (<a
href="https://redirect.github.com/crossbeam-rs/crossbeam/issues/1187">#1187</a>)</li>
<li>See full diff in <a
href="https://github.com/crossbeam-rs/crossbeam/compare/crossbeam-channel-0.5.14...crossbeam-channel-0.5.15">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/rust-lang/cargo/network/alerts).
</details>
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.
<!--
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?
Follow up to #15377 that documents `build_directory` in the cargo
metadata docs.
I did not mention that this feature is not stable yet, let me know if it
would be better to a note that this is nightly only.
Not sure how we normally handle documenting non-stable features
cc: #14125
### What does this PR try to resolve?
This PR adds logic to resolve symlinks before hashing the
`workspace-path-hash` template variable for `build.build-dir`.
See
https://github.com/rust-lang/cargo/issues/14125#issuecomment-2751658701
cc: #14125
Note: The behavior on unix systems is unchanged, as the manifest_path
was already canonicalized (at least on my system and in CI). However,
the Windows behavior did not do this previous.
### How should we test and review this PR?
I added a test which runs `cargo build` twice, once from the real
directory and once from inside of a symlinked directory, then verifies
that hashes match.
The change is only a few lines. Most of the diffs are testing code
r? @epage
Resolves#15401
Here is an example of the feature in
[kitty](https://sw.kovidgoyal.net/kitty/) `0.40.1` with the following
config set in `~/.config/kitty/kitty.conf`
```conf
underline_hyperlinks always
show_hyperlink_targets yes
allow_hyperlinks yes
# ...
```
Tested on `uname -a`:
```
Linux nixos 6.14.0 #1-NixOS SMP PREEMPT_DYNAMIC Mon Mar 24 14:02:41 UTC 2025 x86_64 GNU/Linux
```
Terminals tested with:
- [x] [kitty](https://sw.kovidgoyal.net/kitty/) `0.40.1`
- [x] [ghostty](https://ghostty.org/) `1.1.4-6f1b22a-nix`
- [x] [alacritty](https://alacritty.org/index.html) `0.15.1`
- [x] VScode's version `1.98` integrated terminal aka.
[xterm.js](https://xtermjs.org/)
The following `cargo` invocations will have their output be modified by
this change:
```shell
cargo run # If multiple binaries are defined in the manifest and [package.default-bin] is not defined
cargo run --bin
cargo run --example
cargo run --package
cargo build --bin
cargo build --example
cargo build --package
cargo test --test
cargo test --bench
```
In addition I have done a slight refactor to have the printed indent of
targets and packages be the same by using a shared constant named `const
ITEM_INDENT: &str = " ";`
This is my first PR to the cargo codebase, so I am not familiar with
what is expected in terms of test for a feature such as this.
<!--
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.
-->
