I put this behind `--verbose`
- To keep the output down in the standard case
- Because its assuming most people's "behind" dependencies will be
"Unchanged" and so that is when knowing how to look up how its pulled
in is useful
There might be casses where we want to show pre-release as this grows
but, for now, there isn't too often a case where an update is held back,
you are on a pre-release, your pre-release is updating, and you want a pre-release.
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.