We are about to change the default value for target-names of libraries.
They used to match the package-name. In the future, they will use the
package-name with dashes converted to underscores. This will affect the
artifact env-variables, since they expose target-names. Hence, set the
old env-vars, too, to avoid breakage.
Note that we do not retain the name of a target before it was converted,
and the conversion is lossy, so we cannot reconstruct it. However, we
can rely on the fact that the conversion only happens for default values
(since user-supplied values never allowed dashes). Furthermore, we now
remember whether a target-name was inferred, so we can exactly
reconstruct whether a library-target could have contained dashes in
older releases, or not.
Add a boolean state to `Target` that tells us whether the name of the
target was inferred by Cargo, or whether it was directly specified in
the Manifest.
This value will be required in the future, to allow changing the
inferred names of targets, but retaining enough information to keep
backwards compatibility.
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)
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.
