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
`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"
```
do not compile test for bins flagged as `test = false`
### What does this PR try to resolve?
Fixes#10268#6683 introduced a behavior that compiles all bin targets, but for bins with `test = false` they shouldn't be compiled with `--test` as testbins.
### How should we test and review this PR?
In the first commit of this PR, I refines the test `test_filtered_excludes_compiling_examples` to reflect the current wrong behavior (test passed). The following two commits correct the behavior and the test accordingly. The last few commits encapsulate scattered target selection logic into functions on `CompileFilter`.
Port cargo from toml-rs to toml_edit
Benefits:
- A TOML 1.0 compliant parser
- Unblock future work
- Have `cargo init` add the current crate to the workspace, rather
than error
- #5586: Upstream `cargo-add`
TODO
- [x] Analyze performance and address regressions
- [x] Identify and resolve incompatibiies
- [x] Resolve remaining test failures, see
https://github.com/ordian/toml_edit/labels/cargo
- [x] ~~Switch the code from https://github.com/rust-lang/cargo/pull/10176 to only parse once~~ (this PR is being merged first)
The test new::git_default_branch would fail if the current user had
already configured a different default branch.
This patch changes the test to first write a .gitconfig file with the
default branch set to master. This puts us in a state where we still
have the old default, and then the subsequent change to the config file
will make sure that config changes are still respected.
Error when setting crate type of both dylib and cdylib in library
close https://github.com/rust-lang/cargo/issues/10231
Error when setting crate type of both dylib and cdylib in library. Cargo can't support that at this time, since they both output the same filename.
Benefits:
- A TOML 1.0 compliant parser
- Unblock future work
- Have `cargo init` add the current crate to the workspace, rather
than error
- #5586: Upstream `cargo-add`
Stabilize namespaced and weak dependency features.
This stabilizes the namespaced and weak dependency features. Support is now enabled on crates.io, so this should be ready to go.
As a part of this change, the new feature resolver is now enabled all of the time. This is fairly risky, since there are likely edge cases that haven't been exercised.
NOTE: Projects using `resolver="1"` *should* continue to have the same behavior, the old resolver behavior is emulated.
Closes#8813Closes#8832
Port cargo to clap3
### What does this PR try to resolve?
This moves cargo to the latest major version of clap.
This supersedes #10259 and #10262
### How should we test and review this PR?
For testing, I mostly relied on existing tests. I did manually validate that `cargo run <non-escaped command args>` behaved the same between both
```console
$ cargo run release --help
Finished dev [unoptimized + debuginfo] target(s) in 0.22s
Running `target/debug/cargo-release release --help`
cargo-release 0.18.8
...
$ cargo run --manifest-path ../cargo/Cargo.toml -- run release --help
Finished dev [unoptimized + debuginfo] target(s) in 0.05s
Running `/home/epage/src/personal/cargo/target/debug/cargo run release --help`
Finished dev [unoptimized + debuginfo] target(s) in 1.31s
Running `target/debug/cargo-release release --help`
cargo-release 0.18.8
...
```
For reviewing, I split out each deprecation resolution into a separate commit so its easy to focus on more mechanical changes (most of the deprecation fixes) from interesting ones (the port, the `Arg::multiple` deprecation)
### Additional information
- One parser change found by `cargo_config::includes` is that clap 2
would ignore any values after a `=` for flags.
`cargo config --show-origin` is a flag but the test passed `--show-origin=yes` which
happens to give the desired result for that test but is the same as
`--show-origin=no` or `--show-origin=alien-invasion`.
- `ArgMatches` now panics when accessing an undefined argument but clap
takes advantage of that for sharing code across commands that have
different subsets of arguments defined. I've extended clap so we can
"look before you leap" and put the checks at the argument calls to
start off with so its very clear what is tenuously shared. This
allows us to go in either direction in the future, either addressing
how we are sharing between commands or by moving this down into the
extension methods and pretending this clap feature doesn't exist
- On that topic, a test found clap-rs/clap#3263. For now, there is a
hack in clap. Depending on how we fix that in clap for clap 4.0, we
might need to re-address things in cargo.
- `value_of_os` now requires setting `allow_invalid_utf8`, otherwise it
asserts. To help catch this, I updated the argument definitions
associated with lookups reported by:
- `rg 'values?_os' src/`
- `rg 'values?_of_os' src/`
- clap now reports `2` for usage errors, so we had to bypass clap's
`exit` call to keep the same exit code.
- `cargo vendor --sync` did not use `multi_opt` and so it has both
multiple occurrences **and** multiple values. If we want to deprecate
this, we'll need `unstable-grouped` to be stablized (or pin our clap
version) and ensure each group has only 1 value.
- One parser change found by `cargo_config::includes` is that clap 2
would ignore any values after a `=` for flags.
`cargo config --show-origin` is a flag but the test passed `--show-origin=yes` which
happens to give the desired result for that test but is the same as
`--show-origin=no` or `--show-origin=alien-invasion`.
- The parser now panics when accessing an undefined attribute but clap
takes advantage of that for sharing code across commands that have
different subsets of arguments defined. I've extended clap so we can
"look before you leap" and put the checks at the argument calls to
start off with so its very clear what is tenuously shared. This
allows us to go in either direction in the future, either addressing
how we are sharing between commands or by moving this down into the
extension methods and pretending this clap feature doesn't exist
- On that topic, a test found clap-rs/clap#3263. For now, there is a
hack in clap. Depending on how we fix that in clap for clap 4.0, we
might need to re-address things in cargo.
- `value_of_os` now requires setting `allow_invalid_utf8`, otherwise it
asserts. To help catch this, I updated the argument definitions
associated with lookups reported by:
- `rg 'values?_os' src/`
- `rg 'values?_of_os' src/`
- clap now reports `2` for usage errors, so we had to bypass clap's
`exit` call to keep the same exit code.
BREAKING CHANGE: API now uses clap3
Be resilient to most IO error and filesystem loop while walking dirs
Let `PathSource::walk` be resilient to most IO errors and filesystem loop.
This PR also
- Add a test validating the resilience against filesystem loop to prevent regression.
- Emit warning when filesystem loop found while walking the filesystem. This is the only way I can think of now to solve #9528Fixes#10213.
Cargo has had pipelining enabled by default for a long time, without
issue. Remove support for `build.pipelining = false`. (Continue parsing
the option from the config file, but ignore it.)
Remove `build_script::build_script_scan_eacces` test case because cargo
ignores it and returns its path during a `cargo build`. The caller still
has a chance to hit the IO error if they does access it.
Stabilize the `strip` profile option, now that rustc has stable `-C strip`
https://github.com/rust-lang/rust/pull/90058/ stabilized `-Z strip` as `-C strip`. Stabilize the corresponding Cargo option.
Update the documentation to move it from the unstable reference to the profiles documentation.
Update the tests to account for stabilization.
https://github.com/rust-lang/rust/pull/90058/ stabilized `-Z strip` as
`-C strip`. Stabilize the corresponding Cargo option.
Update the documentation to move it from the unstable reference to the
profiles documentation.
Update the tests to account for stabilization, but make them no-ops on
stable/beta for now until rustc 1.58 releases.
When typing in a single character shortcut as a capital, it always
returns `b` as the suggestion as every one-letter abbreviation
is a lev distance 1 away from the capitalized one.
By making the levenshtein distance case insensitive, the case-mismatched
one-letter abbriviation (e.g. `C` to `c`) will be suggested, rather
than `b`
