Publish workspace
Adds support for simultaneously publishing multiple (possibly inter-dependent) packages in a workspace, gated by the `-Zpackage-workspace` flag.
Questions to be worked out through stabilization:
- Are we ok stabilizing this and #10948 at the same time? Currently, they are behind the same flag
- What is the desired behavior for the publish timeout? This PR uploads the crates in batches (depending on the dependency graph), and we only timeout if nothing in the batch is available within the timeout, deferring the rest to the next wait-for-publish. So for example, if you have packages `a`, `b`, `c` then we'll wait up to 60 seconds and if only `a` and `b` were ready in that time, we'll then wait another 60 seconds for `c`.
- What is the desired behavior when some packages in a workspace have `publish = false`? This PR raises an error whenever any of the selected packages has `publish = false`, so it will error on `cargo publish --workspace` in a workspace with an unpublishable package. An alternative interface would implicitly exclude unpublishable packages in this case, but still error out if you explicitly select an unpublishable package with `-p package-name` (see #14356). This PR's behavior is the most conservative one as it can change from an error to implicit excludes later.
This is part of #1169
Bump ci's version of cargo-semver-version
I just started seeing CI failures like this:
```
error: rustdoc format v33 for file /home/jneeman/tweag/cargo/target/semver-checks/local-cargo-0_83_0/target/semver-checks/target/doc/cargo.json is not supported
```
I think the issue is that the new rust version needs a new cargo-semver-checks, so this PR bumps the version of cargo-semver-checks in CI.
uplift windows gnullvm import libraries
Same changes as #8141, but for gnullvm.
gnullvm does not seem to be tested in CI, so tests were not adjusted.
### What does this PR try to resolve?
The `implib` for [gnullvm](https://doc.rust-lang.org/rustc/platform-support/pc-windows-gnullvm.html) targets should end up at the same location as for `gnu` targets.
### Background
I'm not a windows developer, so I may be wrong, but I believe the implib artifacts for gnullvm should be needed in the same way as for the normal windows-gnu target. In my downstream code, I need to know the location of the implib artifact, and would prefer for the location to be the same for both gnullvm and normal gnu.
Fix cargo add behaving different when translating package name
Fixes#13702Fixes#10680
TODOs
- [x] ~Fuzzy match registry dependencies in `cargo remove` as well~
`cargo remove` does not need fuzzy matching, because there is no unexpected behavior for the user
- [x] ~Don't duplicate name permutation generation~
Unsure whether this is worth it
- [ ] Shall we reject cases where multiple different permutations match?
- [x] Add comments that explain the behavior
chore(deps): update rust crate core-foundation to 0.10.0
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [core-foundation](https://togithub.com/servo/core-foundation-rs) | workspace.dependencies | minor | `0.9.4` -> `0.10.0` |
---
### Release Notes
<details>
<summary>servo/core-foundation-rs (core-foundation)</summary>
### [`v0.10.0`](https://togithub.com/servo/core-foundation-rs/compare/core-foundation-v0.9.4...core-foundation-v0.10.0)
[Compare Source](https://togithub.com/servo/core-foundation-rs/compare/core-foundation-v0.9.4...core-foundation-v0.10.0)
</details>
---
### 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:eyJjcmVhdGVkSW5WZXIiOiIzOC41Ni4wIiwidXBkYXRlZEluVmVyIjoiMzguNTYuMCIsInRhcmdldEJyYW5jaCI6Im1hc3RlciIsImxhYmVscyI6W119-->
feat(resolve): Report MSRV compatible version instead of incomptible
### What does this PR try to resolve?
This expands on #14461 to where only MSRV-compatible versions are
"actionable". MSRV-incompatible versions are therefore unstyled.
We report the MSRV needed so people can choose to unblock by updating
their MSRV. I had wondered if we should report the the absolute latest
MSRV-incompatible version or the one with the next higher MSRV from
where the user is at. Both are reasonable use cases, so I erred with
absolute latest version.
```console
$ cargo update --workspace -v
```
### How should we test and review this PR?
I changed the label from `latest` to `available` to not have to keep coming up with relevant terms for each case.
### Additional information
This is the final step before asking for new feedback on #13908
Don't automatically include the current crate when packaging
This replicates some of the changes in #10677 while packaging. It was split off from #14433
Fix elided lifetime
This fixes an issue with the recent nightly that has added a lint (https://github.com/rust-lang/rust/pull/129207) that warns about the lack of a lifetime, which looks like:
```
warning: elided lifetime has a name
--> src/cargo/core/workspace.rs:580:66
|
580 | pub fn default_members<'a>(&'a self) -> impl Iterator<Item = &Package> {
| -- lifetime `'a` declared here ^ this elided lifetime gets resolved as `'a`
|
= note: `#[warn(elided_named_lifetimes)]` on by default
```
chore(deps): update rust crate pasetors to 0.7.0
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [pasetors](https://togithub.com/brycx/pasetors) | workspace.dependencies | minor | `0.6.8` -> `0.7.0` |
---
### Release Notes
<details>
<summary>brycx/pasetors (pasetors)</summary>
### [`v0.7.0`](https://togithub.com/brycx/pasetors/blob/HEAD/CHANGELOG.md#070)
[Compare Source](https://togithub.com/brycx/pasetors/compare/0.6.8...0.7.0)
**Date:** August 28, 2024.
- Bump MSRV to `1.80`.
- Updated test vectors for `v3.public`.
- (*BREAKING*) Improved error-handling during claims validation. Added `Error::ClaimValidation(ClaimValidationError)`, where `ClaimValidationError` now further specifies the validation error ([#​131](https://togithub.com/brycx/pasetors/pull/131), credits: [`@​jpramosi](https://togithub.com/jpramosi)).`
</details>
---
### 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:eyJjcmVhdGVkSW5WZXIiOiIzOC41Ni4wIiwidXBkYXRlZEluVmVyIjoiMzguNTYuMCIsInRhcmdldEJyYW5jaCI6Im1hc3RlciIsImxhYmVscyI6W119-->
This expands on #14461 to where only MSRV-compatible versions are
"actionable". MSRV-incompatible versions are therefore unstyled.
We report the MSRV needed so people can choose to unblock by updating
their MSRV. I had wondered if we should report the the absolute latest
MSRV-incompatible version or the one with the next higher MSRV from
where the user is at. Both are reasonable use cases, so I erred with
absolute latest version.
fix(resolve): With `latest` message, differentiate actionable updates
### What does this PR try to resolve?
Instead of always listing the absolutely latest version as a warning
color, we now differentiate
- compatible updates are always actionable
- incompatible, direct deps are always actionable
These get reported and made yellow while non-actionable messages are
unstyled.
### How should we test and review this PR?
I just used a broad stroke to say "compatible" in the message means "semver
compatible" and use `^`
- We could focus on "compatible with dependent version reqs" which is
what will be most actionable but seeing if we can get away without
having to track all in-coming version reqs.
- We could be more nuanced in language but the more verbose we are, the
more we take away from higher priority messages
### Additional information
This is not intended as *the* solution for #13908 though it experiments with what to do for that.
This is prep work for improved MSRV reporting where we will
differentiate this further by only considering MSRV-compatible updates as actionable
(or rustc-compatible when not using MSRV-aware reslver).
fix(pkgid): Allow open namespaces in PackageIdSpec's
### What does this PR try to resolve?
This is a part of #13576
This unblocks #14433. We have a test to ensure you can't publish a namespaced package and the error for that is getting masked in #14433 because the package name is getting parsed as a `PackageIdSpec` which wasn't supported until this PR.
### How should we test and review this PR?
### Additional information
feat(resolve): Report incompatible-with-rustc when MSRV-resolver is disabled
### What does this PR try to resolve?
This builds on #14457 to report when deps are incompatible with rustc when an MSRV-aware resolver is not used.
This affects stable code.
### How should we test and review this PR?
### Additional information
Instead of always listing the absolute latest version as a warning
color, we now differentiate
- compatible updates are always actionable
- incompatible, direct deps are always actionable
These get reported and made yellow while non-actionable messages are
unstyled.
This is not intended as *the* solution for #13908 though it makes
improvements in that direction.
This is prep work for improved MSRV reporting where we will
differentiate this further by only considering MSRV-compatible updates as actionable
(or rustc-compatible when not using MSRV-aware reslver).
I just used a broad stroke to say "compatible" in the message means "semver
compatible" and use `^`
- We could focus on "compatible with dependent version reqs" which is
what will be most actionable but seeing if we can get away without
having to track all in-coming version reqs.
- We could be more nuanced in language but the more verbose we are, the
more we take away from higher priority messages
fix(resolve): Report incompatible packages with precise Rust version
### What does this PR try to resolve?
In #14401, we reported about MSRV issues as if we were the resolver. We can be smarter than that though and report precise MSRV information. This allows us to elevate the message from color from yellow to red.
This is also prep work for telling users when a newer, MSRV-compatible version of a package is available.
### How should we test and review this PR?
The report function I added is a little odd because a follow up commit will update it to report when a package is incompatible with rustc when the MSRV resolver is disabled and do this on stable.
### Additional information
This builds on #14445 to improve #14401
fix(resolve): Dont show locking workspace members
### What does this PR try to resolve?
This is for `cargo generate-lockfile` and when syncing the lockfile with
the manifest.
We still show it for `cargo update` because of `cargo update
--workspace`.
We hacked around this previously by filtering out the `num_pkgs==1` case
for single packages but this didn't help with workspaces.
### How should we test and review this PR?
### Additional information
This builds on #14440
