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.
Before the default was hardcoded to `true`. The problem was that means
that to remove the `package.version` boilerplate, you had to add
`package.publish = false` boilerplate.
To make the errors easier to understand in this situation, I err on the
side of encouraging people to put `publish = true` in their manifests.
By making this change, we also unblock "cargo script" /
`Cargo.toml` unifying the handling of `package.publish`.
This defaults the version to `0.0.0` for most of cargo.
It is an error to lack a version and have a package publishable.
That means you have to add `publish = false`.
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.
This introduces a new `CacheLocker` which manages locks on the package
cache. Instead of either being "locked" or "not locked", the new locker
supports multiple modes:
- Shared lock: Cargo can read from the package sources, along with any
other cargos reading at the same time.
- Download exclusive lock: Only one cargo can perform downloads.
Download locks do not interfere with Shared locks, since it is
expected that downloading does not modify existing files (only adds
new ones).
- Mutate exclusive lock: Only one cargo can have this lock, and it also
prevents shared locks. This is so that the cargo can modify the
package cache (such as deleting files) without breaking concurrent
processes.
fix bug: corruption when cargo killed while writing
### What does this PR try to resolve?
fix #11386, superseding #12362
### How should we test and review this PR?
Added unit test showing basic equivalency to existing `write(path, content)`. Full test suite should exercise write.
Added tests for cargo add and remove. These are timing tests, so take a bit of time to run. 5-10s each. They may not fail every time, but do so regularly. Making the change to these two writes seems to prevent me from failing these tests at all.
### Additional information
This uses tempfile::persist which was an existing dependency. atomicwrites crate, an alternative option for this fix, indicates `tempfile::persist` is the same thing. Since we already use tempfile as a dep, I stuck with that.
Disable custom_target::custom_bin_target on windows-gnu
The `custom_target::custom_bin_target` test has been crashing frequently in CI on the x86_64-pc-windows-gnu target since the last LLVM 17 update. This disables the test to reduce the disruption in CI. The issue is being tracked in https://github.com/rust-lang/rust/issues/115985.
feat(embedded): Hack in code fence support
### What does this PR try to resolve?
This is to allow us to get feedback on the design proposed
[on zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Embedding.20cargo.20manifests.20in.20rust.20source/near/391427092)
to verify we want to make an RFC for this syntax.
````rust
#!/usr/bin/env cargo
```cargo
[dependencies]
clap = { version = "4.2", features = ["derive"] }
```
use clap::Parser;
#[derive(Parser, Debug)]
#[clap(version)]
struct Args {
#[clap(short, long, help = "Path to config")]
config: Option<std::path::PathBuf>,
}
fn main() {
let args = Args::parse();
println!("{:?}", args);
}
````
### How should we test and review this PR?
The tests were updated in a separate commit to ensure there was no regression while then migrating to the new syntax to make sure it worked.
This involves some future work
- Removing doc comment support
- Getting the syntax approved and implemented
- Migrating to rustc support for the syntax
#12207 was updated to record these items so we don't lose track of them
more specific registry index not found msg
### What does this PR try to resolve?
covers #12576
### How should we test and review this PR?
test covers exact text, so a review and passing tests.
The previous status line was a little awkward in the way it combined
both counts. I don't think showing the directories is particularly
interesting, so they are only displayed when no files are deleted.
feat(cli): Add '-n' to dry-run
This came from #12638 and my many small frustrations from wanting to use `-n` and not being able to.
We do not have any existing `-n` flags for this to be confused with.
I would wager that `-n` is such an entrenched short flag in build tools that it would not make sense for us to use it with any other flag.
For a survey of where `-n` is used as a short, see https://www.gnu.org/prep/standards/html_node/Option-Table.html#Option-Table
feat: stabilize credential-process and registry-auth
Stabilization PR for `registry-auth` and `credential-process`.
Tracking approval of this stabilization is done in the via the FCP in [#8933](https://github.com/rust-lang/cargo/issues/8933#issuecomment-1711990123). This PR is here to help reviewers of the FCP.
* Stabilizes `registry-auth` and `credential-process`
* Makes authenticated registries require a credential provider
* Adds stable documentation for credential providers and authenticated registries
Closes#8933Closes#10474
This came from #12638 and my many small frustrations from wanting to use
`-n` and not being able to.
We do not have any existing `-n` flags for this to be confused with.
I would wager that `-n` is such an entrenched short flag in build tools that it would
not make sense for us to use it with any other flag.
For a survey of where `-n` is used as a short, see
https://www.gnu.org/prep/standards/html_node/Option-Table.html#Option-Table
feat(help): Add styling to help output
### What does this PR try to resolve?
Try to make `--help` output easier to parse by using terminal styling
Screenshots:
*(`nargo` is my shell script wrapping `cargo run --manifest-path cargo/Cargo.toml`)*
### How should we test and review this PR?
At this time, the only styling snapshotting library I know of is a pain to use, so testing this requires manually running the commands which I did. Screenshots are included for easier evaluation of the general idea.
Snapshotting of the plain text output ensures we don't have accidental formatting regressions from this change since the formatting isn't as obvious from looking at the code.
### Additional information
Traditionally, cargo has disabled clap's styled output. My assumed
reason is that cargo mixes custom help output with auto-generated and
you couldn't previously make it all styled.
Clap 4.2 allowed users to pass in strings styled using ANSI escape
codes, allowing us to pass in styled text that matches clap, unblocking this. In clap
4.4.1, clap gained the ability for the user to override the style.
In this PR, I decided to use the new 4.4.1 feature to style clap's
output to match the rest of cargo's output. Alternatively, we could use
a more subdue style that clap uses by default.
I used the `color-print` crate to allow something almost html-like for styling `&static str`. Alternatively, we could directly embed the ANSI escape codes harder to get write, harder to inspect), or we could do the styling at runtime and enable the `string` feature in clap.
I decided to *not* style `Arg::help` messages because
- It might be distracting to have the descriptions lit up like a
christmas tree
- It is a lot more work
The one exception I made was for `--list` since it is for a
psuedo-command (`...`) and I wanted to intentionally draw attention to
it.
#12593 made styling of `cargo -h` cleaner imo.
#12592 and #12594 were improvements I noticed while doing this.
