### What does this PR try to resolve?
Telling people they are free to hit ctrl-c while waiting for packages
could mean some packages may not be published and the user wouldn't know
until they get a complaint about a missing package.
Instead, if there are remaining packages, we'll tell the user that.
Fixes#15005
### How to test and review this PR?
### What does this PR try to resolve?
The `clippy::perf` lint group is fairly useful for catching bad
practices that might hurt performance marginally.
This PR fixes most of them except `clippy::large_enum_variant`, which
doesn't feel right at this moment and need more researches. And that is
why I didn't enable the lint group.
### How to test and review this PR?
The `clippy::perf` lint group is fairly useful for catching bad
practices that might hurt performance marginally.
This PR fixes most of them except `clippy::large_enum_variant`,
which doesn't feel right at this moment and need more researches.
Anyway, overall this PR should be good.
### What does this PR try to resolve?
As of #13947, `-Zpackage-workspace` made `cargo package` require extra
arguments when it didn't need it before. When a packaging operation will
resolve dependencies, we need to know what registry packages would be
published to in order to correctly generate the overlay to generate the
right lockfile.
We skipped this if there were no dependencies, so no overlay was going
to be used, to reduce the impact of this.
This change goes a step further and only runs the check if the resolver
will run. This should mean that `-Zpackage-workspace` should now only
error when `cargo package` would have failed before.
### How to test and review this PR?
To verify this, the existing failure tests were forked, removing
`-Zpackage-workspace`, and then `--exclude-lockfile`, `--no-verify`, and
`--exclude-lockfile --no-verify` variants were added to characterize
when the check is behavior-neutral vs not needed and that the behavior
is now the same.
_Thanks for the pull request 🎉!_
_Please read the contribution guide: <https://doc.crates.io/contrib/>._
### What does this PR try to resolve?
Bash and Zsh `cargo add` completion option `--offline`
_Explain the motivation behind this change._
_A clear overview along with an in-depth explanation are helpful._
### How to 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._
Previously, libsecret was repeatedly loaded and unloaded—at least twice
during cargo login (once for action get and once for action login). This
caused issues where calls could hang indefinitely due to glib failing to
clean up properly (some threads still running after unloading) and
generating numerous error messages:
```
cargo login --registry ownreg
Updating `ownreg` index
please paste the token for ownreg below
(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: cannot register existing type 'SecretService'
(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: cannot add private field to invalid (non-instantiatable) type '<invalid>'
(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed
(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed
(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: cannot register existing type 'SecretBackend'
(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed
(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed
(process:100727): GLib-CRITICAL **: 08:59:54.568: g_once_init_leave_pointer: assertion 'result != 0' failed
(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed
```
Now, libsecret is stored in a OnceLock, ensuring it is only loaded once,
preventing unnecessary unload/reload cycles.
Fixes#15603
Previously, LibSecretCredential was created multiple times and with it
libsecret was loaded and unloaded multiple times, leading to issues
where calls could run indefinitely due to glib not properly cleaning up.
Now, LibSecretCredential is stored in a OnceLock, ensuring it is only
created once, preventing unnecessary unload/reload cycles of libsecret.
### What does this PR try to resolve?
Attempting to reduce the size of the stabilization PR so the
stabilization changes are more obvious, without pulling something out
that is meaningless.
### How to test and review this PR?
### What does this PR try to resolve?
Found this as I was preparing for stabilization.
As we create a graph of packages to ensure publish order, a self-cycle
shouldn't matter, so we can skip tracking it.
### How to test and review this PR?
`obj` is already `&T`.
<!--
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?
Remap all paths pointing to `build.build-dir`,
i.e., `[BUILD_DIR]/debug/deps/foo-[HASH].dwo` would be remapped to
`/cargo/build-dir/debug/deps/foo-[HASH].dwo`
(note the `/cargo/build-dir` prefix).
This covers scenarios like:
* Build script generated code. For example, a build script may call
`file!`
macros, and the associated crate uses `include!` to include the expanded
`file!` macro in-place via the `OUT_DIR` environment.
* On Linux, `DW_AT_GNU_dwo_name` that contains paths to split debuginfo
files (dwp and dwo).
### How to test and review this PR?
Should be quite straightforward.
The open question is what we want to remap _to_, to help debugger to
find the source files.
cc #12137 and #13171
Remap all paths pointing to `build.build-dir`,
i.e., `[BUILD_DIR]/debug/deps/foo-[HASH].dwo` would be remapped to
`/cargo/build-dir/debug/deps/foo-[HASH].dwo`
(note the `/cargo/build-dir` prefix).
This covers scenarios like:
* Build script generated code. For example, a build script may call `file!`
macros, and the associated crate uses [`include!`] to include the expanded
[`file!`] macro in-place via the `OUT_DIR` environment.
* On Linux, `DW_AT_GNU_dwo_name` that contains paths to split debuginfo
files (dwp and dwo).
### What does this PR try to resolve?
Before this some end-to-end tests didn't cover Windows platforms.
After this, we cover windows-msvc for
* End-to-end debugger tests.
* Check path is trimmed with symbol viewers like `strings`.
windows-gnu isn't covered
### How to test and review this PR?
There are things needing attentions:
* This adds a new CI job for window-msvc "nightly" toolchain.
* In 2f923b3ff25f847d we don't check if an executable's availability by
running `<cmd> --version`. Instead, we check the file execute bit.
* Enabled windows-msvc tests rely on the software provided by [GitHub
windows runner
image](e330e24b7e/images/windows/Windows2022-Readme.md)
* Windows SDK which provides cdb and other debugger tools
* `strings` is provided by MinGW.
### What does this PR try to resolve?
This was discovered during playing with rmeta reuse between cargo-check
and cargo-build.
An rmeta mtime failure is basically the same as "failed to read
metadata".
While we don't report in tracing log, that should be fine because dirty
reason will be reported in the other place.
### How to test and review this PR?
Should have no real user-facing behavior change.
GitHub Actions has Windows SDK pre-installed,
so cdb should be available at that path always.
Additionally, this adds a new CI job for windows-msvc nightly toolchain
Not every executable has a `--version` flag.
Let's check the exectuability instead.
Note that on Windows we check if it is file only.
There is a `is_executable` crate on crates.io,
though that still depend on winapi so don't bother using it.
### What does this PR try to resolve?
This PR fixes a bug where `cargo add` breaks symlinks to Cargo.toml
files. Currently, when Cargo.toml is a symlink and `cargo add` is used
to add a dependency, the symlink is replaced with a regular file,
breaking the link to the original target file.
This issue was reported in #15241 where a user who relies on symlinked
Cargo.toml files found that `cargo add` breaks their workflow.
Fixes#15241
### How should we test and review this PR?
I've modified `LocalManifest::write()` to check if the path is a
symlink, and if so, follow it to get the actual target path. This
ensures we write to the actual file rather than replacing the symlink.
I've also added a test in `tests/testsuite/cargo_add/symlink.rs` that:
1. Creates a symlinked Cargo.toml file
2. Runs `cargo add` to add a dependency
3. Verifies the symlink is preserved and the dependency is added to the
target file
I've manually tested this fix and confirmed it works correctly.
- Preserve symlinks when writing files atomically in write_atomic()
- Update test to verify correct symlink preservation behavior
- Apply rustfmt formatting
This fixes the issue where cargo add would replace symlinked Cargo.toml
files with regular files, breaking the symlink to the original target.
Fixes#15241
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| alpine | final | minor | `3.21` -> `3.22` |
---
### Configuration
📅 **Schedule**: Branch creation - "before 5am on the first day of the
month" (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:eyJjcmVhdGVkSW5WZXIiOiI0MC4zMy42IiwidXBkYXRlZEluVmVyIjoiNDAuMzMuNiIsInRhcmdldEJyYW5jaCI6Im1hc3RlciIsImxhYmVscyI6W119-->
