Http publish not noop
Currently the `cargo-test-support` `HttpServer` is noop on publish. This was causing issues with #11062 as there is [not function registry to pull from](https://github.com/rust-lang/cargo/pull/11062#issuecomment-1241220565). [A suggested fix](https://github.com/rust-lang/cargo/pull/11062#issuecomment-1241349110) to this was to have the test `HttpServer` act like a real registry and write to the filesystem. This would allow for tests to be run over the HTTP API and not fail since there was nothing to pull from.
This PR implements that suggestion by adding a body field to `Request`, and when hitting the publish endpoint it will try and write the `.crate` and manifest information to the filesystem.
Improve errors for TOML fields that support workspace inheritance
Fixes#10997
This also addresses the issue with `MaybeWorkspace<VecStringOrBool>` mentioned in #10942:
```
Caused by:
invalid type: string "foo", expected a boolean or vector of strings for key `package.publish`
```
I removed the `maybe_workspace_vec_string` deserializer in 7a50c0c718 because the error message from the inner `Vec<String>` is now surfaced, but I can revert that if it's preferable to keep those changes.
I tried to base the `deserialize` implementation off of the derived impl for an untagged enum from `cargo expand`. This approach [ultimately led me](https://github.com/serde-rs/serde/blob/v1.0.144/serde/src/private/de.rs#L218) to adding the `serde-value` dependency.
Report cmd aliasing failure with more contexts
### What does this PR try to resolve?
Commands aliasing resolution should report TOML parsing error to users.
Fixes#11013.
### How should we test and review this PR?
https://github.com/rust-lang/cargo/pull/11087/commits/ef7a4ef is the most important commit in this PR. `has_key` now throws errors after this PR, so any use `Config::get<Option<…>>()` is affected if there is a malformed config. Had a skim over all usages of `get::<Option<…>>`, `get_string` and `get_path`, I don't feel any of them should ignore errors.
fix(cli): Forward non-UTF8 arguments to external subcommands
Whether we allow non-UTF-8 arguments or not, we shouldn't preclude external subcommands from deciding to do so.
I noticed this because clap v4 changed the default for external subcommands from `String` to `OsString` with the assumption that this would help people to "do the right thing" more often.
This change adds an example to the authors attribute in the manifest.
It is submitted to clarify the documenation for new folks such as
myself. See the forum issue linked below which prompted this change
since the error message the compiler issues is not clear for new
folks.
https://users.rust-lang.org/t/compile-error-when-adding-authors-to-cargo-toml/79383
Thank you for considering this contribution. It's my first so go
easy on me please! :-)
I noticed this because clap v4 changed the default for external
subcommands from `String` to `OsString` with the assumption that this
would push people to "do the right thing" more often.
refactor(cli): Prepare for clap v4
This is two minor refactors that better align us with the upcoming clap v4
- `clap::ErrorKind` has moved to `clap::error::ErrroKind` during 3.x and in 4.0 the old location no longer works
- `clap::App` was renamed to `clap::Command` and in v4 the lifetime will be removed which will remove the need for us to have an alias at all. This does the rename so we can just use what clap has in v4.
Some linkers do not remove the executable, but truncate and modify it.
That results in the old hard-link being modified even after renamed.
We delete the old artifact here to prevent this behavior from confusing users.
See rust-lang/cargo#8348.
clap 3.1 renamed `App` to `Command`. When we upgrade to clap v4, the
lifetime will be removed and we can just use `clap::Command` instead of
a type alias. This is prep for that.
Add a minor clarification
### What does this PR try to resolve?
It tries to clarify the overriding build scripts section. We spent over an hour with 3 people trying to get it to work and it was extremely difficult to figure out.
### How should we test and review this PR?
N/A
### Additional information
N/A
Revert "Clarify when cargo detects changes"
Reverts rust-lang/cargo#11092
We had not fully confirmed that this language change matches the new behavior.
docs(ref): Clarify workspace settings
### What does this PR try to resolve?
In reviewing the status of #10625, I was reminded
- that we are having growing pains with the workspace documentation
- that `workspace.resolver` isn't documented
So I re-organized the workspace docs to have a high level intro / behavior description and then to focus on being a field reference, much like `manifest.md`. I could see splitting it specifically into tutorial/reference like the overriding dependencies document does it.
When adding `workspace.resolver`, I remembered in the nested workspace discussion there were other workspace related sections that are not present. We now link out to `profile`, `patch`, and `replace`. In doing this, I realized that `patch` and `replace` do not specify their workspace behavior, so I do that.
### How should we test and review this PR?
Look at it commit by commit to get more digestible chunks. Unfortunately, the first commit didn't split up so easily.
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
<!-- homu-ignore:end -->
[master] Run `reach_max_unpack_size` test only on debug build
`cargo test --release` fails on test `reach_max_unpack_size` as the binary to exercise is optimized. The alternative approach is removing `cfg!(debug_assertions)` from this line.
<9ef926dafc/src/cargo/sources/registry/mod.rs (L842)>
#11089