feat: Add native comlpetion with CompleteEnv under the nightly
### What does this PR try to resolve?
Related issue https://github.com/rust-lang/cargo/issues/6645
Tracking issue https://github.com/rust-lang/cargo/issues/14520
This PR is the first step to move cargo shell completions to native completions by using `clap_complete` crate. It makes users could complete cargo subcommand and flags.
By using `clap_complete` crate, we could extend the supported shells to Bash, Zsh, Elvish, Fish, and PowerShell. However, at the current stage, the support for PowerShell in `clap_complete` is not fully developed.
See https://github.com/clap-rs/clap/issues/3166 to get more context about what features `clap_complete` has supported.
### How to test and review this PR?
1. Build a test environment, including the necessary short completion scripts, and the `complete` function to start an interactive shell with the help of a pty device and obtain completion results.
2. Simply test the completion results of subcommands in bash, zsh, fish, elvish.
fix(new): Add to workspace relative to manifest, not current-dir
### What does this PR try to resolve?
We were correctly doing this for cases like `cargo new foo` or
`cargo new deeper/than/this/directory/foo` but not `cargo new ../foo`.
This came up when discussing #14501
### How should we test and review this PR?
### Additional information
Fix parsing of comma separated values in --crate-type flag
### What does this PR try to resolve?
According to the documentation the `--crate-type` flag accepts a comma separated list of crate types. However, these are never actually split into individual items and passed verbatim to rustc.
Since cargo fails to associate cases such as 'staticlib,cdylib' to a specific crate type internally, it has to invoke rustc to determine the output file types for this unknown crate type, which returns only the first file type of the first crate type in the list. Consequently cargo will be looking only for a single '.a' artifact on Linux to be copied to the target directory.
Fix this by splitting the list of provided crate types into individual items before further processing them.
Fixes#14498
### How should we test and review this PR?
Updated corresponding test cases
### Additional information
Include public/private dependency status in `cargo metadata`
fixes#14502
> [!TIP]
> This change can be reviewed commit-by-commit.
> Descriptions on individual commits are available to justify some decisions
`@rustbot` label Command-metadata Z-public-dependency
docs: bin source can be `src/main.rs` and/or in `src/bin/`
### What does this PR try to resolve?
This commit clarifies the doc by stating we can place a binary source as `src/main.rs` and/or in `src/bin/`.
Wording is suggested by Ed Page (`@epage).`
### How should we test and review this PR?
(It seems the only way is to check the chenge visually...)
### Additional information
Closes#14463.
This commit clarifies the doc by stating we can place a binary source as `src/main.rs` and/or in `src/bin/`.
Wording is suggested by Ed Page (@epage).
Closes#14463.
This change introduces a new method, `Dependency::serialized` which replaces the direct `Serialize` implementation on `Dependency`.
This matches the pattern used by `Package` with its `Package::serialized`, and will enable us to influence the serialization format with additional arguments.
I replaced borrowed types in `SerializedDependency` with owned variants to satisfy the borrow checker.
This matches `SerializedPackage` and shouldn't be an issue since `Dependency` is cheap to copy.
fix(toml): Don't require MSRV bump for pub/priv
### What does this PR try to resolve?
In #13308, we decided to make the feature gate for public/private dependencies non-blocking.
Generally, people opt-in to a feature that is non-blocking through `-Z` but some nightly users want an "always on" mode for this, so we offered both in #13340.
In #13340, we made both feature gates work but we did not make them non-blocking for stable, only nightly.
This change makes the feature gate non-blocking on stable.
Unfortunately, this means that 1.83 will be the MSRV for people using public dependencies. Good thing the feature is indefinitely blocked in rustc as that gives us more time.
### How should we test and review this PR?
### Additional information
In #13308, we decided to make the feature gate for public/private
dependencies non-blocking.
Generally, people opt-in to a feature that is non-blocking through `-Z`
but some nightly users want an "always on" mode for this, so we offered
both in #13340.
In #13340, we made both feature gates work but we did not make them
non-blocking for stable, only nightly.
This change makes the feature gate non-blocking on stable.
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
We were correctly doing this for cases like `cargo new foo` or
`cargo new deeper/than/this/directory/foo` but not `cargo new ../foo`.
This came up when discussing #14501
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.
According to the documentation the --crate-type flag accepts a comma
separated list of crate types. However, these are never actually
split into individual items and passed verbatim to rustc.
Since cargo fails to associate cases such as 'staticlib,cdylib' to
a specific crate type internally, it has to invoke rustc to determine
the output file types for this unknown crate type, which returns only
the first file type of the first crate type in the list. Consequently
cargo will be looking only for a single '.a' artifact on Linux to be
copied to the target directory.
Fix this by splitting the list of provided crate types into individual
items before further processing them.
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
