Use thiserror for credential provider errors
### What does this PR try to resolve?
Errors from credential providers currently must a single string. This leads to a lot of `.map_err(|e|cargo_credential::Error::Other(e.to_string())`, which loses the `source()` of these errors.
This changes the `cargo_credential::Error` to use `thiserror` and adds a custom serialization for `std::error::Error` that preserves the source error chain across serialization / deserialization.
A unit test is added to verify serialization / deserialization.
Clarify in `--help` that `cargo test --all-targets` excludes doctests
Per my proposal here: https://github.com/rust-lang/cargo/issues/6669#issuecomment-1658593167
I tried to keep the edit minimalistic to match the surrounding style.
If the maintainers are amenable to it, I think it could also be useful to do one or more of:
- Offer concrete guidance on what to do to run actually-all tests (`--all-targets` then separately `--doc`).
- Link to the issue at: https://github.com/rust-lang/cargo/issues/6669
- Mention that `cargo test` without `--all-targets` runs doctests by default, which seems not immediately obvious.
I'd be happy to attempt to add any of the above that the maintainers feel would be a good fit here.
Per my proposal here: https://github.com/rust-lang/cargo/issues/6669#issuecomment-1658593167
I tried to keep the edit minimalistic to match the surrounding style.
If the maintainers are amenable to it, I think it could also be useful to do one or more of:
- Offer concrete guidance on what to do to run actually-all tests (`--all-targets` then separately `--doc`).
- Link to the issue at: https://github.com/rust-lang/cargo/issues/6669
- Mention that `cargo test` without `--all-targets` runs doctests by default, which seems not immediately obvious.
I'd be happy to attempt to add any of the above that the maintainers feel would be a good fit here.
Git only assumes a submodule URL is a relative path if it starts with `./`
or `../` [^1]. To fetch the correct repo, we need to construct an aboslute
submodule URL.
At this moment it comes with some limitations:
* GitHub doesn't accept non-normalized URLs wth relative paths.
(`ssh://git@github.com/rust-lang/cargo.git/relative/..` is invalid)
* `url` crate cannot parse SCP-like URLs.
(`git@github.com:rust-lang/cargo.git` is not a valid WHATWG URL)
To overcome these, this patch always tries `Url::parse` first to normalize
the path. If it couldn't, append the relative path as the last resort and
pray the remote git service supports non-normalized URLs.
See also rust-lang/cargo#12404 and rust-lang/cargo#12295.
[^1]: <https://git-scm.com/docs/git-submodule>
fix(package): Recognize and normalize `cargo.toml`
### What does this PR try to resolve?
This solution is a blend of conservative and easy
- Normalizes `cargo.toml` to `Cargo.toml` on publish
- Ensuring we publish the `prepare_for_publish` version and include `Cargo.toml.orig`
- Avoids dealing with trying to push existing users to `Cargo.toml`
- All other cases of `Cargo.toml` are warnings
- We could either normalize or turn this into an error in the future
- When helping users with case previously, we've only handle the `cargo.toml` case
- We already should have a fallback in case a manifest isn't detected
- I didn't want to put in too much effort to make the code more complicated to handle this
As a side effect, if a Linux user has `cargo.toml` and `Cargo.toml`, we'll only put one of them in the `.crate` file. We can extend this out to also include a warning for portability for case insensitive filesystems but I left that for after rust-lang/cargo#12235.
### How should we test and review this PR?
A PR at a time will show how the behavior changed as the source was edited
This does add a direct dependency on `unicase` to help keep case-insensitive comparisons easy / clear and to avoid riskier areas for bugs like writing an appropriate `Hash` implementation. `unicase` is an existing transitive dependency of cargo.
### Additional information
Fixes#12384
[Discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/.60cargo.2Etoml.60.20on.20case.20insensitive.20filesystems)
Clarify `lto` setting passing `-Clinker-plugin-lto`
Previously this document implied that the `lto` setting only controlled `-C lto` but in some cases it can also pass `-C linker-plugin-lto`
1b3eb297f9/src/cargo/core/compiler/mod.rs (L1234)
doc: add missing reference to `CARGO_PROFILE_<name>_STRIP` in environment variables docs
The doc for the env var was added in b6d1979683 but was forgotten in env vars
To keep things simple, especially in getting a `Hash` implementation
correct, I'm leveraging `unicase` for case-insensitive
comparisons which is an existing dependency and I've been using for
years on other projects.
This also opens the door for us to add cross-platform compatibility
hazard warnings about multiple paths that would write to the same
location on a case insensitive file system. I held off on that because
I assume we would want #12235 first.
This does mean we can't test the "no manifest" case anymore because the
one case (no pun intended) I knew of for hitting it is now gone.
docs: raise awareness of resolver used inside workspace
Workspaces by default use the resolver in version 1. It's been some time already since the 2021 edition which made version 2 a default for alone packages, but yet most of the projects that make a use of the workspaces still depends on an old resolver.
By being explicit about the resolver tag inside the workspace we can lower the usage of older resolver for the new projects.
This can raise the awareness of this behavior and prevent issues like https://github.com/rust-lang/cargo/issues/12387. I also wasn't aware of this behavior before while not being so new to Rust, and we have the resolver 2 for good reasons, so I think we should be more explicit about it in the documentation.
When someone looks for the 'how to make cargo workspace' answers, he's unlikely to get to the `Dependency Resolution` section at the same time, he'll likely just copy paste the workspace example from the `Workspaces` and call it a day, yet extending the usage of an old resolver and not benefiting from the new one.
Update curl-sys to pull in curl 8.2.0
This is a routine update to curl-sys 0.4.64, updating curl from 8.1.2 to 8.2.0.
Changelog: https://curl.se/changes.html#8_2_0
test(cli): Track --help output
### What does this PR try to resolve?
This makes it easier to evaluate the usability of PRs, like #11905
This follows the pattern of `cargo add` and `cargo remove` of putting these ui tests in `cargo_<cmd>/` directories. `init` didn't follow this pattern, so it was renamed to `cargo_init/`. `cargo_config.rs` was going to conflict with this, it was merged in.
We can evaluate other `<cmd>.rs` files at a later point and consolidate.
### How should we test and review this PR?
The main risks are
- Are all files linked together (`main.rs` -> `<cmd>/mod.rs` -> `<cmd>/<help>.rs`
- Are all `help/mod.rs`s pointing to the right command
refactor(test): Move cargo-config into a dir
This is split out of #11912 and is prep for adding more UI tests.
Generally our UI tests are in a directory named after the full cargo command (`cargo config`). These tend to use `snapbox`.
Here we are tests for the `cargo config` command not written by `snapbox` in a `cargo_config.rs` file. This conflicts with adding snapbox UI tests later in a `cargo_config/` folder. Upon looking at this file, it appears to be UI tests, so I think it would make sense to move them into the `cargo_config/` folder. Definitely wouldn't make sense to move them into `config.rs` since that is general config testing.
This is split out of #11912 and is prep for adding more UI tests.
Generally our UI tests are in a directory named after the full cargo
command (`cargo config`). These tend to use `snapbox`.
Here we are tests for the `cargo config` command not written by
`snapbox` in a `cargo_config.rs` file. This conflicts with adding
snapbox UI tests later in a `cargo_config/` folder. Upon looking at this
file, it appears to be UI tests, so I think it would make sense to move
them into the `cargo_config/` folder. Definitely wouldn't make sense to
move them into `config.rs` since that is general config testing.
refactor(tests): Name init ui tests more consistently
Currently, the UI tests are
- `cargo add`
- `cargo new`
- `cargo remove`
- `init`
One of these is not like the others. This change renames `init` to `cargo_init` to suggest it is the UI tests for the `cargo init` command, rather than `init` functionality.
Currently, the UI tests are
- `cargo add`
- `cargo new`
- `cargo remove`
- `init`
One of these is not like the others. This change renames `init` to
`cargo_init` to suggest it is the UI tests for the `cargo init` command,
rather than `init` functionality.
credential provider implementation
The current credential process protocol only allows sending the credential without any additional information. This changes the protocol in two important ways: Cargo will tell the credential provider what the token is needed for, and the credential provider can tell Cargo how the token can be used.
Since the credential provider knows why Cargo needs a token (`publish` for example), it can produce a signed token specifically for that operation. This would enable a credential process to produce an asymmetric token, or a token with restricted scope such as PASETO or Biscuit.
The credential process can also indicate back to Cargo if the token can be cached in-memory for subsequent requests. For example, if a credential provider integrates with an SSO identity provider that provides short-lived tokens, Cargo will only continue to use the token while it is valid.
### Summary of changes
* Rename `credential-process` to `credential-provider` in config.
* Add a new line-oriented JSON protocol for communicating with external credential providers via stdin/stdout.
* Allow built-in credential providers to run in the Cargo process.
* Move support for asymmetric tokens (RFC3231) into a built-in credential provider (`cargo:paseto`).
* Change the unstable key for asymmetric tokens from `registry-auth` to `credential-process`
* Add a new built-in provider to represent the current config/token based system (`cargo:token`).
* Add a new built-in provider for the a "basic" provider that prints only the token on stdout (`cargo:basic`).
* Create a new config key for the fallback credential providers (`registry.credential-providers`) as a list.
* The provider for `crates.io` no longer also acts as a fallback for other registries.
* Adds a `[credential-alias]` table for defining aliases of credential providers.
* Collect all headers from `http_registry` requests, passing them through to the cred provider.
Everything remains unstable under the `-Zcredential-process` flag.
### How to review this:
I recommend starting with the changes in `unstable.md` for a more detailed description.
### Open questions
* [x] Should we pass all the HTTP headers rather than just `www-authenticate`
