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
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.
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
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
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).
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): 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
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.
`-Ztarget-applies-to-host --config target-applies-to-host=false` make it
possible to build two units for the same output directory with different
rustflags (one with artifact/target rustflags, one with none/host rust
flags). Those flags aren't included in the `-Cmetadata` hash which is
used to disambiguate different versions of crates, resulting in a conflict.
The actual error being produced appears to be the result of two invocations
of `rustc` racing and clobbering each other.
While we don't hash RUSTFLAGS because it may contain absolute paths that
hurts reproducibility, we track whether a unit's RUSTFLAGS is from host
config, so that we can generate a different metadata hash for runtime
and compile-time units.
This builds on the prior work to consolidate everything, simplifying the
code and making it clearer what behavior differences exist between
change kinds.
fix: doctest respects Cargo's color options
### What does this PR try to resolve?
Explain the motivation behind this change.
This commit fixes the issue where cargo's test command doesn't respect the color parameter when it gets passed in like this command: `cargo t --color never --doc -- --color never`
Fixes#14403
### How should we test and review this PR?
Test on a basic rust project, with a file called lib.rs that looks like this
```
/// ```
/// bar
/// ```
pub fn foo() {}
#[cfg(test)]
mod tests {
#[test]
fn foo() {
bar
}
}
```
You can try to replicate the same commands `@zacknewman` used in the description of this issue.
`cargo t --color never --doc -- --color never`
You will see that compared to the official build of cargo, this build will respect the --color argument
Be more permissive while packaging unpublishable crates.
This PR allows for packaging workspaces that include `publish = false` crates, in some circumstances:
- unpublishable crates are ignored when inferring the publish registry
- when checking whether the publish registry is valid, we ignore unpublishable crates
- we don't put unpublishable crates in the local registry overlay, so if any workspace crates depend on an unpublishable crate then they will fail to verify.
This PR also contains a refactor, moving the registry inference logic to `registry/mod.rs`, where it will be reused by the upcoming publish-workspace feature. I put the refactor and the logic changes in different commits.
Fixes#14356
This changes the registry validation slightly, adding in a check
forbidding implicit source replacement. This affects the tests (which
configure a dummy registry for source replacement), so we also weaken
the checks by only erroring for registry issues when there are actually
local dependencies.
feat(update): Report when incompatible-rust-version packages are selected
### What does this PR try to resolve?
In discussin this in #13873, it highlighted that we need to make sure we
tell people when incompatible-rust-version packages are selected.
I decided to keep "latest" and "required rust version" messages mutually
exclusive to avoid too much noise. I gave "required rust version"
higher precedence as its the more critical to operation and, if you are
using an MSRV-incompatible package, it likely is "latest" already.
### How should we test and review this PR?
### Additional information
I was tempted to change colors to make "required rust version" stand out
from "latest" but was unsure what direction to go, so I held off.
Options included
- red for "required rust version", yellow for "latest"
- yellow for "required rust version", nothing for "latest"
There is also more discussion on how to format "latest" at #13908.
In discussin this in #13873, it highlighted that we need to make sure we
tell people when we get in this state.
I decided to keep "latest" and "required rust version" messages mutually
exclusive to avoid too much noise. I gave "required rust version"
higher precedence as its the more critical to operation and, if you are
using an MSRV-incompatible package, it likely is "latest" already.
I was tempted to change colors to make "required rust version" stand out
from "latest" but was unsure what direction to go, so I held off.
Options included
- red for "required rust version", yellow for "latest"
- yellow for "required rust version", nothing for "latest"
There is also more discussion on how to format "latest" at #13908.
Add `--lockfile-path` flag
This change implements a new `--lockfile-path` proposed in #5707 .
Functionality added:
- Add `--lockfile-path <PATH>` to all commands that support `manifest-path` with exception of:
- `locate-project` (doesn't use lock file)
- `verify-project` (is deprecated)
- `read-manifest` (doesn't use lock file)
- Behind -Zunstable-options and docs
- The flag's docs / `--help` has (unstable) in them
- `<PATH>` must end with `Cargo.lock`. If specified path doesn't exist (or parent director(ies), create all the parent directories and the lockfile itself
Implementation TLDR: add `requested_lockfile_path` into `Workspace` and set it on `workspace(gctx)` call (setting from the context)
Update `lockfile.lock_root()` to respect `requested_lockfile_path` (if set)
Add test cases covering all affected commands. Tested creating lockfile, reading lockfile, overriding default (`./Cargo.lock`) lockfile, symlink tests. Extra tests for package to make sure pinned versions from path's lockfile are respected (i.e. double check correct lockfile is used)
I doubt this flag will be used for any command that's not read-only, but I tried to cover all the commands.
