cargo-credential-gnome-secret: dynamically load libsecret
Building `cargo-credential-gnome-secret` currently requires the `libsecret` development libraries to be installed and findable via `pkg-config`. This is often an extra step for users and complicates CI builds.
This loads the required functions from `libsecret` dynamically using `libloading` which uses `dlopen` internally.
Closes#12503
Testing this requires manually installing the credential provider on a system with libsecret set up. I tested it on Arch Linux.
credential-providers: make 1password no longer built-in
Since 1password is just one of many potential CLI-based credential providers, it makes more sense for it to be installable as a plugin rather than built-in to Cargo.
This means that `cargo:1password` will no longer work as a credential provider.
The replacement would be `cargo install cargo-credential-1password` and using `cargo-credential-1password` instead.
r? `@ehuss`
credential: rename cargo:basic to cargo:token-from-stdout
Multiple people have said that the name of the `cargo:basic` credential provider is confusing, since it's not doing HTTP Basic authentication.
Rename `cargo:basic` to `cargo:token-from-stdout`, which more accurately describes what it does.
versions and paths of a workspace members between the original and
a checked-out workspace are different, and shouldn't be included in
hash keys when querying packages.
The `github.sha` is a merge commit with the parents of latest master
and the head of the pr. Trying to diff the changes from that merge
SHA to base will show all changes that have been made in-between.
And that doesn't seem about right.
We switch to `github.event.pull_request.head.sha` if there is a pr.
See: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/version-bump.20CI.20failing
Crate checksum lookup query should match on semver build metadata
Since crates.io allows crate versions to differ only by build metadata, a query using `OptVersionReq::exact` + `next()` can return nondeterministic results.
This change fixes the issue by adding an additional `filter` that ensures the version is equal (including build metadata).
It still feels somewhat wrong that a query using `exact` can match multiple crates, so an alternative fix would be to add a new variant of `OptVersionReq` that also matched on build metadata.
Fixes#11412
It confuses people that both `--no-fail-fast` and `--keep-going` exist
on `cargo test` and `cargo bench` but with slightly different behavior.
The intended use cases for `--keep-going` involve build commands like
`build`/`check`/`clippy` but never `test`/`bench`.
Hence, this commit removes `--keep-going` from `test`/`bench` and
provides guidance of `--no-fail-fast` instead.
If people really want to build as many tests as possible, they can also
do it in two steps:
cargo build --tests --keep-going
cargo test --test --no-fail-fast
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.
-->
