Fix elided lifetime in associated const
Fix an unelided lifetime in an associated const.
The old code was equivalent to:
```rust
impl<'a> RegistryConfig {
/// File name of [`RegistryConfig`].
const NAME: &'a str = "config.json";
}
```
and not `&'static str`, as it might be in a regular `const` item.
This "regressed" in rust-lang/rust#97313, which started allowing this behavior (inadvertently, as far as I can tell). It's not necessarily clear to me that this is sound (or at least, it's not something we intended to be able to express), but it's also preventing me from doing crater runs to investigate fallout of this issue (rust-lang/rust#114713 and rust-lang/rust#114716).
prompt the use of `--nocapture` flag if `cargo test` process is terminated via a signal.
Fixes#10855
As per the discussion on this issue, we want to prompt the user to use `--nocapture` if a test is terminated abnormally. The motivation for this change is described in the issue.
We check for 3 things before we display this flag. -
- `!is_simple` (if the test ended with a non 101 status code)
- `harness` (if the standard test harness was used), and
- `!nocapture` (whether or not the `--nocapture` flag was already passed to the test)
There's further tests added to `test::nonzero_exit_status` that check that the `stderr` is correct for the various combinations possible when a test ends with a non-101 status code.
The new expected behavior is -
- Display `--nocapture` note for only non-zero exit statuses, when the `--nocapture` flag is not passed.
- Only display the note if we use a standard test harness since custom test harnesses do not implement the `--nocapture` flag.
To implement the check for the `--nocapture` flag, the function definition for `report_test_errors` was changed to add the `test_args: &[&str]` parameter. This parameter is passed from the immediate calling function. This private function is only called twice change and is not causing regression after making the appropriate changes to both the places it's called in.
cargo-credential: reset stdin & stdout to the Console
Credential providers run with stdin and stdout piped to Cargo to communicate. This makes it more difficult for providers to do anything interactive. The current workaround is for a provider to use the `cargo_credential::tty()` function when reading from the console by re-opening stdin using `/dev/tty` or `CONIN$`.
This PR makes the credential provider to re-attach itself to the current console so that reading from stdin and writing to stdout "just works" when inside the `perform` method of the provider. stderr is unaffected since it's not redirected by Cargo.
Only the `cargo-credential` crate is changed. No changes are needed to Cargo.
cc #8933
Fix cargo remove incorrectly removing used patches
### What does this PR try to resolve?
Fixes an issue where patches are being removed when member dependencies don't explicitly contain the patched crate.
Fixes#12419
### How should we test and review this PR?
- Created a test for the failing use case
- Verify passing test
<!--
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
chore(gh): Expand update window
I've been having some repos not updated lately. RenovateBot project's theory is that its because RenovateBot is scheduled to run once every 3 hours and checks the schedule at that point while the schedules I use only offers an exact 3 hour window, making this a race condition. The schedule originally came from RenovateBot but they changed their polling schedule.
See https://github.com/renovatebot/renovate/discussions/23642#discussioncomment-6618560
Fix panic when enabling http.debug for certain strings
Fixes an issue where enabling HTTP debugging may attempt to slice a string across a character boundary resulting in a panic. This likely occurs when binary HTTP data happens to be valid UTF-8.
By interpreting the strings as `&[u8]` before slicing, (which is what `eq_ignore_ascii_case` did internally anyway), the panic is no longer possible.
Closes#12459
r? `@weihanglo`
fix(cli): Make `--help` easier to browse
This mirrors some of the categories from `cargo help` (the man pages) using [`clap::Arg::help_heading`](https://docs.rs/clap/latest/clap/struct.Arg.html#method.help_heading).
There are fewer categories to avoid extra vertical space. Instead, they
are left int the `Options` category but put first.
The goal is to try to make it easier to scan `--help` output as the list of flags can get quite long and its easy to miss what features are there.
I've been having some repos not updated lately. RenovateBot project's theory is
that its because RenovateBot is scheduled to run once every 3 hours and
checks the schedule at that point while the schedules I use only offers
an exact 3 hour window, making this a race condition. The schedule
originally came from RenovateBot but they changed their polling
schedule.
See https://github.com/renovatebot/renovate/discussions/23642#discussioncomment-6618560
This mirrors some of the categories from `cargo help` (the man pages).
There are fewer categories to avoid extra vertical space. Instead, they
are left int the `Options` category but put first.
fix: preserve jobserver file descriptors on rustc invocation to get `TargetInfo`
Then cargo asks rustc for `TargetInfo`, cargo passes environment variables that describe jobserver file descriptors, but doesn't actually passed them, because `jobserver-rs` sets `FD_CLOEXEC` by default and expects users to explicitly call `Client::configure` to pass them further. Rustc respects make jobserver, so this causes error - env vars refers to nonexistent file descriptors, which is ignored now.
This PR makes cargo compatible with https://github.com/rust-lang/rust/pull/113730, which attempts to catch such situations.
Fix printing multiple warning messages for unused fields in [registries] table
Cargo currently prints the same warning message multiple times for unexpected fields in the `[registries.<registry>]` or `[registry]` tables. This is because Cargo warns each time that the structure is deserialized from `Config`. Depending on which code path is taken I've seen the warning printed up to 6 times.
* A cache of deserialized registry configurations is added to the `Config` struct.
* Registry authentication is changed to directly read the config when searching for a registry name, rather than deserializing each registry configuration.
A test is added to ensure both `[registries]` and `[registry]` only warn once for unexpected fields.
Add allow(internal_features)
https://github.com/rust-lang/rust/pull/108955 has added a new deny-by-default lint to reject internal features, which is causing tests to fail on nightly. This adds an `allow` to work around that.
Update pretty_env_logger to 0.5
This updates pretty_env_logger from 0.4.0 to 0.5.0. The primary motivation is to drop some dependencies like `atty`.
https://github.com/seanmonstar/pretty-env-logger/compare/v0.4.0...v0.5.0
I think the main change is updating to env_logger 0.7 to 0.10 which syncs with what is normally used by cargo.
Remove build metadata from libgit2-sys dependency
This removes the `+1.6.4` build metadata from the libgit2-sys dependency because it causes cargo to generate a warning every time it is used.
In 1.71, `.cargo-ok` changed to contain a JSON `{ v: 1 }` to indicate
the version of it. A failure of parsing will result in a heavy-hammer
approach that unpacks the `.crate` file again. This is in response to a
security issue that the unpacking didn't respect umask on Unix systems.
Without this, an attacker can leverage globally writable files buried
in the `.crate` file. After a user downloaded and unpacked the file,
the attacker can then write malicous code to the downloaded sources.
