[beta] Add common profile validation.
Beta backport of:
* #10411 — This is intended to limit any potential misuse of rustflags in profiles.
* #10396 — Fix CI due to clap deprecation
Avoid new deprecation warnings from clap 3.1.0
### What does this PR try to resolve?
This fixes a number of new deprecations in [clap 3.1.0](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md#310---2022-02-16) that are currently causing CI to fail for all other PRs due to `-Dwarnings`.
Add common profile validation.
This fixes an oversight where `rustflags` is not nightly-gated in a profile override (like `[profile.dev.package.foo]`).
The problem is that the validation was only being done for the top-level profile.
The solution here is to consolidate common profile validation that should be done for both the top level and the overrides. In the process I also fixed validation of `codegen-backend` which also is shared. This will hopefully help prevent other oversights in the future.
Have traced down the issue. It feel like the original intent is to
ignore `Cargo.lock` and `target` at project root but not subdirectories.
1. The original implementation did ignore root `/Cargo.lock`.
https://github.com/rust-lang/cargo/pull/321
2. Someday one wanted to support both gitignore and hgingore's syntax
and removed the leading slash.
https://github.com/rust-lang/cargo/pull/1247
3. Later, one found that we should not ignore `target` other than
under root directory and added `/target` back.
https://github.com/rust-lang/cargo/pull/4099
4. It turns out that the syntax is not compatible between gitignore
and hgignore. Therefore, one started to use hgignore special syntax
to handle `Cargo.lock`.
https://github.com/rust-lang/cargo/pull/4342
This commit rollbacks to what original implementation tries to do.
The `strip` option allows the string `"off"`, which `rustc` doesn't
have, and maps it to `"none"`. Remove that equivalent, and just keep
`"none"`.
Simplify and clarify the documentation for `strip` accordingly.
`strip` reused the `is_off` function from `lto`, which also had the net
effect of allowing `"n"` and `"no"`, which weren't documented as
supported. This change drops those as well.
Improve startup time of bash completion.
`cargo list` takes about .15 seconds on my computer which is
substantial enough to be the slowest command run when my shell starts
according to [sstephenson's bashprof](https://github.com/sstephenson/bashprof).
This commit defers running `cargo list` until we need it for the first
time.
# Testing
After starting a new shell (which has loaded cargo's bash completion)
type `cargo <TAB><TAB>` and see the output matches the output prior to
this change (ie: the commands given by `cargo list`). You should
observe a small delay. You should observe no such delay on subsequent
attempts within the same session.
`cargo list` takes about .15 seconds on my computer which is
substantial enough to be the slowest command run when my shell starts
according to sstephenson's bashprof.
This commit defers running `cargo list` until we need it for the first
time.
Stabilize `-Ztimings` as `--timings`
The `-Ztimings` option has existed for years, and many people use it to
profile and optimize their builds. It's one of the common reasons people
use nightly cargo.
The machine-readable JSON output may warrant further careful inspection
before we commit to a stable format. However, for the human-readable
output we don't need to make any commitment about the exact output.
Add a `--timings` option, as the stable equivalent to `-Ztimings`.
(Passing `html` or `json` requires `-Zunstable-options`, but the default `--timings` does not.)
Document the new option, and update the testsuite.
fix(install): Keep v1 file formatting the same
Inspired by #10345, I looked for other cases where
`toml_edit::easy::to_string` is used (which outputs inline tables) to
see if we should switch to `to_string_pretty`. The crates v1 file was
the only case I found.
As a side effect, we can no longer elide the empty `dev-dependencies`
table in published manifests. This was the behavior before `toml_edit`,
so not much of a loss.
Do not ignore `--features` when `--all-features` is present
This allows to specify dependency features when using `--all-features`, for example:
```shell
$ cargo run --example example --all-features --features="tracing/log"
```
You can test this in this repository: https://github.com/WaffleLapkin/cargo_all_some_features, it contains an example with ``required-features = [..., "tracing/log"]`` that is impossible to run with `--all-features` without this patch.
An attempt to fix#10333
test: Fix compatibilty with new toml_edit
`toml_edit` fixed a bug in 0.13.4 that this test was relying on that is
meant to help with rust-lang/cargo#10349. This basically restores us
back to the pre-toml_edit behavior for published manifests.
I included the `Cargo.toml` change to ensure any existing lock files on people's machines get updated so the test won't mysteriously start failing for them when doing a `pull`.
`toml_edit` fixed a bug in 0.13.4 that this test was relying on that is
meant to help with rust-lang/cargo#10349. This basically restores us
back to the pre-toml_edit behavior for published manifests.
Inspired by #10345, I looked for other cases where
`toml_edit::easy::to_string` is used (which outputs inline tables) to
see if we should switch to `to_string_pretty`. The crates v1 file was
the only case I found.
As a side effect, we can no longer elide the empty `dev-dependencies`
table in published manifests. This was the behavior before `toml_edit`,
so not much of a loss.
This avoids dropping them wherever Cargo happens to run from, and
instead places them under the target directory.
This has the advantage, and disadvantage, that `cargo clean` will remove
them.
The `-Ztimings` option has existed for years, and many people use it to
profile and optimize their builds. It's one of the common reasons people
use nightly cargo.
The machine-readable JSON output may warrant further careful inspection
before we commit to a stable format. However, for the human-readable
output we don't need to make any commitment about the exact output.
Add a `--timings` option, as the stable equivalent to `-Ztimings`.
Stabilize the `html` output format, and require `-Zunstable-options` for
the `json` output format.
Document the new option, and update the testsuite.
The text-based timing information emits many additional lines, creating
quite a bit of verbosity. Remove in favor of the HTML report, as
suggested at
https://github.com/rust-lang/cargo/pull/10245#issuecomment-1003741052 .
If we re-add text-based timing information in the future, it could come
in the form of a text-based report, or as a duration printed on the same
line as the crate it measures rather than a separate line.
extra-link-arg-etc: support all link types (credit @davidhewitt)
This commit adds support for the remaining link types to `-Zextra-link-arg-etc`:
`
rustc-link-arg-tests
rustc-link-arg-benches
rustc-link-arg-examples
`
This would be useful in PyO3, where users writing Python extension modules (which do link against libpython) want to run cargo tests for extension module. As executables, these tests need to link against libpython.
This is a follow up of https://github.com/rust-lang/cargo/pull/9416 by `@davidhewitt`
This allows to specify dependency features when using `--all-features`,
for example:
```shell
$ cargo run --package a --example example --all-features --features="tracing/log"
```
bors
Mrmaxmeier
Loïc BRANSTETT
Josh Stone
hi-rustin
Weihang Lo
Josh Triplett
Tyler Mandry
itsjohncs
Ed Page
Alphyr
Maybe Waffle