Add error message when `cargo fix` on an empty repo
### What does this PR try to resolve?
close https://github.com/rust-lang/cargo/issues/11380
Add error message when `cargo fix` on an empty repo.
### How should we test and review this PR?
- [x] unit test
```sh
set -eux
cargo +nightly new repro
cd repro
echo "fn main() { let _ = 0.clone(); }" > src/main.rs
cargo fix
```
Store the sparse+ prefix in the SourceId for sparse registries
#11209 added a new `SourceKind::SparseRegistry` and removed the `sparse+` prefix from the URLs stored in the `SourceId`.
The removal of the `sparse+` prefix from the URLs in the `SourceId` has led to several bugs, since registry URLs no longer round-trip through a `SourceId`. The most recent one I found was that the example configuration generated by `cargo vendor` did not include the `sparse+` prefix. Any place that calls the `.url()` method on a `SourceId` potentially has this bug.
This change puts the `sparse+` prefix back in the URL stored in the `SourceId`, but keeps the new `SourceKind::SparseRegistry`.
A test is added for doing `cargo vendor` on an alternative registry using the sparse protocol.
add newline char to `cargo install .` error message for easier reading.
I just noticed the `cargo install .` error message was not formatted very nicely.
Just added a newline char to make it cleaner.
Thanks
Change rustdoc-scrape-examples to be a target-level configuration
This PR addresses issues raised in rust-lang/cargo#9525. Specifically:
1. It enables examples to be scraped from `#[test]` functions, by passing additional flags to Rustdoc to ensure that these functions aren't ignored by rustc.
2. It moves the `arg` from `-Z rustdoc-scrape-examples={arg}` into a target-level configuration that can be added to Cargo.toml.
The added test `scrape_examples_configure_target` shows a concrete example. In short, examples will be default scraped from Example and Lib targets. Then the user can enable or disable scraping like so:
```toml
[lib]
doc-scrape-examples = false
[[test]]
name = "my_test"
doc-scrape-examples = true
```
Add warning when `cargo tree -i <spec>` can not find packages
### What does this PR try to resolve?
close https://github.com/rust-lang/cargo/issues/11315
Add warning when `cargo tree -i <spec>` can not find packages.
### How should we test and review this PR?
Please run the unit test.
Clean profile, patch, and replace in cargo remove
### What does this PR try to resolve?
This PR is part of the continued work on cargo remove (#11099, see deferred work).
After a successful removal of a dependency, clean up the profile, patch, and replace sections to remove all references to it.
**Note** the GC process was expanded to clean up not just references to the dependencies just removed, but also references of all dependencies. This was because there's not an easy way to determine which dependencies correspond to the given TOML keys, without either 1) figuring that out before the removal (therefore having to predict the behavior), or 2) returning that information from the remove function (somewhat unorthodox for an op).
### How should we review and test this PR?
Verify that the implementation makes sense and that the tests are sufficient.
fix: return non UTF-8 error message
Fixes https://github.com/rust-lang/cargo/issues/11311
### Test Steps
1. Create a new empty Git repository
2. Create a `.gitignore` that is not valid UTF-8, for instance `printf '\xFF\xFE' > .gitignore`
3. `cargo init`
test(publish): Cover more wait-for-publish cases
These came from trying to guess what cases are causing problems in #11314. Unfortunately, can't reproduce it so far but figured it'd be good to keep these around.
Make cargo forward pre-existing CARGO if set
Currently, Cargo will always set `$CARGO` to point to what it detects its own path to be (using `std::env::current_exe`). Unfortunately, this runs into trouble when Cargo is used as a library, or when `current_exe` is not actually the binary itself (e.g., when invoked through Valgrind or `ld.so`), since `$CARGO` will not point at something that can be used as `cargo`. This, in turn, means that users can't currently rely on `$CARGO` to do the right thing, and will sometimes have to invoke `cargo` directly from `$PATH` instead, which may not reflect the `cargo` that's currently in use.
This patch makes Cargo re-use the existing value of `$CARGO` if it's already set in the environment. For Cargo subcommands, this will mean that the initial invocation of `cargo` in `cargo foo` will set `$CARGO`, and then Cargo-as-a-library inside of `cargo-foo` will inherit that (correct) value instead of overwriting it with the incorrect value `cargo-foo`. For other execution environments that do not have `cargo` in their call stack, it gives them the opportunity to set a working value for `$CARGO`.
One note about the implementation of this is that the test suite now needs to override `$CARGO` explicitly so that the _user's_ `$CARGO` does not interfere with the contents of the tests. It _could_ remove `$CARGO` instead, but overriding it seemed less error-prone.
Fixes#10119.
Fixes#10113.
Only remove fingerprints and build script artifacts of the requested package
Fixes#10069
This is my first PR to cargo. Let me know if you want me to add tests, or if there are any other changes you would like to see :)
This PR changes the globs used to remove fingerprints and build artifacts when running `cargo clean -p <pkid>`. The glob used was `<package_name>-*` which would match artifacts for packages that are prefixed by `<package_name>-` (e.g. `cargo clean -p sqlx` would also remove artifacts for `sqlx-{core,macros,etc.}`). This problem is not seen with other artifacts since those use the crate name instead of package name which normalize hyphens to underscores.
The changes follow the naive approach mentioned in #10069 where some basic string manipulation is done to strip off the last hyphen, hash, and potential extension to get the original package name which can be used to determine if the artifact is actually for the desired package. This means that this **does not** handle trying to resolve the package to determine the artifacts, so it still ignores the url and version that may be passed in the pkgid
Clean stale git temp files
### What does this PR try to resolve?
When cargo is interrupted while libgit2 is indexing the pack file, it will leave behind a temp file that never gets deleted. These files can be very large. This checks for these stale temp files and deletes them.
### How should we test and review this PR?
There is a simulated test here. To test with the actual behavior:
1. Run `CARGO_HOME=chome cargo fetch`
2. While it is "resolving deltas", hit Ctrl-C.
3. Notice that there is a 200MB file in `chome/registry/index/github.com-1ecc6299db9ec823/.git/objects/pack/`
4. Do that several times if you want, each time adds another 200MB file.
5. Build this PR: `cargo b -r`
6. Run `CARGO_HOME=chome CARGO_LOG=cargo::sources::utils=debug ./target/release/cargo fetch`
7. Notice that it deletes the `pack_git2_*` files.
