Clarify flag behavior in `cargo remove --help`
### What does this PR try to resolve?
I noticed what I believe are typos in `cargo rm --help`:
```
Section:
--dev Remove as development dependency
--build Remove as build dependency
--target <TARGET> Remove as dependency from the given target platform
```
This change updates that section with a more appropriate description of those flags.
### How should we test and review this PR?
I've updated the relevant test for that help output.
### Additional information
Sorry for not opening an issue about this. I believe it's easy enough to approve it if my assumption is correct.
update SPDX License info
### What does this PR try to resolve?
fixes#12797
* link to latest license info
* update link for further info to main spdx page
Link to further info was pointing to a 2018 news update, now points to the main spdx page.
* link to latest license info
* update link for further info to main spdx page
* Update src/doc/src/reference/manifest.md
* point directly at expression syntax
Co-authored-by: Weihang Lo <weihanglo@users.noreply.github.com>
update license list
add detailed message when target folder path is invalid
# What does this PR try to resolve?
close https://github.com/rust-lang/cargo/issues/12789
add more detailed message when target folder path is invalid
# How should we test and review this PR?
Before this PR, if the target folder refer to broken symbolic link like /a/b/c, then run cargo build, the output is:
```
error: Not a directory (os error 20)
```
the detailed error message is missing.
This PR will add the error context for it, the finall output will be
```
cargo build
error: failed to create directory `/root/workspace/playground/target`
Caused by:
Not a directory (os error 20)
```
Support `public` dependency configuration with workspace deps
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.
Also 👋 it's been awhile!
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.
contrib docs: add some conveniences
- AND search terms, instead of OR
- allow quick-edit, by adding a button that allows one to submit a change directly via github
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">
chore: Sort dependency tables
This will make `cargo add` put things in the right place.
Verified by doing `cargo add arcstr && git diff && git reset --hard`
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.
rustdoc: remove the word "Version" from test cases
Needed for https://github.com/rust-lang/rust/pull/115948 to merge.
That PR gets rid of the word "Version" in rustdoc's HTML output, and it splits spaced versions on their first space, to fit in the tight horizontal spacing. This causes Cargo's test suite to fail, because it look for the word "Version", even though things are working as they should.
These tests work on both current nightly and on that pull request.
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)
