Add `--public` for `cargo add`
## What does this PR try to resolve?
Complete https://github.com/rust-lang/cargo/issues/13037
This PR want to add `--public/--no public` flag for `cargo add`
Note: this assumes we'll remove workspace inheritance support for `public` as it sounds like we'll be reverting it https://github.com/rust-lang/rust/issues/44663#issuecomment-1826474620. If we decide to keep workspace inheritance, we'll need to come back and update this.
## How should we test and review this PR?
Most of Code were reference `cargo add --optional`, So can reviewed the new code based on the part of `optional` code.
The new testcases were origin from the `cargo add --optional` part.
- `public` testcase：there is no dependencies and will be add `public` dependencies.
- `no_public` testcase: there is no dependencies and will be add `no_public` dependencies.
- `overwrite_public` testcase: the dependencies already exists but will be overwrite with `public`.
- `overwrite_no_public` testcase: the dependencies already exists but will be overwrite with `no_public`.
- `overwrite_public_with_no_public` testcase: the dependencies already marked as `no_public` and will be overwrite with `public`.
- `overwrite_no_public_with_public` testcase: the dependencies already marked as `public` and will be overwrite with `no_public`.
Fixed uninstall a running binary failed on Windows
### What does this PR try to resolve?
Fixes https://github.com/rust-lang/cargo/issues/3364
The problem reproduce when you try to uninstall a running binary and it will failed on Windows, this is because that cargo had already remove the installed binary tracker information in disk, and next to remove the running binary but it is not allowed in Windows. And to the worst, you can not uninstall the binary already and only to reinstall it by the `--force` flag.
### How to solve the issue?
This PR try to make the uninstall a binary more reasonable that only after remove the binary sucessfully then remove the tracker information on binary and make the remove binary one by one.
### How should we test and review this PR?
Add testcase 0fd4fd357b
- install the `foo`
- run `foo` in another thread.
- try to uninstall running `foo` and only failed in Windows.
- wait the `foo` finish, uninstall `foo`
- install the `foo`
### Additional information
Don't filter on workspace members when scraping doc examples
Fixes https://github.com/rust-lang/cargo/issues/13074.
I confirmed locally that it fixed the issue in docs.rs.
cc `@willcrichton`
r? `@epage`
Fixes error count display is different when there's only one error left
### What does this PR try to resolve?
When there's only 1 error left, the number 1 appears in the output so that it scans the same as the output when there's more than 1 error, so:
```
error: could not compile `crate` (lib test) due to 1 previous error
```
instead of the current:
```
error: could not compile `crate` (lib test) due to a previous error
```
Fixes#12390
rustc related PR [#114759](https://github.com/rust-lang/rust/pull/114759)
fix: reorder `--remap-path-prefix` flags for `-Zbuild-std`
### What does this PR try to resolve?
Order of `--remap-path-prefix` flags is important for `-Zbuild-std`.
We want to show `/rustc/<hash>/library/std` instead of `std-0.0.0`.
Fixesrust-lang/rust#117839
### How should we test and review this PR?
Follow the steps in rust-lang/rust#117839, or run
```
CARGO_RUN_BUILD_STD_TESTS=true cargo +nightly t --test build-std
```
to verify.
Handle $message_type in JSON diagnostics
### What does this PR try to resolve?
Unblocks https://github.com/rust-lang/rust/pull/115691.
Without this change, Cargo's testsuite fails in `doc::doc_message_format` and `metabuild::metabuild_failed_build_json`.
### How should we test and review this PR?
Tested with and without https://github.com/rust-lang/rust/pull/115691.
In Cargo repo: `cargo test --test testsuite`
In Rust repo: `x.py test src/tools/cargo` (separately on master and $message_type PR)
This is an alternative to #12158's `CARGO_WORKSPACE_DIR` that was
implementing the solution to #3946 that previously discussed in the
cargo team meeting.
`CARGO_WORKSPACE_DIR` is a bit awkward to document / describe because
its the effective workspace directory of the thing being built.
If the thing being built doesn't have a workspace, it falls back to
`CARGO_MANIFEST_DIR`.
It would also be hard to take into account what the
`CARGO_WORKSPACE_DIR` would be for path dependencies into foreign
workspaces *and* it wouldn't solve the problem the user is having.
What the user really wants is the CWD of rustc when it is invoked.
This is much simpler to describe and is accurate when using a path
dependency to a foreign package.
Because the CWD is a much simpler mechanism to talk about, I figured we
could diverge from our prior consensus and make it always present,
rather than limiting it to tests.
Remaining work for #3946: get this stabilized
Exited with hard error when custom build file no existence or not in package
## What does this PR try to resolve?
Fixed https://github.com/rust-lang/cargo/issues/11383
## How should we test and review this PR?
Add test `build_script_outside_pkg_root`, this will check `custom_build.rs` existence and whether in the package root, if not then exited with a hard error
## Additional information
The code just handle the `custom build` target that i know how to test it. Other target type is skipped.
If the only path is a loop then counted as the shortest path.
This is a fix for #12941
This graph data structure is used to store dependency DAGs. Where each edge represents a dependency from a package to the package that fulfilled the dependency. Different parts of the resolver store this data in opposite directions, sometimes packages point at the things that depend on them other times packages point to the parents that required them. Error messages often need to report on why a package is in the graph, either by walking up toward parents or down toward children depending on how this graph is stored. #12678 unified the two different walking implementations, and replace them with a breadth first search so as to find the shortest path. This code ignored when edge pointed at a package that had already been reached, because that generally describes a longer path to an existing package.
Unfortunately, when I said this was a DAG that was a simplification. There can be cycles introduced as dev-dependencies. The existing code would reasonably ignore the cycles figuring that if we continue searching we would eventually find the root package (a package that nothing depended on). Missing the possibility that the root package created the cycle.
Now we search through the entire graph looking for a root package. If we do not find a root package we report the path to the last package we processed.
fix(resolver): Prefer MSRV, rather than ignore incompatible
### What does this PR try to resolve?
This is another experiment for #9930.
Comparing preferring over exclusively using MSRV compatible:
Benefits
- Better error messages
- `--ignore-rust-version` is implicitly sticky
Downsides
- Can't backtrack for MSRV compatible version
- Still requires workspace-wide MSRV (compared to our desired end state of declaring MSRV as yet another dependency)
### How should we test and review this PR?
### Additional information
Note: `--ignore-rust-version` is not yet implemented for the resolver.
This builds on #12930
This is another experiment for #9930.
Comparing preferring over exclusively using MSRV compatible:
Benefits
- Better error messages
- `--ignore-rust-version` is implicitly sticky
Downsides
- Can't backtrack for MSRV compatible version
- Still requires workspace-wide MSRV (compared to our desired end state of declaring MSRV as yet another dependency)
This builds on #12930
