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"
```
Update publishing link for semver rules.
This updates the publishing guide to point to the chapter on SemVer rules which is more complete and up-to-date than RFC 1105.
