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
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.
We now include the prelude in so many places, this simplifies how we can
present how `cargo-test-support` works.
Yes, this included some `use` clean ups but its already painful enough
walking through every test file, I didn't want to do it twice.
While this is noisy and hides other deprecations, I figured deprecations would
make it easier for people to discover what tasks remain and allow us to
divide and conquer this work rather than doing a heroic PR.
In theory, this will be short lived and we'll go back to seeing
deprecations in our tests.
This is to help with #9930
Example changes:
```diff
-[LOCKING] 4 packages
+[LOCKING] 4 packages to latest version
-[LOCKING] 2 packages
+[LOCKING] 2 packages to latest Rust 1.60.0 compatible versions
-[LOCKING] 2 packages
+[LOCKING] 2 packages to earliest versions
```
Benefits
- The package count is of "added" packages and this makes that more
logically clear
- This gives users transparency into what is happening, especially with
- what rust-version is use
- the transition to this feature in the new edition
- whether the planned config was applied or not (as I don't want it to
require an MSRV bump)
- Will make it easier in tests to show what changed
- Provides more motiviation to show this message in `cargo update` and
`cargo install` (that will be explored in a follow up PR)
This does come at the cost of more verbose output but hopefully not too
verbose. This is why I left off other factors, like avoid-dev-deps.
This has bothered me about `cargo new` and `cargo init` for a while that
the output is read backwards, for example:
```diff
--- i/tests/testsuite/cargo_init/path_contains_separator/stderr.log
+++ w/tests/testsuite/cargo_init/path_contains_separator/stderr.log
@@ -1,3 +1,3 @@
+ Creating binary (application) package
warning: the path `[ROOT]/case/test:ing/.` contains invalid PATH characters (usually `:`, `;`, or `"`)
It is recommended to use a different name to avoid problems.
- Created binary (application) package
```
Inspired by my having forgotten to add `[lints]` to the if sequence.
Previously, we added a comment to suggest this but the further the code
is, the harder it is to track.
I considered a custom `Deserialize` impl, possibly through a new type,
that would error.
This would be the more "pure" solution.
Unfortunately, this would also have worse errors because the errors
would be reported to the `Deserializer` at the document-level, rather
than directly on the individual fields.
Well, we don't do on individual fields now but it is something we will
soon be exploring.
This was missed with the initial `[lints]` implementation.
While this is a breaking change, this is aligned with ones we've done in
the past. A lot of times, we warn first. My hope is that isn't needed
this time because
- It only exists virtual workspaces so they aren't published
- It is a nop to have this which is likely to be caught
- This is so new that the number of people using it, and likely running
into this case, is quite low.
When a user runs `cargo new` or `cargo init` within a workspace, Cargo will automatically add the new package to the members list in the workspace if necessary. The heuristic to add the new package is as follows:
- If there is no `members` list in the workspace yet, a new `members` list is created.
- If there is an `exclude` statement, Cargo checks if the new package should be excluded. If it doesn't match the `exclude` list, the package is added to the `members` list.
- If there is a glob expression in the `members` list that matches the new package, the package is not added to the `members` list.
- If the existent `members` list is sorted, Cargo tries to preserve the ordering when it adds the new package.
This change doesn't try to format the resulting `members` list in any way, leaving the formatting decissions to the user.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Benefits:
- A TOML 1.0 compliant parser
- Unblock future work
- Have `cargo init` add the current crate to the workspace, rather
than error
- #5586: Upstream `cargo-add`
The `anyhow` crate interoperates with the `std::error::Error` trait
rather than a custom `Fail` trait, and this is the general trend of
error handling in Rust as well.
Note that this is mostly mechanical (sed) and intended to get the test
suite passing. As usual there's still more idiomatic cleanup that can
happen, but that's left to later commits.
`cargo vendor`: Don't delete hidden top-level files.
`cargo vendor` (without `--no-delete`) will delete all files in the `vendor/` directory when it starts. This changes it so that it will skip any entries starting with a dot. This allows one to track the vendor directory with a source control system like git.
Closes#7109
(Note: two commits, one is a test change.)
