Fix old_cargos tests
Some of these tests have bitrotted a bit since they aren't enabled by default. The issues are:
* Change to `config` to `config.toml` shouldn't have been made to this test since old cargos can't read config.toml.
* Cargo's own `Carog.toml` now using dotted keys breaks parsing on some old versions, ignore them.
* `cargo pkgid` is now emitting a different format.
* #13085 changed how packages are published in the testsuite to correctly include the `[features]` table in the generated `Cargo.toml`. This exposed an oversight in the `old_cargos::new_features` test wasn't actually testing things correctly. It now correctly illustrates the errors received in older versions. I have a vague memory of this, but I don't remember why it was done this way.
* #10907 changed the default config to use `[registries]` instead of `[source]` to implement source replacement of crates.io. Older versions can't handle that.
Some of these tests probably should just be deleted, since I don't think they are really bringing much value. Or at least they should have some floor that they won't test under. However, I'm not quite ready to do that.
feat: Add hint for adding members to workspace
### What does this PR try to resolve?
Fixes https://github.com/rust-lang/cargo/issues/13403
### How should we test and review this PR?
Reviewd commit by commit
### Additional information
fix: Switch more notes/warnings to lowercase
See https://doc.crates.io/contrib/implementation/console.html#style
By fixing existing cases, we make it more likely people will copy a case they should.
I left out multi-sentence cases because I was unsure how to handle those
Don't add the new package to workspace.members if there is no existing workspace in Cargo.toml.
### What does this PR try to resolve?
Fixed https://github.com/rust-lang/cargo/issues/13345
If the current package has no workspace table in Cargo.toml, then if you run `cargo add foo`, don't create the workspace inline item and don't add `foo` into the workspace.members.
### How should we test and review this PR?
Reviewed by commit by commit.
### Additional information
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`
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.
`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
```
