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 7a50c0c718f3547e3d76498770fc3ed256cb3994 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.
When setting target features via rustflags via `[build]` config key,
cargo correctly propagates them to rustc (via -C flag) and to build.rs
(via CARGO_CFG_TARGET_FEATURE env var).
However, if `[target.cfg]` is used instead, build.rs doesn't get the
flags (rustc still gets them though).
This will only show the messaeg if we didn't already show a version req
with full precision specified ... mostly. We'll also skip it if its a
local or git dependency but we never show the version in those cases
because it doesn't matter.
The `precise_version` logic came from cargo-upgrade.
This gives a hint to users that we might not be showing the feature list
for the latest version but the earliest version.
Also when using a workspace dependency or re-using an existing
dependency, this is a good reminder of what the version requirement is
that was selected.
However, when the user or add (the common case) selected a full
precision requirement, this is redundant.
I'm also mixed on whether the meta version should show up.
Fixes#11073
Improve error message for an array value in the manifest
Fixes https://github.com/rust-lang/cargo/issues/10942
The error message will be:
```
error: failed to parse manifest at `/Users/..`
Caused by:
invalid type: string "Ky", expected an array for key `package.authors`
```
Enable two windows tests
These two tests were disabled on Windows a long time ago. AFAICT, the reasons are no longer relevant, and it should be safe to enable these tests. See each commit for a more detailed exposition.
Improve error msg for get target runner
Actually, we'll get this config from three places. So this msg may be confusing when you set it up in `.cargo/config.toml` or pass it by `--config`.
We already printed the location of the config, so I think it's OK to change it to `configurations`.
Only override published resolver when the workspace is different
### What does this PR try to resolve?
Ensures when publishing a package that uses an implicit `resolver = "1"` to maintain an MSRV before the `resolver` key was stabilized the implicitness is retained rather than being turned into an explicit setting.
fixes#10954 (assuming that the workspace and its packages are configured with a consistent resolver)
Packages in the local workspace can't get updated this way; the user
just needs to point to a different source, or otherwise update the
package themselves.
People encountering a dependency with a newer `rust-version` requirement
may not know about `cargo update --precise`, or may consider alternate
approaches that may be harmful (such as pinning with a `=` dependency).
Provide specific guidance in the error message.
If the user is using `cargo install`, suggest `cargo install --locked` instead.
Test if reserved filenames are allowed in Windows
Recent versions of Windows have removed the limitation on filenames like `aux` or `con`. This change allows the `package::reserved_windows_name` to still pass by first trying to create a file with a reserved name to see if Windows supports it. If so, it skips the rest of the test. Otherwise, we keep the same behavior as before.
