Provide a better error message when mixing dep: with /
Features of the form `dep:foo/feature` aren't accepted as valid syntax. This generated a somewhat confusing error message of:
```
feature `f1` includes `dep:bar/bar-feat`, but `dep:bar` is not a dependency
```
This PR adds a more targeted error message that provides some suggestions on how to fix it.
There is more context in #9574 as to why the syntax is the way it is.
Remove lingering unstable flag `-Zfeatures`
From [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/.E2.9C.94.20-Zfeatures):
> Eric Huss: When trying to validate that the feature resolver resolves features in the same way as the dependency resolver. I think it is identical, but there are a lot of complex use cases and flags that aren't covered in the testsuite so I'm not entirely confident. If we ever come across a scenario where it isn't the same, the compare option can be useful to see what differs.
In the future we could pick 61b94c3b0435250a0abb8080867b4af8d7dd88f8 to remove this Z flag.
Tweak wording
the "If, however, ..." construct reads a bit awkwardly, so tweaked it.
English is my native language, although I don't claim to be a grammar expert.
Expose libgit2-sys/vendored feature as vendored-libgit2
### What does this PR try to resolve?
Compiling cargo on MacOS can be problematic due present libraries, `cargo` already supports vendoring for openssl (and it helps https://github.com/pacak/cargo-show-asm/pull/51 to some users). This pull request attempts to extend vendoring support to libgit2 in order to fix more foreign library issues: https://github.com/pacak/cargo-show-asm/issues/50
While it is possible for me to enable it on my side (https://github.com/pacak/cargo-show-asm/pull/52) a special care needs to keep versions in sync. Exposing this feature in `cargo` directly will make such fixes for my and other crates more robust.
### How should we test and review this PR?
Disabled by default means existing behavior is unchanged, testing with it enabled to confirm if it still works should do the trick.
Indicate how Cargo locates the manifest
Currently the only place where that is documented is in an obscure flag called `--manifest-path`. The behaviour of Cargo in regards to locating the manifest should be in a more obvious place, and this seems to be right about where I added it.
Reduce references to `[project]` within cargo
There was an issue (#11129) with `[project]` being put in the docs but nothing else stating what `[project]` is. This was an oversight by me when writing the docs as `[project]` is still supported in cargo. [Back in 2014](86b2a2a432) `[project]` was [renamed to `[package]`](https://github.com/rust-lang/cargo/issues/3388#issuecomment-266504735), since then it has kinda sat as something that exists and is supported but not really. I brought this up in a [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/removal.20of.20.60.5Bproject.5D.60), and it was suggested that we could show a warning when `[project]` is used in a manifest of a _top-level_ crate.
To go slightly further than this I tried to change as many references from `[project]` to `[package]` as possible. This should hopefully help with confusion between `[project]` and `[package]` in the future.
This PR also includes a cherry-picked commit from #11131 as it was having issues with bors and fits well with the changes that are being made in this PR.
This should ideally be reviewed commit by commit
Iteratively construct target cfg
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 changes it so that cargo will call `rustc` up to two times to collect the `cfg` values, updating which flags to use on the second call based on the cfg discovered in the first call.
Closes#6858.
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.
