Commit graph

12767 commits

Author SHA1 Message Date
bors
b2ee005824 Auto merge of #11162 - pacak:master, r=ehuss
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.
2022-09-30 00:14:30 +00:00
bors
c39193a7c5 Auto merge of #11159 - epage:clap4, r=weihanglo
refactor(cli): Upgrade to clap v4
2022-09-29 20:17:54 +00:00
Michael Baikov
8818a89330 Expose libgit2-sys/vendored feature as vendored-libgit2
disabled by default
2022-09-29 12:17:25 -04:00
Ed Page
69ba69f908 refactor: Resolve clap deprecations 2022-09-28 13:32:27 -05:00
Ed Page
96948f7a24 refactor(cli): Upgrade to clap v4 2022-09-28 13:32:14 -05:00
bors
a3e352e4b8 Auto merge of #11157 - weihanglo:expose-edition-doc, r=epage
Expose guide to adding a new edition as rustdoc
2022-09-28 16:20:43 +00:00
Weihang Lo
3589509155
Add intra-doc links for features! macro 2022-09-28 16:53:45 +01:00
Weihang Lo
677205c948
Add intra links for unstable features doc 2022-09-28 16:53:45 +01:00
Weihang Lo
ee4b265568
Expose doc "how to add a new Edition" as rustdoc 2022-09-28 16:53:45 +01:00
bors
d900b67345 Auto merge of #11158 - weihanglo:remove-multitarget-from-Zhelp, r=epage
Remove `multitarget` from -Zhelp
2022-09-28 15:31:45 +00:00
Weihang Lo
b1b7a40917
Remove multitarget from -Zhelp 2022-09-28 16:17:20 +01:00
bors
7145b9235b Auto merge of #11155 - hi-rustin:rustin-patch-comment, r=epage
Remove outdated comments

### What does this PR try to resolve?

I found an outdated comment when I was reading the code. So I removed it.
2022-09-28 14:30:45 +00:00
hi-rustin
b15f252d59 Remove outdated comments
Signed-off-by: hi-rustin <rustin.liu@gmail.com>
2022-09-28 11:05:15 +08:00
bors
f5fed93ba2 Auto merge of #11150 - seanbright:dashes, r=weihanglo
build-scripts.md: Use em dash consistently.

The list items in build-scripts.md were mixing en dash and em dash. This switches to just em dash.
2022-09-27 12:03:57 +00:00
bors
76f080be18 Auto merge of #10770 - wmstack:master, r=weihanglo
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.
2022-09-27 11:03:21 +00:00
Waleed Dahshan
1a886279fd indicate how cargo locates the manifest 2022-09-27 10:57:29 +00:00
bors
928561a0c5 Auto merge of #11135 - Muscraft:remove-ref-to-project, r=weihanglo
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
2022-09-27 09:26:27 +00:00
bors
f6de921a5d Auto merge of #11114 - matklad:build-falgs, r=ehuss
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.
2022-09-27 01:08:14 +00:00
Sean Bright
2590c1ebc6 build-scripts.md: Use em dash consistently. 2022-09-26 16:06:47 -04:00
Scott Schafer
8625d7274a fix(cargo): Add a warning on [project] table being used in a manifest 2022-09-26 10:32:48 -06:00
Scott Schafer
cabee4f511 fix(cargo): Add a warning on package and project in the same Cargo.toml 2022-09-26 10:32:07 -06:00
Scott Schafer
185054946b refactor: Reduce use of project in util/mod.rs 2022-09-26 09:51:16 -06:00
Scott Schafer
b7ca85d1e8 refactor: Rename TomlProject to TomlPackage 2022-09-26 09:51:16 -06:00
Scott Schafer
ab18bd40d5 refactor(testsuite): Replace [project] with [package] 2022-09-26 09:51:16 -06:00
Matthias Beyer
281113bcb5 Fix: "project" should be "package"
This was accidentially overlooked when writing the documentation.

Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
2022-09-26 09:51:16 -06:00
Aleksey Kladov
c333b0a7be when learning target information, run a little fixedpoint iteration loop 2022-09-26 13:22:43 +01:00
bors
abf6b4e447 Auto merge of #11146 - jiangying000:patch-1, r=weihanglo
update comment about `CARGO_BIN_EXE_`
2022-09-26 07:51:23 +00:00
jiangying
260620e755
Update test.rs 2022-09-26 15:28:16 +08:00
jiangying
dc61e112da
Update mod.rs 2022-09-26 15:26:19 +08:00
bors
13ae438cf0 Auto merge of #11139 - weihanglo:issue/11041, r=epage
Call out that not all config values can be set via env vars
2022-09-23 15:41:55 +00:00
bors
254cf2fa35 Auto merge of #11137 - weihanglo:version-bump, r=epage
Bump to 0.67.0, update changelog
2022-09-23 15:01:39 +00:00
Weihang Lo
7c2acdbfa3
Call out that not all config values can be set via env vars 2022-09-23 14:52:45 +01:00
Weihang Lo
b514a06e61
Update changelog for 1.65 2022-09-23 09:32:22 +01:00
Weihang Lo
92df3e73e6
Bump to 0.67.0 2022-09-23 09:20:30 +01:00
bors
1a5a7ff321 Auto merge of #11134 - weihanglo:ci/update-toolchain-contrib-doc, r=epage
ci: update toolchain for building api doc
2022-09-23 01:33:52 +00:00
bors
902bb0c2fc Auto merge of #11111 - Muscraft:http-publish-not-noop, r=ehuss
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.
2022-09-23 00:08:26 +00:00
Weihang Lo
ba3d2e981b
ci: update toolchain for building api doc 2022-09-22 21:40:27 +01:00
bors
9230e4839d Auto merge of #11113 - rdimartino:maybeworkspace-deserialize, r=epage
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.
2022-09-22 20:10:33 +00:00
bors
dbd1c18379 Auto merge of #11130 - Muscraft:use-ready-macro, r=Eh2406
switch to `std::task::ready!()` where possible

