cargo-tree: Handle -e no-proc-macro when building the graph
### What does this PR try to resolve?
Makes `-e no-proc-macro` more useful when combined with `-i` or `-d`. Fixes#12030.
### How should we test and review this PR?
The new and existing tests should cover this, I hope!
### Additional information
Pruning proc-macro crates during graph construction is closer to how the edge-based filters work (`[no-]build` etc.), so even though `no-proc-macro` isn't technically filtering on edges, it's following a well-established code path.
crates.io reads rust-version from the tarball directly, but we can include it in
the publish request for the sake of consistency for third-party registries.
The headers can significantly contribute to noise in the output,
drowning out the rest of the output. Most investigation will likely be
focused on the case where cargo completely fails to download, so this
only shows the full detail in the final error message.
Use registry.default for login/logout
This changes `cargo login` and `cargo logout` to use the registry configured at `registry.default` as the registry instead of crates.io. For `cargo login`, this was an unintentional regression from #6466. The documentation has always stated that it will use the default registry.
This makes the command more in line with other registry-involving commands. There are still some inconsistencies.
These commands use the default if not specified:
* `cargo init`
* `cargo new`
* `cargo owner`
* `cargo search`
* `cargo yank`
* `cargo publish` uses the default, but will also look at the `publish` field `Cargo.toml` and use that if the registry is not specified.
These commands would always use crates.io if `--registry` is not specified:
* `cargo login`
* `cargo logout`
* `cargo install`
I'm a bit uncertain how to proceed, since this is technically a breaking change particularly if someone has scripted it. I suspect that the number of users that use `registry.default` is very small, and those that script `cargo login` are even smaller, and thus the intersection is probably small or nonexistent. However, there is some risk here.
Rustc supports these since rust-lang/rust#109808. It's technically
possible to set a named debuginfo level through `RUSTFLAGS`, but in
practice cargo always passes its own opinion of what the debuginfo level
is, so allow it to be configured through cargo too.
Fix credential token format validation.
The existing validation incorrectly excluded tab because of a missing backslash. This updates to add the backslash.
This also rewords the comments. I found the current comments to be a little confusing.
This also extends the test to verify more valid inputs.
cc #11600
When doing a credential lookup, Cargo deserializes the registry configuration and detects the
registries.crates-io.protocol key as unused and issues a warning.
This fixes the issue by adding the field to the struct
Add delays to network retries.
This adds a delay to network retries to help guard against short-lived transient errors.
The overview of how this works is: Requests that fail are placed into a queue with a timestamp of when they should be retried. The download code then checks for any requests that need to be retried, and re-injects them back into curl.
Care must be taken in the download loops to track which requests are currently in flight *plus* which requests are waiting to be retried.
This also adds jitter to the retry times so that multiple failed requests don't all flood the server when they are retried. This is a very primitive form of jitter which suffers from clumping, but I think it should be fine.
The max number of retries is raised to 3 in order to bring the total retry time to around 10 seconds. This is intended to address Cloudfront's default negative TTL of 10 seconds. The retry schedule looks like 0.5seconds ± 1 second, then 3.5 seconds then 6.5 seconds, for a total of 10.5 to 11.5 seconds. If the user configures additional retries, each attempt afterwards has a max delay of 10 seconds.
The retry times are currently not user-configurable. This could potentially be added in the future, but I don't think is particularly necessary for now.
There is an unfortunate amount of duplication between the crate download and HTTP index code. I think in the near future we should work on consolidating that code. That might be challenging, since their use patterns are different, but I think it is feasible.
Handle case mismatches when looking up env vars in the Config snapshot
### What does this PR try to resolve?
Fixes#11814.
Windows environment variables are case-insensitive, which causes problems when looking them up in the `Config` env snapshot.
This PR adds another member (`case_insensitive_env`) in `Config` that maps upper-cased keys to their original values in the env (for example, `"PATH" => "Path"`). If lookup in `self.env` fails, this PR converts the key to upper case and looks it up in `self.case_insensitive_env` to obtain the correct key name if it exists (on Windows only).
### How should we test and review this PR?
Please see the new tests in `testsuite/config.rs` and `testsuite/cargo_command.rs`.
### Additional information
Currently, this uses `str::to_uppercase` to uppercase the keys. This requires key to be valid UTF-8, and may disagree with how the OS uppercases things (see the link in [this comment](https://github.com/rust-lang/cargo/issues/11814#issuecomment-1462870983) for details).
align semantics of generated vcs ignore files
### What does this PR try to resolve?
The currently generated `^target/` spec in a hg ignore will only ignore dirs of that name at the root.
This change matches the behavior of the gitignore spec next to it, by only ignoring both files/symlinks and dirs of name "target".
### How should we test and review this PR?
Run `cargo new`
