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 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! :-)