In Rust 1.64.0, [`std::task::ready`](https://doc.rust-lang.org/stable/std/task/macro.ready.html) was [stabilized](https://blog.rust-lang.org/2022/09/22/Rust-1.64.0.html#stabilized-apis). Using `ready!()` can make what is happening clearer in the code as it expands to roughly:
```rust
let num = match fut.poll(cx) {
    Poll::Ready(t) => t,
    Poll::Pending => return Poll::Pending,
};
```
This PR replaces places using `Poll::Pending => return Poll::Pending`  with `ready!()` where appropriate.

I was unsure about how useful the new macro would be in one place in [`cargo/registry/index.rs`](247ca7fd04/src/cargo/sources/registry/index.rs (L425-L429)), so I left it out and will add it in if needed.

Close #11128

r? `@Eh2406`
2022-09-22 19:29:20 +00:00
Scott Schafer
0c2e0feaf3 switch to std::task::ready!() where possible 2022-09-22 12:52:02 -06:00
Scott Schafer
251a2c7915 cargo-test-support: Make publish http api write to file system 2022-09-22 10:00:49 -06:00
bors
247ca7fd04 Auto merge of #11087 - weihanglo:issue-11013, r=epage
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.
2022-09-22 14:51:58 +00:00
bors
8882d993f3 Auto merge of #11127 - matklad:unused-mut, r=Eh2406
minor: remove unused mut
2022-09-22 14:06:49 +00:00
Aleksey Kladov
73c79c7821 minor: remove unused mut 2022-09-22 15:04:00 +01:00
Weihang Lo
5caabc0ade
doc: rustdoc for aliased_command 2022-09-22 10:52:39 +01:00
Weihang Lo
5dd982d8af
Make cargo version work even with malformed configurations 2022-09-22 10:52:39 +01:00
Weihang Lo
ef7a4ef062
Dont swallow errors when checking existence of a config key 2022-09-22 10:52:39 +01:00
Weihang Lo
2c6647df80
test(alias): with malformed config no proper error emitted
This demonstrate the old behaviour that no proper error is emitted if
there is a parse error during configuration parsing.
2022-09-22 10:46:32 +01:00
bors
7c8a5a67d3 Auto merge of #11118 - epage:external, r=weihanglo
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.
2022-09-22 07:56:31 +00:00
bors
635a84854b Auto merge of #10938 - ptdecker:add-author-example, r=weihanglo
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!  :-)
2022-09-21 20:44:58 +00:00