Whether a period was used was dependent on whether a `help:` block is
present.
That shouldn't make a difference and the rustc dev guide says not to use
periods unless multiple sentences are used.
This is a follow up to #14846 which changed `run` to return the
`RawOutput`.
Reasons I didn't "update" some code to the new `run` return value
- We were actually using `ProcessBuilder::exec_with_output` and I didn't
want to disentangle what it would take to switch to `Execs`
- We did processing on the `Result` and I didn't want to check how that
could be updated
`Registry::describe_source` will be used as default error message, but if the message
come from `Registry::describe_source` is empty, then it uses `SourceId` message
fix: correct error count for `cargo check --message-format json`
Hi! This is my first time contributing to Cargo. If there is anything that I need to do, please let me know!
(I'm not sure whether the commit message is aligned with the Cargo's convention. If it doesn't, I'm willing to modify it!)
This PR resolves the issue with incorrect error count and ensures warnings are correctly displayed when using `cargo check --message-format json`.
Fixes#14472
feat: add CARGO_MANIFEST_PATH env variable
Adds `CARGO_MANIFEST_PATH` variable as part of https://github.com/rust-lang/cargo/issues/12207
Context: `CARGO_MANIFEST_DIR` is not very useful, because there is no `Cargo.toml` file when running a cargo script. In cases when multiple scripts are stored in the same folder, we can't tell which script exactly is being run using `CARGO_MANIFEST_DIR`
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.
test: Fix some test based on rustc version
### What does this PR try to resolve?
Some test ouput specifies the latest rustc version and will failed when the rustc version get updated
### How should we test and review this PR?
### Additional information
fix(test): Move path2url to CargoPathExt::to_url
### What does this PR try to resolve?
This is a small step, like #14243, to improve the clarity of `cargo-test-support`s API.
Overall, I'm trying to make it more obvious on https://docs.rs/cargo-test-support/latest/cargo_test_support/ which items to reach for when. I figured this is one that could be demoted to `paths` When doing so, I noticed `CargoPathExt`. I figured if we had any extension traits for `Path`, then this is a
reasonable one to add.
### How should we test and review this PR?
### Additional information
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.
feat(resolve): Tell the user the style of resovle done
### What does this PR try to resolve?
This is to help with https://github.com/rust-lang/cargo/issues/9930
Example changes:
```diff
-[LOCKING] 4 packages
+[LOCKING] 4 packages to latest compatible version
-[LOCKING] 2 packages
+[LOCKING] 2 packages to latest Rust 1.60.0 compatible versions
-[LOCKING] 2 packages
+[LOCKING] 2 packages to earliest compatible 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.
### How should we test and review this PR?
### Additional information
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.
feat: Add 'open-namespaces' feature
### What does this PR try to resolve?
This is a step towards #13576
### How should we test and review this PR?
### Additional information
