Apply `-Zpanic-abort-tests` to doctests too
### What does this PR try to resolve?
`cranelift` doesn't support unwinding, which causes issues with `should_panic` tests. Attempting to use `-Zpanic-abort-tests` to fix that still fails with doctests because they attempt to use unwinding. `rustdoc` already supports specifying `-Cpanic=abort` and correctly handles ` ```should_panic` tests with it enabled, so we can just start passing it when `-Zpanic-abort-tests` is set.
Fixes https://github.com/rust-lang/rust/issues/120578 (when using `-Zbuild-std=std,panic_abort` too)
This commit lifts a helper function from invoking rustc to additionally
being used for invoking rustdoc. This enables hiding the command line
invocation of `rustdoc` by default when it fails, although it's still
available to see with `--verbose`. The intention here is to match the
behavior of `cargo build` for rustc failures here and was inspired by
recently running `cargo doc` and not being able to see the actual
failure as the command line ended up taking the whole screen (afterwards
I made the screen bigger and that helped too).
Add `docsrs` cfg as a well known `--check-cfg`
Now that https://github.com/rust-lang/docs.rs/pull/2390 has been merged we can add the `docsrs` cfg in Cargo well known --check-cfg "list". The `docsrs` cfg used by at least [3k project on GitHub](https://github.com/search?q=lang%3Atoml+%2Frustdoc-args+%3D+%5C%5B%22--cfg%22%2C+%22docsrs%22%5C%5D%2F+NOT+is%3Afork&type=code&repo=&langOverride=&start_value=1) alone; including the cfg will help reduce the impact of enabling by default this feature.
> We include it here (in Cargo) instead of rustc, since there is a much closer relationship between Cargo and docs.rs than rustc and docs.rs. In particular, all users of docs.rs use Cargo, but not all users of rustc (like Rust-for-Linux) use docs.rs.
This is part of the last remaining bits of the `--check-cfg` feature.
r? `@epage`
`rustc` will start marking the suggestions for prefacing unused bindings
with underscores as "maybe incorrect", which makes them no longer auto
applicable by `rustfix`.
Change done at https://github.com/rust-lang/rust/pull/120470.
fix(new): Print a 'Creating', rather than 'Created' status
### What does this PR try to resolve?
This has bothered me about `cargo new` and `cargo init` for a while that
the output is read backwards, for example:
```diff
--- i/tests/testsuite/cargo_init/path_contains_separator/stderr.log
+++ w/tests/testsuite/cargo_init/path_contains_separator/stderr.log
`@@` -1,3 +1,3 `@@`
+ Creating binary (application) package
warning: the path `[ROOT]/case/test:ing/.` contains invalid PATH characters (usually `:`, `;`, or `"`)
It is recommended to use a different name to avoid problems.
- Created binary (application) package
```
### How should we test and review this PR?
### Additional information
This has bothered me about `cargo new` and `cargo init` for a while that
the output is read backwards, for example:
```diff
--- i/tests/testsuite/cargo_init/path_contains_separator/stderr.log
+++ w/tests/testsuite/cargo_init/path_contains_separator/stderr.log
@@ -1,3 +1,3 @@
+ Creating binary (application) package
warning: the path `[ROOT]/case/test:ing/.` contains invalid PATH characters (usually `:`, `;`, or `"`)
It is recommended to use a different name to avoid problems.
- Created binary (application) package
```
In #7295 (released in 1.39), we said we'd want to warn on use of
`.cargo/config` after about 6 months. Over 4 years later, we are now
getting that warning.
This is important for addressing user confusion, like in
https://www.reddit.com/r/rust/comments/19fd5q2/cargoconfig/
External subcommands are already able to inherit the jobserver from
env since #10511. However, users reported that they've expected
`cargo run` to behave the same as external subcommands.
A popular example "cargo-xtask" pattern is used as scripting to run
arbitrary tasks. Users may want to invoke `cargo run` from Make and
expect some parallelism. This PR provides such an ability to the
general `target.<...>.runner`, which affects `cargo test`,
`cargo bench`, and `cargo run`.
Note that this PR doesn't create any jobserver client if there is no
existing jobserver from the environment. Nor `-j`/`--jobs` would create
a new client. Reasons for this decision:
* There might be crates don't want the jobserver to pollute their
file descriptors, although they might be rare
* Creating a jobsever driver with the new FIFO named pipe style is not
yet supported as of `jobserver@0.1.26`. Once we can create a named
pipe-based jobserver, it will be less risky and inheritance by
default can be implemented.
Go back to passing an empty `values()` when no features are declared
This PR is basically a revert of https://github.com/rust-lang/cargo/pull/13011, which made the `--check-cfg` invocation be `cfg()` when no features are declared instead of `cfg(feature, values())` since it meant declaring that the config `feature` were to be available in this form: `#[cfg(feature)]`, which is not the case.
Thankfully after some brainstorming, I [proposed](https://github.com/rust-lang/rust/pull/119930) changing the behavior of empty `values()` in `rustc` to no longer imply the _none_ value and simply create an empty set of expected values. 😃
For Cargo, always using `cfg(feature, values(...))` means that the config `feature` is always expected, regardless of the number of features. This makes the warning better, as it will now always be `unexpected config value` (instead of `unexpected config name`). 🎉
Fixes https://github.com/rust-lang/cargo/pull/13011#issuecomment-1819427800 as well as the concern in the [tracking issue](https://github.com/rust-lang/cargo/issues/10554).
r? `@epage`
Previously if a value from `--package` flag contains `?`, Cargo
considered it as a glob pattern. However, staring from 12933 the
Package Id Spec has been extended to accept `?` for git sources.
This PR adjust accordingly to accept `?` from `--package` flag
when it is a valid Package Id Spec.
In 12914 we stabilized pkgid spec as unique package identifier for
`cargo metadata`. However, we forgot to make the same change to
JSON message format[^1]. This PR does so.
Note that the `package_id` field in JSON message is not clearly stated
as "opaque", so it might be considered as a breaking change to some extent.
[^1]: https://doc.rust-lang.org/nightly/cargo/reference/external-tools.html#compiler-messages
Strip debuginfo when debuginfo is not requested
### What does this PR try to resolve?
This PR implements [this proposal](https://github.com/rust-lang/cargo/issues/4122#issuecomment-1868318860). It contains a detailed description of the change.
As a summary, this PR modifies Cargo so that if the user doesn't set `strip` explicitly, and debuginfo is not enabled for any package being compiled, Cargo will implicitly set `strip = "debuginfo"`, to strip pre-existing debuginfo coming from the standard library. This reduces the default size of release binaries considerably (~4.5 MiB => ~450 KiB for helloworld on Linux x64).
Perhaps we could only add the `-Cstrip` option for the leaf/root target (i.e., a binary), but cargo already passes `-Cstrip` to libraries if it's set by `[profile.<...>.package.<lib>]`, so it seems harmless.
Fixes: https://github.com/rust-lang/cargo/issues/4122
### How should we test and review this PR?
Best reviewed commit by commit. There is one commit that fixes an existing related test that was using wrong assertion.
### Additional information
The implementation of the deferred option was inspired by `DebugInfo`, which already uses a similar concept.
### Unresolved questions
Should we also do this on macOS by default? It [seems](https://github.com/rust-lang/cargo/issues/11641) that there can be some issues with `strip` there. If it doesn't work, it basically inhibits compilation in release mode, with no easy way to opt out (unless the user explicitly requests debuginfo, but that's not the same as the previous state).
fix(metadata): Stabilize id format as PackageIDSpec
### What does this PR try to resolve?
For tools integrating with cargo, `cargo metadata` is the primary interface. Limitations include:
- There isn't an unambiguous way to map a package entry from `cargo metadata` to a parameter to pass to other `cargo` commands. An `id` field exists but it is documented as an opaque string, useful only for comparisons with other `id`s within the document.
- There isn't an unambiguous way of taking user parameters (`--package`) and mapping them to `cargo metadata` entries. `cargo pkgid` could help but it returns a `PackageIdSpec` which doesn't exist within the `cargo metadata` output.
This attempts to solve these problems by switching the `id` field from `PackageId` to `PackageIdSpec` which is a [publicly documented format](https://doc.rust-lang.org/cargo/reference/pkgid-spec.html), can be generated by `cargo pkgid`, and is accepted by most commands via the `--package` flag.
As the `"id"` field is documented as opaque, this technically isn't a breaking change though people could be parsing it.
For `cargo_metadata` they do [use a new type that documents it as opaque but publicly expose the inner `String`](https://docs.rs/cargo_metadata/latest/cargo_metadata/struct.PackageId.html). The `String` wasn't publicly exposed due to a request by users but instead their `PackageId` type replaced using `String`s in the API in oli-obk/cargo_metadata#59 with no indication given as to why the `String` was still exposed. However, you'll note that before that PR, they had `WorkspaceMember` that parsed `PackageId`. This was introduced in oli-obk/cargo_metadata#26 without a motivation given.
**Note that `PackageIdSpec` has multiple representation that might uniquely identify a package and we can return any one of them.**
Fixes#7267
### How should we test and review this PR?
### Additional information
cc `@oli-obk`
