fix(cli): Provide next steps for bad -Z flag
In #5546, they suggested we have a list of them but that would be hard to keep up and works well enough to just always mention it.
Fixes#5546
fix(remove): Preserve feature comments
### What does this PR try to resolve?
We've been having a hard time balancing leaving the feature list in a good looking start and preserving formatting. With our new formatting policy (#12836), we can just choose to preserve formatting instead.
Fixes#11743
### How should we test and review this PR?
The first commit copies an existing test. The second is where the fun begins, customizing the test for some weird cases. The follow up commits do the slow walk for improving it.
We ended up preserving some line-trailing comments because they come after the comma and toml_edit treats that as part of the prefix of the next item. Tracking removal of that was going to require us to determine if the newline existed in the suffix or in the next item's prefix and edit accordingly and I decided to skip that to keep this initial implementation simpler.
### Additional information
fix(help):Clarify install's positional
### What does this PR try to resolve?
- That a version is accepted
- That you are selecting from the source a package which led to part of
the confusion in #4830
I wonder if we should rename our `CRATE` value names to `PKG`/`PACKAGE`
While doing this, I decided to fix the inconsistency in how we handle value names in help.
### How should we test and review this PR?
### Additional information
Adjust `-Zcheck-cfg` for new rustc syntax and behavior
https://github.com/rust-lang/rust/pull/111072 introduced a new syntax for `rustc` `--check-cfg` argument. This PR adjust cargo `-Zcheck-cfg` for new that new syntax and behavior.
This PR removes all the `-Zcheck-cfg` options (`features`, `names`, `values`, `output`), as they don't make much sense now since with the new `rustc` behavior: `features`, `names` and `values` are all combine together and the `output` option was only here because the other were.
Now the new behavior from cargo is to always pass one `--check-cfg` argument to rustc for the `feature`s which implicitly enables well known names and values.
fix(replace): Partial-version spec support
### What does this PR try to resolve?
#12614 changed package ID specs to allow fields in the version number to be optional. This earliest branch with this change is `rust-1.74.0` (beta). While `@Eh2406` was investigating version metadata issues in #12772, problems with the partial version change were found
- `replace`s that specify version metadata were ignored **(fixed with this PR)**
- This also extends out to any other place a PackageIDSpec may show up, like `cargo check -p <name>`@<spec>``
- We explicitly kept the same semantics of version requirements that pre-releases require opt-in. If nothing else, this gives us more room to change semantics in the future if we ever fix the semantics for pre-release.
- `replace`s that don't specify version metadata when the `Cargo.lock` contained a version metadata, it would previously be ignored (with a warning) but now match **(unchanged with this PR)**
- When the version metadata in `Cargo.lock` differed from the overriding `Cargo.toml`, cargo would panic **(now an error in this PR)**
With this PR, we are acknowledging that we changed behavior in taking ignored replaces (because of differences with version metadata) and applying them. Seeing as version metadata is relatively rare, replaces are relatively rare, and differences in it for registries is unsupported, the impact seems very small.
The questions before us are
- Do we revert #12614 in `master` and `rust-1.74.0` or merge this PR into `master`
- If we merge this PR into `master`, do we cherry-pick this into `rust-1.74.0` or revert #12614, giving ourselves more time to find problems
### How should we test and review this PR?
The initial commit adds tests that pass as of #12614. Prior to #12614, these tests would have warned that the `replace` was unused and failed because `bar::bar` didn't exist. Each commit then changes the behavior (or not) and updates the corresponding test.
### Additional information
This commit removes all the -Zcheck-cfg options (features, names,
values, output), as they don't make much sense now since features, names
and values are all combine together for upstream rustc and the output
option was only here because the other were.
Now the new behavior from cargo is to always pass one `--check-cfg`
argument to rustc for the `feature`s which implicitly enables well known
names and values.
Print environment variables for build script executions with `-vv`
### What does this PR try to resolve?
When debugging complicated builds (I was trying to figure out how `cargo-miri` cross-compiles compiler_builtins without needing a C cross compiler), it's useful to see all the environment variables passed to the build script.
This is also consistent with other commands.
### How should we test and review this PR?
I tested it locally by creating a small crate with an empty `build.rs` and building it. Additionally, a test is included.
fix(cli): Suggest cargo-search on bad commands
This is a low-tech solution alternative to the options proposed in #4682
- Search `[[bin]]`s within all packages in the registry (which aren't tracked atm), suggesting to `cargo install` what is found
- Check if `cargo-<cmd>` is in the registry, suggesting `cargo install if it is
By suggesting `cargo search`, we are giving them a tool so they can verify if the package is what they want (a `cargo info` would help as a next step).
Is is needed?
- New users might not know of `cargo search` but they can search on crates.io
- New users might not be aware of the `cargo-<cmd>` naming pattern
Seems like this can still offer some benefit.
Fixes#4682
- That a version is accepted
- That you are selecting from the source a package which led to part of
the confusion in #4830
I wonder if we should rename our `CRATE` value names to `PKG`/`PACKAGE`
This is a low-tech solution alternative to the options proposed in #4682
- Search `[[bin]]`s within all packages in the registry (which aren't
tracked atm), suggesting to `cargo install` what is found
- Check if `cargo-<cmd>` is in the registry, suggesting `cargo install
if it is
By suggesting `cargo search`, we are giving them a tool so they can
verify if the package is what they want (a `cargo info` would help as a
next step).
Is is needed?
- New users might not know of `cargo search` but they can search on
crates.io
- New users might not be aware of the `cargo-<cmd>` naming pattern
Seems like this can still offer some benefit
Fixes#4682
This commit updates the processing of `workspace = true` dependencies in
the `[dependencies]` section to process the `public` field. Previously
this field was ignored and didn't get plumbed through as configured.
feat: add package name and version to warning messages
### What does this PR try to resolve?
Hi, this PR Fixes#8018, where i add the package name and version on warning messages.
As this is my first contribution to the project, if anything is not in compliance in the PR let me know and I will be happy to correct it.
Do not call it "Downgrading" when difference is only build metadata
### What does this PR try to resolve?
When a `cargo update --precise` changes a dependency between 2 versions which differ only in build metadata, Cargo prints a log referring to it as "Updating" or "Downgrading" the dependency, depending on a comparison between the build metadatas.
This is usually not meaningful, given that build metadata is often stuff like git commit hashes, which are not meaningfully ordered.
```console
Updating crates.io index
Downgrading foo v0.0.1+43ef4fe -> v0.0.1+2c65d16
Updating bar v0.0.2+bc17664 -> v0.0.2+c144a98
```
~~This PR changes to the word "Switching" when the version major, minor, patch, and pre-release value are not being changed.~~
This PR uses the word "Updating" when the version major, minor, patch, and pre-release value are unchanged, regardless of whether the build metadata is going up or down.
### How should we test and review this PR?
- `cargo test`
- `cargo build --release`
- `/path/to/cargo/target/release/cargo add tonic_datastore_v1`
- `/path/to/cargo/target/release/cargo update -p tonic_datastore_v1 --precise 0.1.0+3562b6cb3`
- `/path/to/cargo/target/release/cargo update -p tonic_datastore_v1 --precise 0.1.0+ee9e8e4e6`
Before:
<img src="https://github.com/rust-lang/cargo/assets/1940490/93e377e7-928e-4cec-aff6-451166ef7c81" width="500">
~~After:~~
<img src="https://github.com/rust-lang/cargo/assets/1940490/bb71459e-469a-4e09-bb8a-4083f34bce79" width="500">
After:
<img src="https://github.com/rust-lang/cargo/assets/1940490/8804e2fe-d0de-4c9e-b463-a5742daf9446" width="500">
fix(install): Suggest an alternative version on MSRV failure
### What does this PR try to resolve?
Moves users from a bad error message, suggesting `--locked` which won't do anything, to suggesting a version of a package to use instead.
The side benefit is errors get reported sooner
- Before downloading the `.crate`
- When installing multiple packages, before building the first
This comes at the cost of an extra `rustc` invocation.
### How should we test and review this PR?
Per-commit this builds it up, from tests to the final design.
### Additional information
This is also written in a way to align fairly well with how we'd likely implement #10903.
This improved error message will still be useful after that issue is resolved when the MSRV compatible version is outside of the version req.
The next step would be to also automatically install an MSRV compatible
version if compatible with the version req (#10903).
This improved error message will still be useful if the MSRV compatible
version is outside of the version req.
I did this as the first step
- Helps people now, not needing to wait on `-Zmsrv-policy` to be stabilized
- Has fewer questions on how it should be done (or if it should be)
This will also report the error without having to download the `.crate`
first.
If installing multiple packages, this will also report it immediately,
rather than waiting for the other packages to be installed first.
This also offers us more flexibility in the error we report,
like suggesting more appropriate fixes.
